On 08/28/2017 09:46 PM, Andrew Pinski wrote: > On Mon, Aug 28, 2017 at 7:46 PM, Martin Sebor <mse...@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
