From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127457 invoked by alias); 2 Dec 2015 09:54:11 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 127438 invoked by uid 89); 2 Dec 2015 09:54:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f182.google.com Received: from mail-yk0-f182.google.com (HELO mail-yk0-f182.google.com) (209.85.160.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 02 Dec 2015 09:54:09 +0000 Received: by ykfs79 with SMTP id s79so40678838ykf.1 for ; Wed, 02 Dec 2015 01:54:07 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.129.50.214 with SMTP id y205mr1570576ywy.147.1449050047015; Wed, 02 Dec 2015 01:54:07 -0800 (PST) Received: by 10.37.93.11 with HTTP; Wed, 2 Dec 2015 01:54:06 -0800 (PST) In-Reply-To: <565E11EF.4080605@redhat.com> References: <561482CD.6060202@redhat.com> <56159608.5000801@redhat.com> <5617E10E.6060300@redhat.com> <565E11EF.4080605@redhat.com> Date: Wed, 02 Dec 2015 09:54:00 -0000 Message-ID: Subject: Re: [PATCH][PR tree-optimization/67816] Fix jump threading when DOM removes conditionals in jump threading path From: Richard Biener To: Jeff Law Cc: GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg00220.txt.bz2 On Tue, Dec 1, 2015 at 10:32 PM, Jeff Law wrote: > On 10/09/2015 09:45 AM, Jeff Law wrote: >>> >>> 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. > > So I started looking at this in response to 68619, where this approach does > indeed solve the problem. > > Essentially DOM's optimization of those edges results in two irredicuble > loops becoming reducible. The loop analysis code then complains because we > don't have proper loop structures for the new natural loops. > > Deferring to cfg_cleanup works because if cfg_cleanup does anything, it sets > LOOPS_NEED_FIXUP (which we were trying to avoid in DOM). So it seems that > the gyrations we often do to avoid LOOPS_NEED_FIXUP are probably not all > that valuable in the end. Anyway... Yeah, I have partially working patches lying around to "fix" CFG cleanup to avoid this. Of course in the case of new loops appearing that's not easily possible. > There's some fallout which I'm still exploring. For example, we have cases > where removal of the edge by DOM results in removal of a PHI argument in the > target, which in turn results in the PHI becoming a degenerate which we can > then propagate away. I have a possible solution for this that I'm playing > with. > > I suspect the right path is to continue down this path. Yeah, the issue here is that DOM isn't tracking which edges are executable to handle merge PHIs (or to aovid doing work in unreachable regions). It should be possible to make it do that much like I extended SCCVN to do this (when doing the DOM walk see if any incoming edge is marked executable and if not, mark all outgoing edges as not executable, if the block is executable at the time we process the last stmt determine if we can compute the edge that ends up always executed and mark all others as not executable) Richard. > Jeff > >