Re: RFC -- update_equiv_regs and friends

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

  In message <200103041901.OAA05842@jwlab.FEITH.COM>you write:
   > No, rtx_varies_p determines if the rtx varies at any point in the
  > function (really).  If it returns false, then the rtx * will not *
  > produce a different answer regardless of where it's executed.
  > Unfortunately its special cause handling of LO_SUM operand 0 is
  > biting update_equiv_regs.  In addition update_equiv_regs probably
  > needs to verify that memory addresses don't vary before creating
  > REG_EQUIV notes containing them.
Note that rtx_varies_p does check that the address is non-varying too:

   case MEM:
      return ! RTX_UNCHANGING_P (x) || rtx_varies_p (XEXP (x, 0), for_alias);

  > >  I previously submitted a patch to change
  > > at least some of the code in update_equiv_regs to use rtx_unstable_p
  > > instead of rtx_varies_p.
  > 
  > rtx_unstable_p is less conservative than rtx_varies_p in that it'll
  > return false for a register which is simply marked unchanging.  You
  > really don't want to change update_equiv_regs to use it.
Agreed.  It seems to me that making such a change would make this problem
even worse.  Consider:

  (set (reg dest)  (mem/u (reg/u addr)

We've got the register holding ADDR marked as unchanging, but it could well
die in that insn.

jeff