This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Dead and duplicated code in register elimination




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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]