This is the mail archive of the
mailing list for the GCC project.
Re: operand_equal_p() and SSA_NAME
- From: Jeff Law <law at redhat dot com>
- To: Martin Sebor <msebor at gmail dot com>, GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Mon, 28 Aug 2017 22:22:56 -0600
- Subject: Re: operand_equal_p() and SSA_NAME
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7FF7780F75
- References: <email@example.com>
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;
> memcpy (&a, &a - 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
> 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.