[PATCH] Improved SAVE_EXPR handling in operand_equal_p.

Daniel Berlin dberlin@dberlin.org
Wed Sep 3 21:00:00 GMT 2003


On Sep 3, 2003, at 3:47 PM, Roger Sayle wrote:

>
> Hi Richard,
>
> On Wed, 3 Sep 2003, Richard Henderson wrote:
>>> The patch below fixes this by considering two SAVE_EXPRs that wrap
>>> operand_equal_p subexpressions (which ensures they have no 
>>> side-effects)
>>> as equal.  This is also extended slightly by treating SAVE_EXPR much
>>> like a NOP, so that a SAVE_EXPR(x) is also considered equal to x.
>>
>> This is not really true.  A SAVE_EXPR is a temporary variable.
>> It's value depends on when it is evaluated.  Thus
>>
>> 	$x = SAVE_EXPR (d)
>> 	d++;
>> 	$y = SAVE_EXPR (d)
>>
>> 	$x != $y
>>
>> It is *possible* that if you have two unevaluated SAVE_EXPRs,
>> i.e. SAVE_EXPR_RTL is still null, that the values of their
>> saves will evaluate to be the same.  I'm not certain that we
>> can truely assume this in something as general as operand_equal_p.
>
> Its important to remember that operand_equal_p is only ever used
> to compare two operands within the same expression, typically only
> within the same operator.

This is untrue on the tree-ssa branch, nor is it part of the documented 
interface of operand_equal_p.
> *Any* usage of operand_equal_p where this isn't the case is broken.

you've assumed the usage is for value equivalence in these cases, which 
it isn't.
It's whether the operands look the same (ie lexical equivalence).
--Dan



More information about the Gcc-patches mailing list