From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69705 invoked by alias); 9 Sep 2016 15:17:23 -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 69642 invoked by uid 89); 9 Sep 2016 15:17:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=maximize, balance, him, interest 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; Fri, 09 Sep 2016 15:17:21 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id u89FHIxn032643; Fri, 9 Sep 2016 10:17:19 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id u89FHIlV032642; Fri, 9 Sep 2016 10:17:18 -0500 Date: Fri, 09 Sep 2016 15:26:00 -0000 From: Segher Boessenkool To: Jeff Law Cc: Bernd Schmidt , gcc-patches@gcc.gnu.org Subject: Re: [PATCH v2 0/9] Separate shrink-wrapping Message-ID: <20160909151718.GB28260@gate.crashing.org> References: <81710c02-05bf-fb65-dedc-8ba389c0d8e8@redhat.com> <20160826145001.GA21746@gate.crashing.org> <20160826162709.GA30044@gate.crashing.org> <2c1fee68-4753-779c-5d75-90e6c7f86776@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2c1fee68-4753-779c-5d75-90e6c7f86776@redhat.com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00506.txt.bz2 On Thu, Sep 08, 2016 at 10:41:37AM -0600, Jeff Law wrote: > So can you expand on the malloc example a bit -- I'm pretty sure I > understand what you're trying to do, but a concrete example may help > Bernd and be useful for archival purposes. Sure, but it's big (which is the problem :-) ) > I also know that Carlos is interested in the malloc example -- so I'd > like to be able to pass that along to him. > > Given the multiple early exit and fast paths through the allocator, I'm > not at all surprised that sinking different components of the prologue > to different locations is useful. > > Also if there's a case where sinking into a loop occurs, definitely > point that out. Not sure that happens in there, I'll find out. > >>That's a later addition anyway and isn't necessary to do > >>shrink-wrapping in the first place. > > > >No, it always did that, just not as often (it only duplicated straight-line > >code before). > Presumably (I haven't looked yet), the duplication is so that we can > isolate one or more paths which in turn allows sinking the prologue > further on some of those paths. It duplicates as many blocks as it needs to dup, to make as many exits as possible reachable without *any* prologue/epilogue. As the header comment before the older code says: /* Try to perform a kind of shrink-wrapping, making sure the prologue/epilogue is emitted only around those parts of the function that require it. There will be exactly one prologue, and it will be executed either zero or one time, on any path. Depending on where the prologue is placed, some of the basic blocks can be reached via both paths with and without a prologue. Such blocks will be duplicated here, and the edges changed to match. Paths that go to the exit without going through the prologue will use a simple_return instead of the epilogue. We maximize the number of those, making sure to only duplicate blocks that can be duplicated. If the prologue can then still be placed in multiple locations, we place it as early as possible. > This is something I'll definitely want to look at -- block duplication > to facilitate code elimination (or in this case avoid code insertion) > hits several areas of interest to me -- and how we balance duplication > vs runtime savings is always interesting. Yeah. If you use separate shrink-wrapping you still *also* get the "old" algorithm, if that wasn't clear. Segher