This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][PR tree-optimization/81741] Throttle recording conditional equivalences
- From: Jeff Law <law at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 23 Aug 2017 08:19:13 -0600
- Subject: Re: [PATCH][PR tree-optimization/81741] Throttle recording conditional equivalences
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx07.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 E99B8C0467C6
- References: <firstname.lastname@example.org> <CAFiYyc219bd5-6RCXgM8GyD=uOioO9TmKMA5NndNaDR0a2bqsw@mail.gmail.com>
On 08/23/2017 04:37 AM, Richard Biener wrote:
> On Tue, Aug 22, 2017 at 5:13 PM, Jeff Law <email@example.com> wrote:
>> However, there are still cases where we have a conditional equivalence
>> and the names have the same cost to compute. A greatly simplified
>> example can be found in gcc.dg/tree-ssa/20030922-2.c.
> So the intent is (as in the patch) to not record any conditional equivalence
> for this case?
Correct. We're no longer recording these conditional equivalences in
the const/copies table and SSA_NAME_VALUE. The only time we will record
them now is if one name is cheaper to compute than the other (so that we
can potentially propagate away the expensive one).
Note that we still have 1 = NAME1 eq NAME2
In the expression hash table, which is what allows us to still simplify
stuff like NAME1 ^ NAME2 -> 0 and the like. The mechanism by which
that gets simplified now is different, hence the change in dump scanning.
But to reiterate, we're no longer recording the conditional equivalences
into the const/copies table by default and thus we no longer use
conditional equivalences for const/copy propagation by default.
>> I've simply xfailed this test. To fix it we need to build a second set
>> of tables that are essentially the conditional equivalences, without
>> setting SSA_NAME_VALUE (SSA_NAME_VALUE is what drives const/copy
>> propagation in DOM). That's actually fairly easy and not terribly
>> costly. What gets ugly is we have to consult this second set of tables
>> when doing simplifications. Worse yet, we have to run through each
>> operand's conditional equivalences, substitute it in and try to
>> simplify. It just don't expect it to hit enough to justify that pain.
> Agreed. Note I think the main issue is that conditional equivalences
> do not play well with value-numbering as they affect values of already
> visited expressions. So you'd basically have to re-iterate value-numbering
> possibly affected expressions (recording the new result only temporarily
> of course).
Understood. I still want to flesh out the unwindable equivalence
classes a bit further so I can measure how often cases like 20030922-2.c
occur in practice.
My sense is there's still some cases we're going to want to handle, but
I'm going to have to build the fully generalized version to get enough
instrumentation to guide that decision.
>> The net result is we should stop ping-ponging copy propagations that
>> arise from conditional equivalences at the loss of some minor
>> optimizations in code similar to 20030922-2.c.
> Can you file a PR for the XFAIL?
>> Bootstrapped and regression tested on x86_64. Installing on the trunk.
> Thanks for finally taking a stab at this.
It's been on my list for a while :-)