Re: RFC -- update_equiv_regs and friends

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> 
> > The function rtx_varies_p used in update_equiv_regs only determines
> > whether a rtx varies at the location where the rtx is used in the
> > code.
> 
> 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.

This is what the comments say for rtx_varies_p:

/* Return 1 if X has a value that can vary even between two
   executions of the program.  0 means X can be compared reliably
   against certain constants or near-constants.
   FOR_ALIAS is nonzero if we are called from alias analysis; if it is
   zero, we are slightly more conservative.
   The frame pointer and the arg pointer are considered constant.  */

The comments don't say the rtx is constant at any point in a function
if the falue is 0.  At a given point in a function, operand 0 of a
LO_SUM is always the same but this doesn't mean that the rtx is suitable
for substitution at another point in the program.

The comments for rtx_unstable_p say:

/* Return 1 if the value of X is unstable
   (would be different at a different point in the program).
   The frame pointer, arg pointer, etc. are considered stable
   (within one function) and so is anything marked `unchanging'.  */

This was clearly intended to determine whether an rtx could be used a
a differnt point in the program.

It doesn't seem right to change the behaviour of rtx_varies_p with
respect to LO_SUMs.  Effectively, the only difference between rtx_unstable_p
and rtx_varies_p is in their handling of LO_SUM.  I am fairly certain
that the difference in handling the pic_offset_table_rtx is unnecessary.

The technique used to save and restore the pic offset table
register on the PA was substantially revised recently.  The save is
now done in the body of the function rather than the prologue, and there
is now a use in the return to prevent the last restore from being
deleted (see return_internal_pic).  Thus, I believe the comments
regarding PIC_OFFSET_TABLE_REG_CALL_CLOBBERED are no longer correct,
at least with respect to the PA port.  The only other port that defines
PIC_OFFSET_TABLE_REG_CALL_CLOBBERED is the ia64.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)