Dead and duplicated code in register elimination
Bernd Schmidt
crux@pool.informatik.rwth-aachen.de
Fri Oct 30 12:00:00 GMT 1998
On Fri, 30 Oct 1998, Jeffrey A Law wrote:
>
> In message <Pine.GSO.4.02A.9810261336130.29793-100000@colt.informatik.rwth-aa
> chen.de>you write:
> > I'd like to move the whole register elimination code into a separate file,
> > and add some functionality that can be used from flow.c, global.c,
> > local-alloc.c as well as any other places that need it. Should I send a
> > patch for this?
> Exactly what common functionality are you expecting to move? How much code do
> you think can be shared?
Currently, there are just a few small bits which recompute the set of
eliminable registers scattered throughout the compiler. However, there are a
number of bugs in the elimination code that we need to fix:
- local-alloc.c still thinks that if it allocates a pseudo to an eliminable
register, reload won't be able to reallocate it if the register turns out
not to be eliminable after all. That's a harmless bug.
- flow.c is very inconsistent in its handling of eliminable registers. It
marks the frame pointer as live at the end of the function (but only in
mark_regs_live_at_end, not in the otherwise identical code in
mark_used_regs). It does nothing similar for the other eliminable
registers.
- flow.c expects that if the frame pointer is eliminated, reload will remove
it from the live list of each basic block. There's a function which does
this: mark_elimination in global.c. However, that function is completely
superfluous since the register life information is recomputed during the
post-reload life analysis anyway.
- The post reload life analysis treats the eliminable registers just like
the first flow pass: it marks the frame pointer as globally live,
regardless of whether it was eliminated or not.
We end up with incorrect life information currently; this can be seen by
examining the register dumps for post-reload passes with -fomit-frame-pointer:
the frame pointer will be marked as live everywhere.
To fix the bugs and the few duplicated bits it would be nice to keep track of
the set of eliminable registers, including information about which ones
can/can't be eliminated, throughout compilation of the function, adjusting
the information during reload. Of course we can do all that without moving
the code out of reload1.c; I just thought the file could stand splitting up.
If you don't want to do that, I'll send just the fixes.
Bernd
More information about the Gcc-patches
mailing list