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?) Thanks Martin
