From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26992 invoked by alias); 3 Aug 2011 09:12:05 -0000 Received: (qmail 26978 invoked by uid 22791); 3 Aug 2011 09:12:04 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate1.uk.ibm.com (HELO mtagate1.uk.ibm.com) (194.196.100.161) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Aug 2011 09:11:46 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate1.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p739Bb3q005384 for ; Wed, 3 Aug 2011 09:11:37 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p739BavT1802408 for ; Wed, 3 Aug 2011 10:11:36 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p739BaFD018398 for ; Wed, 3 Aug 2011 03:11:36 -0600 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id p739BZri018360; Wed, 3 Aug 2011 03:11:35 -0600 Message-Id: <201108030911.p739BZri018360@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 03 Aug 2011 11:11:35 +0200 Subject: Re: libgcc: strange optimization To: richard.guenther@gmail.com (Richard Guenther) Date: Wed, 03 Aug 2011 09:12:00 -0000 From: "Ulrich Weigand" Cc: iant@google.com (Ian Lance Taylor), mikpe@it.uu.se (Mikael Pettersson), michael@walle.cc (Michael Walle), avr@gjlay.de (Georg-Johann Lay), hp@bitrange.com (Hans-Peter Nilsson), rth@redhat.com (Richard Henderson), gcc@gcc.gnu.org In-Reply-To: from "Richard Guenther" at Aug 02, 2011 03:42:12 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00064.txt.bz2 Richard Guenther wrote: > On Tue, Aug 2, 2011 at 3:23 PM, Ian Lance Taylor wrote: > > 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 the > >> register variables from constants or parameters. > > > > Let's just implement those requirements in the compiler itself. > > Doesn't work for existing code, no? And 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? Why not extend the constraint > syntax somehow to allow specifying the same effect? 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: If a variable X is declared as register asm for register Y, and X is later on used as operand to an inline asm, the register allocator will choose register Y to hold that asm operand. (And this is the full specification of register asm semantics, nothing beyond this is guaranteed.) It seems this semantics could be implemented very early on, probably in the frontend itself. The 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). The 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 -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com