Re: [PATCH] Re: REG_DEAD/REG_EQUIV problem.

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

  In message <Pine.LNX.4.21.0102182145350.18223-100000@front.linuxcare.com.au>y
ou write:
  > On Sun, 18 Feb 2001, Jeffrey A Law wrote:
  > 
  > >   In message <Pine.LNX.4.21.0102012037050.19209-100000@front.linuxcare.co
  > m.au>y
  > > ou write:
  > >   > On Thu, 1 Feb 2001, Alan Modra wrote:
  > >   > 
  > >   > > (insn 17 15 21 (set (reg/v:DI 69)
  > >   > >         (mem/u:DI (lo_sum:DI (reg:DI 70)
  > >   > >                 (unspec:DI[ 
  > >   > >                         (symbol_ref/v/f:DI ("*L$C0001"))
  > >   > >                     ]  0)) 0)) 83 {*pa.md:2368} (insn_list 15 (nil)
  > )
  > >   > >     (expr_list:REG_EQUIV (mem/u:DI (lo_sum:DI (reg:DI 70)
  > >   > >                 (unspec:DI[ 
  > >   > >                         (symbol_ref/v/f:DI ("*L$C0001"))
  > >   > >                     ]  0)) 0)
  > >   > >         (expr_list:REG_DEAD (reg:DI 70)
  > >   > >             (nil))))
  > >   > 
  > >   > 	* rtlanal.c (reg_death_note_p): New function.
  > >   > 	(reg_mentioned_dies): New function.
  > >   > 	* rtl.h (reg_mentioned_dies): Declare.
  > >   > 	* reload1.c (reload): Don't set reg_equiv_memory_loc for an ins
  > n
  > >   > 	that references memory via a reg that dies.
  > >
  > > This is fundamentally going down the wrong path.
  > 
  > Fair enough.  Better to stop them being emitted in the first place.
  > 
  > > The REG_EQUIV is valid and it's valid for it to be used to create an
  > > equivalence in reg_equiv_memory_loc.
  > > 
  > > The problem is elsewhere.  This just fixes the symptom.
  > 
  > Is it really valid?  Let me ask this:
  > 
  > a) Is it OK for a REG_EQUIV to refer to a register that is marked as dead?
  >    (reg 70 in the above example)
Upon further review, I'm not sure.

We've allowed it in the past, though the circumstances under which it
causes problems may not have happened enough for us to notice.

  > b) If so, then making use of the REG_EQUIV means that the dead register
  >    needs to rise from the dead and live until the point where the
  >    equivalence is used.  This change in reg 70's life wasn't happening.
  >    Should it?
This is where it gets interesting.  Clearly if we allow the equivalence to
be used the way we are now, then any registers referenced inside the
equivalence must be made live (or we have to emit code to initialize
them before using the equivalence).  

  > c) If so, is this worthwhile?  Why not extend reg 69's life instead?
The point of this code is to realize that reg69 has another form and
use in cases where reg69 does not get a hard register.  Else we have to
spill reg69 into the stack.  It's *usually* worth quite a bit of work to
avoid that :-)

Now, you could legitimately ask if we should have recorded insn 15
(whatever insn sets (reg:DI 70) as part of the initialization sequence
for reg 69 and whether or not we should have emitted that code along at
the same time we emitted the LO_SUM expression.    I thought we had code
to do that (see reg_equiv[blah].init_insns).  But I'm not entirely familiar
with that code, so my guess about its purpose could be wrong.

On a positive note, I'm a lot more familiar with the problem you're trying
to solve now since I spend a few minutes tonight looking at it (as opposed
to going strictly on my memory of how all this stuff is supposed to work).

jeff