From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125375 invoked by alias); 12 Sep 2016 16:36:14 -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 125366 invoked by uid 89); 12 Sep 2016 16:36:13 -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,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=crtl, calls_alloca, cfun, calls_eh_return 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; Mon, 12 Sep 2016 16:36:12 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (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 4AB058E3E3; Mon, 12 Sep 2016 16:36:11 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-111.phx2.redhat.com [10.3.116.111]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8CGaAtS001740; Mon, 12 Sep 2016 12:36:10 -0400 Subject: Re: [PATCH 1/9] separate shrink-wrap: New command-line flag, status flag, hooks, and doc To: Segher Boessenkool References: <4b44888ff2f1237b364ccd0a566a4b739db0a032.1470015604.git.segher@kernel.crashing.org> <3a3fece4-6f3a-cb07-8083-a5f6e820c693@redhat.com> <20160909150429.GA28260@gate.crashing.org> <711c73dc-b9c4-9688-03fc-6005d113170d@redhat.com> <20160909203315.GB21356@gate.crashing.org> Cc: Bernd Schmidt , gcc-patches@gcc.gnu.org From: Jeff Law Message-ID: <06335496-6318-f6a3-1668-44941483959e@redhat.com> Date: Mon, 12 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: <20160909203315.GB21356@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/msg00644.txt.bz2 On 09/09/2016 02:33 PM, Segher Boessenkool wrote: > On Fri, Sep 09, 2016 at 12:28:12PM -0600, Jeff Law wrote: >>> The generic code only does >>> >>> + /* We don't handle "strange" functions. */ >>> + if (cfun->calls_alloca >>> + || cfun->calls_setjmp >>> + || cfun->can_throw_non_call_exceptions >>> + || crtl->calls_eh_return >>> + || crtl->has_nonlocal_goto >>> + || crtl->saves_all_registers) >>> + return; >>> >>> so that does not give up in "many" cases. >> Doesn't seem like a lot to me either. > > A few of those could be handled, perhaps with some extra hooks, but it > didn't look useful to me so far. Agreed. I don't think this is worth spending time on. > >>> Targets that push function args can handle things fine as far as I see? >>> Targets that normally use push insns in the prologue will just have to >>> not do that for the components that are separately wrapped. Or they can >>> still use pushes to reserve that space, if that works better. >> To me it's more about the fact that the offset to the slot where the >> register should be saved varies (unless you have a frame pointer) and I >> don't think there's enough information in any of the hook arguments to >> allow derivation of that offset. > > I think knowing in front of what BB to insert the prologue (or after what > BB, the epilogue) is all info we need? Maybe. I'd be worried about things like deferred pops and combine-stack-adjustments. The former are probably OK as I suspect we cleaned things up at basic block boundaries. The latter I've never really looked at. > > And if even that is not good enough for any target then that target can > elect not to do separate shrink-wrapping at all ;-) Exactly. Jeff