From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27072 invoked by alias); 9 Sep 2016 15:26:43 -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 27062 invoked by uid 89); 9 Sep 2016 15:26:42 -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=Hx-languages-length:2953, balance, highly, picture 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 15:26:41 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (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 F091D83F43; Fri, 9 Sep 2016 15:26:39 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-111.phx2.redhat.com [10.3.116.111]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u89FQdn9022060; Fri, 9 Sep 2016 11:26:39 -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> <41fe31e4-81a0-da9e-619a-4c503f7f1051@redhat.com> <20160909061919.GA24532@gate.crashing.org> Cc: Michael Matz , Bernd Schmidt , gcc-patches@gcc.gnu.org From: Jeff Law Message-ID: Date: Fri, 09 Sep 2016 15:28: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: <20160909061919.GA24532@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/msg00507.txt.bz2 On 09/09/2016 12:19 AM, Segher Boessenkool wrote: > Thanks for looking at the patches Jeff. > > On Thu, Sep 08, 2016 at 10:28:59AM -0600, Jeff Law wrote: >> Right. Essentially Segher's patch introduces the concept of prologue >> components that are independent of each other and which can be >> shrink-wrapped separately. The degree of independence is highly target >> specific, of course. > > There can be dependencies as well (e.g. a save to the frame requires that > frame to be set up already), but the current patches have no way to > describe such dependencies. I haven't found a good way to describe the > dependencies yet. Finding a good balance between general and useful isn't > easy, as usual. Right. I over-simplified a bit here. Some dependencies can be handled via the hooks in the target files. I think what we've got is sufficient for now -- we'll have a much clearer picture of weak spots in the design if/when someone enables separate shrink wrapping for another target. Until then, I think we're OK. > >> I think one of the questions (and I haven't looked through the whole >> thread yet to see if it's answered) is why the basic shrink-wrapping >> algorithm can't be applied to each of the prologue components -- though >> you may have answered it with your loop example below. > > You get code size explosion with the "basic" algorithm. And a lot of > that isn't really worth it: avoiding the whole prologue/epilogue is > usually worth copying some blocks for, but avoiding just a single register > save/restore pair? More doubtful. Understood. We have similar balancing problems elsewhere. How much duplication should we allow to expose a CSE or eliminate a conditional jump on a path through the CFG. So I think sticking with this as a design decision makes sense -- does it impact the issue around running a particular component's prologue more than once? >> Thanks. I'd been wondering about when it'd be useful to push prologue >> code into a loop nest when I saw the patches fly by, but didn't think >> about it too much. I haven't looked at the shrink-wrapping literature >> in years, but I don't recall it having any concept that there were cases >> where sinking into a loop nest was profitable. > > It isn't common, but it does happen. If you use a proper cost metric > based on executiuon frequency with some algorithm then that algorithm will > naturally avoid placing *logues into loops. Right and the cases where it's placing them into loops it's going to be doing so on paths that are unlikely executed within the loop. ISTM that using frequencies is a significant step forward over the older placement algorithms in this space (which IIRC were structured as simple dataflow solvers) -- with the added advantage that if we have profiling data we can make better decisions. Does this impact the compile time computation complexity issue that was raised elsewhere? jeff