From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25092 invoked by alias); 30 Nov 2012 21:48:17 -0000 Received: (qmail 25020 invoked by uid 22791); 30 Nov 2012 21:48:16 -0000 X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Nov 2012 21:48:10 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id A5A33CB2957; Fri, 30 Nov 2012 22:48:11 +0100 (CET) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kX4IP1jJIkV; Fri, 30 Nov 2012 22:48:11 +0100 (CET) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id F1F29CB20FF; Fri, 30 Nov 2012 22:48:10 +0100 (CET) From: Eric Botcazou To: Richard Biener Cc: gcc-patches@gcc.gnu.org, Marek Polacek Subject: Re: [PATCH] Don't bypass blocks with multiple latch edges (PR middle-end/54838) Date: Fri, 30 Nov 2012 22:01:00 -0000 Message-ID: <1398692.dAJDxCGIaW@polaris> User-Agent: KMail/4.7.2 (Linux/3.1.10-1.16-desktop; KDE/4.7.2; x86_64; ; ) In-Reply-To: References: <20121126142843.GH17362@redhat.com> <5890792.ZMS3qalP0H@polaris> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 X-SW-Source: 2012-11/txt/msg02573.txt.bz2 > RTL cprop seems to run both before and after RTL loop optimizers (currently > after RTL loop optimizers we throw away loops - an arbitrary chosen point > before IRA across which I could not get things to work). Thus you could do > > if (current_loops) > is_loop_header = bb == bb->loop_father->header; > else > { > may_be_loop_header = false; > FOR_EACH_EDGE (e, ei, bb->preds) > if (e->flags & EDGE_DFS_BACK) > { > may_be_loop_header = true; > break; > } > } OK, let's do something like this then: if (current_loops) may_be_loop_header = (bb == bb->loop_father->header); else { may_be_loop_header = false; FOR_EACH_EDGE (e, ei, bb->preds) if (e->flags & EDGE_DFS_BACK) { may_be_loop_header = true; break; } } since we cannot always be sure that it's a header. > I don't understand > > /* The irreducible loops created by redirecting of edges entering the > loop from outside would decrease effectiveness of some of the > following optimizations, so prevent this. */ > if (may_be_loop_header > && !(e->flags & EDGE_DFS_BACK)) > { > ei_next (&ei); > continue; > } > > why isn't this simply > > if (may_be_loop_header) > { > ei_next (&ei); > continue; > } > > ? It looks like the code tries to allow "rotating" a loop - but that's only > good if bb has exactly two predecessors (one entry and one latch edge). And > even then it requires to manually update the loop structures (update what > the new header and latch blocks are). That's the bug. We have a loop with 2 latch edges, but the loop fixup code in bypass_block only handles one. > That said, removing the !(e->flags & EDGE_DFS_BACK) condition seems > to fix the ICE. Threading across a loop header is in fact complicated > (see the special routine tree-ssa-threadupdate.c:thread_through_loop_header > necessary for that). Scary enough indeed. But this seems to work fine here if the loop has exactly one latch edge, so we don't need to change that. Removing the above condition is equivalent to early returning from bypass_block for all potential headers. > Let's declare the GIMPLE level did all interesting threadings through > headers. The testcase is precisely a counterexample with 2 latch edges. But OK, let's punt if there is more than a single (potential) latch edge. -- Eric Botcazou