Re: Dead and duplicated code in register elimination

[Jeffrey A Law <law at cygnus dot com>]

  In message <Pine.GSO.4.02A.9810302044570.23042-100000@matlock.informatik.rwth
-aachen.de>you write:
  > 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.
I have very bad feelings about this.  Let's not change it right now.  We've
got enough things to stabilize without introducing this factor.

  >   - 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.
I think the frame pointer problem has been fixed.

It's not clear that other eliminable registers need to be live at the same
time as the frame pointer.  So it's not really clear that they should get
the same handling.


  >   - 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.
Agreed.  We need to fix this.  But remember, we don't always run flow2, so
whatever you do needs to work with and without optimization.

  > 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.
I'm not opposed to cleaning things up, I'm just trying to figure out exactly
what you had in mind and determine if it's enough to bother with another
source file.  I *like* simple self contained source files :-)

jeff