From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121162 invoked by alias); 11 Jan 2019 12:18:38 -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 121151 invoked by uid 89); 11 Jan 2019 12:18:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=0.7 required=5.0 tests=BAYES_20,KAM_MANYTO,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=controversial, 52813, Bernd, shrink-wrapping 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, 11 Jan 2019 12:18:36 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x0BCIIDN012198; Fri, 11 Jan 2019 06:18:19 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x0BCIFOA012196; Fri, 11 Jan 2019 06:18:15 -0600 Date: Fri, 11 Jan 2019 12:18:00 -0000 From: Segher Boessenkool To: Bernd Edlinger , Jakub Jelinek , Dimitar Dimitrov , Christophe Lyon , Thomas Preudhomme , "gcc-patches@gcc.gnu.org" , richard.sandiford@arm.com Subject: Re: [PATCH] [RFC] PR target/52813 and target/11807 Message-ID: <20190111121814.GG14180@gate.crashing.org> References: <85840089.MtehzfUrTt@tpdeb> <20190107092337.GM30353@tucnak> <87lg3vicg5.fsf@arm.com> <20190110132111.GZ14180@gate.crashing.org> <87zhs84374.fsf@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zhs84374.fsf@arm.com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00622.txt.bz2 On Thu, Jan 10, 2019 at 09:23:27PM +0000, Richard Sandiford wrote: > Segher Boessenkool writes: > > On Tue, Jan 08, 2019 at 12:03:06PM +0000, Richard Sandiford wrote: > >> Bernd Edlinger writes: > >> > Meanwhile I found out, that the stack clobber has only been ignored up to > >> > gcc-5 (at least with lra targets, not really sure about reload targets). > >> > From gcc-6 on, with the exception of PR arm/77904 which was a regression due > >> > to the underlying lra change, but fixed later, and back-ported to gcc-6.3.0, > >> > this works for all targets I tried so far. > >> > > >> > To me, it starts to look like a rather unique and useful feature, that I would > >> > like to keep working. > >> > >> Not sure what you mean by "unique". But forcing a frame is a bit of > >> a slippery concept. Force it where? For the asm only, or the whole > >> function? This depends on optimisation and hasn't been consistent > >> across GCC versions, since it depends on the shrink-wrapping > >> optimisation. (There was a similar controversy a while ago about > >> to what extent -fno-omit-frame-pointer should "force a frame".) > > > > It's not forcing a frame currently: it's just setting frame_pointer_needed. > > Whatever happens from that is the target's business. > > Do you mean the asm clobber or -fno-omit-frame-pointer? If the option, > then yeah, and that was exactly what was controversial :-) I meant the asm clobber. LRA sets frame_pointer_needed to 1 because the stack pointer is clobbered, on many targets anyway: /* If we modify the source of an elimination rule, disable it. Do the same if it is the destination and not the hard frame register. */ for (ep = reg_eliminate; ep < ®_eliminate[NUM_ELIMINABLE_REGS]; ep++) if (ep->from_rtx == XEXP (x, 0) || (ep->to_rtx == XEXP (x, 0) && ep->to_rtx != hard_frame_pointer_rtx)) setup_can_eliminate (ep, false); and setup_can_eliminate has if (! value && ep->from == FRAME_POINTER_REGNUM && ep->to == STACK_POINTER_REGNUM) frame_pointer_needed = 1; > >> The effect on the redzone seems like something that should be specified > >> explicitly rather than as an (accidental?) side effect of listing the > >> sp in the clobber list. Maybe this would be another use for the "asm > >> attributes" proposal. "noreturn" was another attribute suggested on > >> IRC yesterday. > > > > Redzone is target-dependent. > > Right. Target-dependent asm attributes wouldn't be a problem though. It's harder to document, which means it is harder to get right (and get people to _use_ it correctly), as well. > Most other things about an asm are target-dependent anyway. Very true. > > "noreturn"... What would that mean, *exactly*? It cannot execute any > > code the compiler can see, so such asm is better off as real asm anyway > > (not inline asm). > > "Exactly" is a strong word, and this wasn't my proposal, but... "Exactly", as in, "please do enough hand-waving to cover all available space" ;-) There are many details that aren't quite obvious, but they do matter for how usable and useful this extension would be. > I think it would act like a noreturn call to an unknown function. Except it won't behave like a call otherwise (on Power all calls force a stack frame, for example; and on all targets noreturn calls do the same currently I think?) > Output operands wouldn't make sense, and arguably clobbers wouldn't > either. Yeah. Segher