Re: [PATCH] Improved SAVE_EXPR handling in operand_equal_p.

[Roger Sayle <roger at eyesopen dot com>]

On Wed, 3 Sep 2003, Richard Henderson wrote:
> > 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.
>
> Yes, but is it guaranteed that both SAVE_EXPRs originate from
> the same expression?  I don't think that's necessarily true.

That all depends upon your definition of "same expression" :>
The recursive invocation of operand_equal_p checks that both
SAVE_EXPRs wrap identical trees without side-effects.

Consider that one solution to this problem might be to have
save_expr check whether its operand side-effects or not, and
avoid wrapping it with a SAVE_EXPR node if it doesn't.  In
theory, we don't require a SAVE_EXPR to preserve behaviour.
Unfortunately, this then becomes an efficiency issue, where
a tree may involve a significant computation, and we'd like
to use the result more than once.  For this reason, we wrap
SAVE_EXPRs around trees that don't need them.  But this then
confuses "fold" into believing that otherwise equivalent
expressions are distinguishable.

Should it matter that SAVE_EXPR (VAR_DECL (d)) and
SAVE_EXPR (VAR_DECL (d)) don't share the same tree node,
if we know that d can't have been modified since either
SAVE_EXPR?  In "cabs(z) != cabs(z)" there are two distinct
SAVE_EXPR nodes that wrap equal operands.

Roger
--