operand_equal_p() and SSA_NAME

[Martin Sebor <msebor at gmail dot com>]

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