This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: reload question
- From: Miles Bader <miles at lsi dot nec dot co dot jp>
- To: Ian Lance Taylor <ian at airs dot com>
- Cc: <tm_gccmail at kloo dot net>, Bernd Schmidt <bernds_cb1 at t-online dot de>, gcc at gcc dot gnu dot org
- Date: Thu, 02 Jun 2005 14:56:17 +0900
- Subject: Re: reload question
- References: <Pine.LNX.4.21.0503250447460.25190-100000@mail.kloo.net><m3fyyj6glv.fsf@gossamer.airs.com>
- Reply-to: Miles Bader <miles at gnu dot org>
Ian Lance Taylor <ian@airs.com> writes:
> I agree that gcc is not well designed to cope with an accumulator
> architecture. Reload can't cope.
I've had a fair amount of success with the approach I initially posted
(perturbing the emission order of reloads based on dependencies between
the operand they are associated with). It's still pretty fragile in the
sense that even a tiny mistake in something like the constraints will
cause reload to barf, but I guess that's to be expected. The code
produced seems pretty reasonable too (with almost no peepholes at all);
for instance it will allocate a variable to the accumulator in the odd
case where that's possible.
[I don't know if this is the sort of thing that's viable for merging
into standard gcc, but maybe a simpler approach based on a backend hook
or something would be.]
I gotta admit though, by now I thoroughly hate the gcc reload code...
-Miles
--
((lambda (x) (list x x)) (lambda (x) (list x x)))