From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97818 invoked by alias); 2 Dec 2015 15:31:40 -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 97794 invoked by uid 89); 2 Dec 2015 15:31:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 02 Dec 2015 15:31:39 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 584DE5A081; Wed, 2 Dec 2015 15:31:38 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-91.phx2.redhat.com [10.3.113.91]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB2FVb8X019240; Wed, 2 Dec 2015 10:31:38 -0500 Subject: Re: [PATCH][PR tree-optimization/67816] Fix jump threading when DOM removes conditionals in jump threading path To: Richard Biener References: <561482CD.6060202@redhat.com> <56159608.5000801@redhat.com> <5617E10E.6060300@redhat.com> <565E11EF.4080605@redhat.com> Cc: GCC Patches From: Jeff Law Message-ID: <565F0ED9.50400@redhat.com> Date: Wed, 02 Dec 2015 15:31:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg00294.txt.bz2 On 12/02/2015 02:54 AM, Richard Biener wrote: >> 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. And that may argue that it's largely inevitable if we collapse a conditional (and thus delete an edge). > >> 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). Right. 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) Essentially yes. I'm using the not-executable flag and bypassing things when it's discovered. The most interesting side effect, and one I haven't fully analyzed yet is an unexpected jump thread -- which I've traced back to differences in what the alias oracle is able to find when we walk unaliased vuses. Which makes totally no sense that it's unable to find the unaliased vuse in the simplified CFG, but finds it when we don't remove the unexecutable edge. As I said, it makes no sense to me yet and I'm still digging. jeff