public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH][PR tree-optimization/67816] Fix jump threading when DOM removes conditionals in jump threading path
Date: Fri, 09 Oct 2015 15:45:00 -0000	[thread overview]
Message-ID: <5617E10E.6060300@redhat.com> (raw)
In-Reply-To: <CAFiYyc1zCHN40QSs=GH7bzJ35EJvYHk2pGv6HZabq5EkU2LTXw@mail.gmail.com>

On 10/08/2015 03:56 AM, Richard Biener wrote:
> On Thu, Oct 8, 2015 at 12:00 AM, Jeff Law <law@redhat.com> wrote:
>> On 10/07/2015 02:26 AM, Richard Biener wrote:
>>
>>>
>>> Hmm, other passes avoid all this by not removing edges or blocks
>>> themselves but leaving that to cfgcleanup.  They simply replace the
>>> condition in GIMPLE_CONDs or the switch value in GIMPLE_SWITCHes and
>>> let cleanup_control_expr_graph do the hard part of the job.
>>>
>>> Now - I don't know how that would interact with jump threads
>>> covering those paths, that is, what kind of "mess" jump threading
>>> would produce with the conditions/switches mangled that way.
>>>
>>> The other nice thing is that CFG cleanup properly deals with loop
>>> structure changes.
>>
>> Threading will handle it correctly as that's essentially how we handled it
>> until last week ;-)
>>
>> The "problem" is the threader thread through those blocks.  And while that
>> works correctly, it is quite wasteful in terms of compile time and memory
>> consumption due to the block duplication required to preserve side effects.
>> It also churns the blocks & ssa-names used in the isolated regions which
>> makes comparing debugging dumps before/after threading much harder than it
>> ought to be.
>
> Yes, but as you remove jump threading paths you could leave the CFG change to
> cfg-cleanup anyway?  To get better behavior wrt loop fixup at least?
So go ahead and detect, remove the threading paths, but leave final 
fixup to cfg-cleanup.  I can certainly try that.

It'd actually be a good thing to experiement with regardless -- I've 
speculated that removing the edges in DOM allows DOM to do a better job, 
but never did the instrumentation to find out for sure.  Deferring the 
final cleanup like you've suggested ought to give me most of what I'd 
want to see if there's really any good secondary effects of cleaning up 
the edges in DOM.

jeff

  reply	other threads:[~2015-10-09 15:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-07  2:26 Jeff Law
2015-10-07  8:26 ` Richard Biener
2015-10-07 22:00   ` Jeff Law
2015-10-08  9:56     ` Richard Biener
2015-10-09 15:45       ` Jeff Law [this message]
2015-12-01 21:32         ` Jeff Law
2015-12-02  9:54           ` Richard Biener
2015-12-02 15:31             ` Jeff Law
2015-12-02 15:35               ` Richard Biener
2015-12-02 22:57                 ` Jeff Law
2015-12-03  9:57                   ` Richard Biener
2015-12-03 20:29                 ` Jeff Law
2015-12-04 10:12                   ` Richard Biener
2015-12-04 17:18                     ` Jeff Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5617E10E.6060300@redhat.com \
    --to=law@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).