From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24184 invoked by alias); 9 Sep 2016 16:48:35 -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 23886 invoked by uid 89); 9 Sep 2016 16:48:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=forefront, balance, terrible 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 ESMTP; Fri, 09 Sep 2016 16:48:32 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A1DC561E63; Fri, 9 Sep 2016 16:48:31 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-111.phx2.redhat.com [10.3.116.111]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u89GmVmQ015750; Fri, 9 Sep 2016 12:48:31 -0400 Subject: Re: [PATCH v2 0/9] Separate shrink-wrapping To: Segher Boessenkool References: <81710c02-05bf-fb65-dedc-8ba389c0d8e8@redhat.com> <20160826145001.GA21746@gate.crashing.org> <902e82bf-16c4-b302-ed44-90fb09b7c013@redhat.com> <20160909152806.GC28260@gate.crashing.org> Cc: Bernd Schmidt , gcc-patches@gcc.gnu.org From: Jeff Law Message-ID: Date: Fri, 09 Sep 2016 16:49:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160909152806.GC28260@gate.crashing.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00519.txt.bz2 On 09/09/2016 09:28 AM, Segher Boessenkool wrote: >> Segher's code essentially allows individual components of the prologue >> to sink to different points within the function rather than forcing the >> prologue to be sunk as an atomic unit. > > It also allows prologue an epilogue components to be placed in multiple > places, Right. I need to keep that in the forefront of my mind. and even allows them to be executed more than once, if that is > cheaper. This is the part that I'm still struggling with. > >>>> The full-prologue algorithm makes as many blocks run without prologue as >>>> possible, by duplicating blocks where that helps. If you do this for >>>> every component you can and up with 2**40 blocks for just 40 components, >>> >>> Ok, so why wouldn't we use the existing code with the duplication part >>> disabled? That's a later addition anyway and isn't necessary to do >>> shrink-wrapping in the first place. >> I think the concern here is the balance between code explosion and the >> runtime gains. > > The code explosion can be terrible if you have only a few components, > already. The runtime gains are not so great either. Here's a simple > example, showing part of a cfg, the exits to the right are calls to > abort and need some prologue component: > > | > 1 > |\ > | \ > 2 X1 > |\ > | \ > | X2 > | 3 > > With the "old" algorithm, you need to place the prologue at 1 (because > you can only have one), and then the fall-through path also necessarily > gets that component's prologue. With the "separate" algorithm, the > component prologues can be placed at X1 and X2 instead (and that will > most likely be cheapest according to the cost model, too). Thanks. That really helps highlight some of the key differences between the old and new model. > > You can also put this in a loop. I'll try to make a simple example > with that. That would be great. And a case where they execute more than once too. Jeff