From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5279 invoked by alias); 14 Jan 2013 17:52:09 -0000 Received: (qmail 5268 invoked by uid 22791); 14 Jan 2013 17:52:07 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 14 Jan 2013 17:51:56 +0000 Received: from campfire.kam.mff.cuni.cz (campfire.kam.mff.cuni.cz [195.113.17.153]) by nikam.ms.mff.cuni.cz (Postfix) with ESMTP id 75883541967; Mon, 14 Jan 2013 18:51:54 +0100 (CET) Received: by campfire.kam.mff.cuni.cz (Postfix, from userid 29025) id 685F620E01; Mon, 14 Jan 2013 18:51:54 +0100 (CET) Date: Mon, 14 Jan 2013 17:52:00 -0000 From: Zdenek Dvorak To: Marek Polacek Cc: Steven Bosscher , GCC Patches , Richard Guenther Subject: Re: [PATCH] Fix PR55833 + cheaper checking Message-ID: <20130114175154.GA22128@kam.mff.cuni.cz> References: <20130110173143.GD20218@redhat.com> <20130110221943.GA14720@kam.mff.cuni.cz> <20130114161353.GB5414@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130114161353.GB5414@redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2013-01/txt/msg00716.txt.bz2 Hi, > On Thu, Jan 10, 2013 at 11:19:43PM +0100, Zdenek Dvorak wrote: > > I agree -- at the very least, unswitch_single_loop should check whether there > > is any possiblity it could have affected irreducible loops information (this > > should only be the case when some already existing irreducible loop is altered > > in the progress). Which is what it (or more precisely, remove_path function > > used by it) tries to do -- so is should be sufficient to check why this fails > > for the considered testcase, and make sure the situation is correctly detected, > > Actually, in this case, we don't call remove_path from unswitch_single_loop > at all. I am not quite sure what you mean by that -- remove_path is called unconditionally in unswitch_loop (and fix_loop_placement is only called through remove_path). > So, here's another stab at it. In this version, we will call > mark_irreducible_loops only in case where we're removing a loop > from loop hierarchy tree. Because when we do that (and we're in some > irreducible region), the edge that connects those two loops > should be marked as EDGE_IRREDUCIBLE_LOOP. And the preheader BB > eventually as BB_IRREDUCIBLE_LOOP. Does this look any better? > I'm not actually checking whether we really are in a irreducible > region, should that be done (how?)? Yes, you should check whether you are in an irreducible loop. This is done by testing EDGE_IRREDUCIBLE_LOOP flag, Zdenek