On 08/28/2017 08:46 PM, Martin Sebor 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. > > When this handling of ADDR_EXPR is added, the internal call to > the recursive function returns true but the outermost call then > fails the "hash state" assertion. With the assertion removed > the change then causes at least one test suite failure due to > a gimple validation check. That suggests that the function > deliberately doesn't handle SSA_NAMEs but I don't understand > why. > > If that is, in fact, intentional, can someone explain what > the rationale is? > > Incidentally, I noticed that operand_equal_for_phi_arg_p() in > tree.c that calls operand_equal_p() takes care to avoid doing so > when either argument is an SSA_NAME, apparently as a (presumably > compile-time) optimization. That seems to confirm that not > handling SSA_NAMEs is intentional (but doesn't explain it). > (As an aside, if operand_equal_p() is meant to return false > for SSA_NAMES and there is a use case for it doing so quickly > why not simply have it do what operand_equal_for_phi_arg_p does > as the first thing?) operand_equal_p was never designed to look back through the use-def chains. In fact, it pre-dates all the SSA work.
In general I'd think if you find yourself wanting operand_equal_p to look backwards through the use-def chains, then more likely than not a constant/copy propagation opportunity has been missed somewhere. jeff
