This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: operand_equal_p() and SSA_NAME


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]