From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14921 invoked by alias); 3 Aug 2011 10:04:27 -0000 Received: (qmail 14908 invoked by uid 22791); 3 Aug 2011 10:04:25 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-gx0-f175.google.com (HELO mail-gx0-f175.google.com) (209.85.161.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Aug 2011 10:04:11 +0000 Received: by gxk3 with SMTP id 3so114873gxk.20 for ; Wed, 03 Aug 2011 03:04:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.235.4 with SMTP id i4mr435529ybh.136.1312365850700; Wed, 03 Aug 2011 03:04:10 -0700 (PDT) Received: by 10.150.219.17 with HTTP; Wed, 3 Aug 2011 03:04:10 -0700 (PDT) In-Reply-To: <4E3919EA.2080002@gjlay.de> References: <201108030911.p739BZri018360@d06av02.portsmouth.uk.ibm.com> <4E3919EA.2080002@gjlay.de> Date: Wed, 03 Aug 2011 10:04:00 -0000 Message-ID: Subject: Re: libgcc: strange optimization From: Richard Guenther To: Georg-Johann Lay Cc: Ulrich Weigand , Ian Lance Taylor , Mikael Pettersson , Michael Walle , Hans-Peter Nilsson , Richard Henderson , gcc@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-08/txt/msg00066.txt.bz2 On Wed, Aug 3, 2011 at 11:50 AM, Georg-Johann Lay wrote: > Ulrich Weigand wrote: >> Richard Guenther wrote: >>> On Tue, Aug 2, 2011 at 3:23 PM, Ian Lance Taylor wrot= e: >>>> Richard Guenther writes: >>>>> I suggest to amend the documentation for local call-clobbered register >>>>> variables to say that the only valid sequence using them is from a >>>>> non-inlinable function that contains only direct initializations of t= he >>>>> register variables from constants or parameters. >>>> Let's just implement those requirements in the compiler itself. >>> Doesn't work for existing code, no? =A0And if thinking new code then >>> I'd rather have explicit dependences (and a way to represent them). >>> Thus, for example >>> >>> asm ("scall" : : "asm("r0")" (10), ...) >>> >>> thus, why force new constraints when we already can figure out >>> local register vars by register name? =A0Why not extend the constraint >>> syntax somehow to allow specifying the same effect? > > Yes this would be exact equivalence of > > =A0register int var asm ("r0") =3D 10; > =A0... > =A0asm ("scall" : : "r" (var), ...) > > >> Maybe it would be possible to implement this while keeping the syntax >> of existing code by (re-)defining the semantics of register asm to >> basically say that: >> >> =A0If a variable X is declared as register asm for register Y, and X >> =A0is later on used as operand to an inline asm, the register allocator >> =A0will choose register Y to hold that asm operand. =A0(And this is the >> =A0full specification of register asm semantics, nothing beyond this >> =A0is guaranteed.) > > Yes, that's reasonable. =A0As I understand the docs, in code like > > void foo () > { > =A0 register int var asm ("r1") =3D 10; > =A0 asm (";; use r1"); > } > > there is nothing that connects var to the asm and assuming that > r1 holds 10 in the asm is a user error. > > The only place where the asm attached to a variable needs to have > effect are the inline asm sequences that explicitly refer to > respective variables. =A0If there is no inline asm referencing a > local register variable, there is on difference to a non-register > auto variable; there could even be a warning that in such a case > that > > =A0 register int var asm ("r1") =3D 10; > > is equivalent to > > =A0 int var =3D 10; > >> It seems this semantics could be implemented very early on, probably >> in the frontend itself. =A0The frontend would mark the *asm* statement >> as using the specified register (there would be no special handling >> of the *variable* as such, after the frontend is done). =A0The optimizers >> would then simply be required to pass the asm-statement register >> annotations though, much like today they pass constraints through. >> At the point where register allocation decisions are made, those >> register annotations would then be acted on. >> >> Bye, >> Ulrich > > I wonder why it does not work like that in the current implementation. > Local register variable is just like using a similar constraint > (with the only difference that in general there is no such constraint, > otherwise the developer would use it). A pass like .asmcons could > take care of it just the same way it does for constraints and no > optimizer passed would have to bother if a variable is a local register > or not. > > This would render local register variables even more functional > because no one needed to care if there were implicit library calls > or things like that. Yes, I like that idea. Richard.