From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38190 invoked by alias); 12 Feb 2020 10:02:06 -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 38178 invoked by uid 89); 12 Feb 2020 10:02:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy= X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Feb 2020 10:02:00 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 01CA1voZ024682; Wed, 12 Feb 2020 04:01:57 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 01CA1up3024681; Wed, 12 Feb 2020 04:01:56 -0600 Date: Wed, 12 Feb 2020 10:02:00 -0000 From: Segher Boessenkool To: Richard Biener Cc: Roman Zhuykov , "Kewen.Lin" , GCC Patches , Bill Schmidt , "bin.cheng" Subject: Re: [PATCH 0/4 GCC11] IVOPTs consider step cost for different forms when unrolling Message-ID: <20200212100155.GC22482@gate.crashing.org> References: <20200120123332.GV3191@gate.crashing.org> <52c8eecc-3383-81ad-70ce-27c149d7a103@linux.ibm.com> <20200210212910.GL22482@gate.crashing.org> <20200211074859.GV22482@gate.crashing.org> <1ac98132-734e-0ee3-5ea2-7ec256ee92d2@ispras.ru> <20200211181216.GX22482@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00720.txt.bz2 On Wed, Feb 12, 2020 at 09:12:58AM +0100, Richard Biener wrote: > On Tue, 11 Feb 2020, Segher Boessenkool wrote: > > Basic block partitioning has wildly disproportionate fallout in all > > later passes, both in terms of what those *do* (or don't, if partitioning > > is enabled), and of impact on the code (not to mention developer time). > > > > Maybe the implementation can be improved, but probably we should do this > > in a different way altogether. The current situation is not good. > > I think the expectation that you can go back to CFG layout mode > and then work with CFG layout tools after we've lowered to CFG RTL > is simply bogus. Partitioning is also quite problematic if you do not use cfglayout mode. For example, in shrink-wrapping. It prevents a lot there. > Yeah, you can probably do analysis things but > I wouldn't be surprised if a CFG RTL -> CFG layout -> CFG RTL cycle > can wreck things. Undoubtedly doing CFG manipulations is not going > to work since CFG layout does not respect CFG RTL restrictions. Doing CFG manipulations on CFG RTL mode directly is almost impossible to do correctly. For example, bb-reorder. Which is a much more important optimisation than partitioning, btw. > Partitioning simply uncovered latent bugs, there's nothing wrong > with it IMHO. I don't agree. The whole way EDGE_CROSSING works hinders all other optimisations a lot. Segher