operand_equal_p() and SSA_NAME

[Jeff Law]

On 08/28/2017 09:46 PM, Andrew Pinski wrote:
> On Mon, Aug 28, 2017 at 7:46 PM, Martin Sebor <msebor@gmail.com> wrote:
>> operand_equal_p() doesn't handle SSA_NAMEs and returns false for
>> operands in that form even when they have equal values (when both
>> are ADDR_EXPR of the same decl).  Yet the function is extensively
>> relied on in the middle end where I would expect it be beneficial
>> to have it handle SSA_NAMEs.  At a minimum, it would let some
>> tests succeed earlier rather than later, leading to better code.
>> One example is:
>>
>>   char a[32];
>>   memcpy (&a[2], &a[4] - 2, 7);
>>
>> which would be eliminated even without optimization if the function
>> did handle SSA_NAMEs.
> 
> 
> It does handle it via:
>   /* If ARG0 and ARG1 are the same SAVE_EXPR, they are necessarily equal.
>      We don't care about side effects in that case because the SAVE_EXPR
>      takes care of that for us. In all other cases, two expressions are
>      equal if they have no side effects.  If we have two identical
>      expressions with side effects that should be treated the same due
>      to the only side effects being identical SAVE_EXPR's, that will
>      be detected in the recursive calls below.
>      If we are taking an invariant address of two identical objects
>      they are necessarily equal as well.  */
>   if (arg0 == arg1 && ! (flags & OEP_ONLY_CONST)
>       && (TREE_CODE (arg0) == SAVE_EXPR
>           || (flags & OEP_MATCH_SIDE_EFFECTS)
>           || (! TREE_SIDE_EFFECTS (arg0) && ! TREE_SIDE_EFFECTS (arg1))))
>     return 1;
> 
> 
> That is SSA_NAMES are only equal to another SSA_NAME if it is self.
> Otherwise it a different optimization pass job to get them to be
> equal.
Exactly.

> In this case most likely FRE or DOM.  If they are not doing the job,
> you need to check why and not change operand_equal_p to look back it
> the SSA_NAME's definition.
> 
Right.

Jeff