From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88599 invoked by alias); 9 Sep 2016 17:01:20 -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 87810 invoked by uid 89); 9 Sep 2016 17:01:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=tonight 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 17:01:18 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (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 97E718B973; Fri, 9 Sep 2016 17:01:17 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-111.phx2.redhat.com [10.3.116.111]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u89H1Hg5003151; Fri, 9 Sep 2016 13:01:17 -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> <20160826162709.GA30044@gate.crashing.org> <2c1fee68-4753-779c-5d75-90e6c7f86776@redhat.com> <20160909151718.GB28260@gate.crashing.org> <6671c3dd-6d8c-0f4d-4729-528442ad42fc@redhat.com> <20160909164905.GA7827@gate.crashing.org> Cc: Bernd Schmidt , gcc-patches@gcc.gnu.org From: Jeff Law Message-ID: <79b328f4-6b7f-6ce7-5f75-30e8ad814336@redhat.com> Date: Fri, 09 Sep 2016 17:22: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: <20160909164905.GA7827@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/msg00524.txt.bz2 On 09/09/2016 10:49 AM, Segher Boessenkool wrote: > On Fri, Sep 09, 2016 at 09:59:03AM -0600, Jeff Law wrote: >> On 09/09/2016 09:17 AM, Segher Boessenkool wrote: >>> 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 :-) ) >> Yea :( But it's likely a very compelling example of real world code. >> It's almost certainly too big to turn into a testcase of any kind, but >> just some before/after annotated code would be helpful. > > I'll work on it, but it won't be before tonight, probably quite a bit > later. Seeing the difference in generated machine code is probably > most useful? Better than RTL ;-) Yea, machine code is probably most useful. > >> Ideally we'd have some smaller testcases we could put in the testsuite >> to ensure that the feature works over-time in the way intended would be >> helpful as well. > > I might be able to make some really tiny testcases that will not need > updates all of the time. We'll see. Understood, particularly on the maintenance burden for these kind of tests. The alternate approach might be to pick up Bernd's work and see if we can use that test the various components. > > But that is not because it is good to have only one! GCC expects there > to be only one, instead. Some ports might even use prologues that cannot > be duplicated at all. Agreed on all points. > >> And in separate shrink-wrapping world, we're leaving that model behind >> and I think that's one of the big things I'm struggling with -- we may >> execute a prologue component more than once if I've read everything >> correctly. > > Yes, and that is perhaps radically new in the GCC world, but not anywhere > else. And just to be clear I think I'm mostly looking for why multiple execution of a particular component is useful. My first thought in that case is that we've got a redundancy and that the redundancy should be identified and eliminated :-) I've got a few not-well-formed ideas in my head about when that might happen and why we might not want to squash out the redundancy. But it'd be a hell of a step forward to see that case in action. Jeff