From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3648 invoked by alias); 3 Aug 2011 20:50:33 -0000 Received: (qmail 3637 invoked by uid 22791); 3 Aug 2011 20:50:31 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from atrey.karlin.mff.cuni.cz (HELO atrey.karlin.mff.cuni.cz) (195.113.26.193) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Aug 2011 20:50:17 +0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id CA656F056D; Wed, 3 Aug 2011 22:50:15 +0200 (CEST) Date: Wed, 03 Aug 2011 20:50:00 -0000 From: Jan Hubicka To: Richard Henderson Cc: "gcc@gcc.gnu.org" Subject: Re: [RFC] Remove -freorder-blocks-and-partition Message-ID: <20110803205015.GC22893@atrey.karlin.mff.cuni.cz> References: <4E25F810.6050904@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E25F810.6050904@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-08/txt/msg00073.txt.bz2 Hi, > The worst part is that test coverage for this feature is > extremely poor. It's very difficult to tell if any cleanup > in this area is likely to introduce more bugs than it fixes. > > After 3 days fighting with this code, I had a bit of a > cathartic whine on IRC. I got two votes to just rip the > whole thing out. I am also not fan of the code, given that I had several encounters with it and was bit by it quite badly, too. With ipa-split I implemented part of what is needed for outlining of cold regions of function sinto a separate functions. This however is different from partitioning - i.e. the code sequence of getting into the offlined part is longer since you need to actually pass stuff in function arguments and it is hard to jump back and forth in between hot and cold regions. Expecting it the partitioning to be fully replaced by gimple level offlining is thus not realistic. So function partitioning still makes sense to me as an optimization and in fact I was hoping to get it into shape that it can be enabled with -fprofile-use by default and thus also tested by profiledbootstrap. It did not happen as I am busy with IPA/LTO tasks at the moment. So I am unsure what really we want to do. Removing the feature seems pity, but at the same time the code really needs an revamp. Since you apparently spent most time to on this issue, I won't object to your decision to rip out the code. Honza > > Andrew Pinski points out that the feature could probably be > equivalently implemented via outlining and function calls > (I assume well back at the gimple level). At which point we > no longer have cross-segment jump_insns at the rtl level, > which seems like a Really Big Win to me at this point. > Not that I'm volunteering to actually do the work to implement > any such scheme. > > Thoughts? > > > r~