From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4465 invoked by alias); 7 Nov 2007 11:55:48 -0000 Received: (qmail 4442 invoked by uid 22791); 7 Nov 2007 11:55:47 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate6.de.ibm.com (HELO mtagate6.de.ibm.com) (195.212.29.155) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 07 Nov 2007 11:55:43 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id lA7BteQ5392604 for ; Wed, 7 Nov 2007 11:55:40 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.6) with ESMTP id lA7BtdrK2015384 for ; Wed, 7 Nov 2007 12:55:40 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id lA7Btdm7013999 for ; Wed, 7 Nov 2007 12:55:39 +0100 Received: from lc4eb0107015440.ibm.com (dyn-9-152-216-52.boeblingen.de.ibm.com [9.152.216.52]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id lA7Btcq1013974; Wed, 7 Nov 2007 12:55:38 +0100 Received: by lc4eb0107015440.ibm.com (sSMTP sendmail emulation); Wed, 07 Nov 2007 12:54:29 +0100 From: "Andreas Krebbel" Date: Wed, 07 Nov 2007 11:55:00 -0000 To: Richard Sandiford Cc: gcc-patches@gcc.gnu.org Subject: Re: [PING] Target hook for rewriting inline asm constraints Message-ID: <20071107115429.GA6782@homer.boeblingen.de.ibm.com> References: <20071031162911.GA13462@homer.boeblingen.de.ibm.com> <84fc9c000710310943i7c45fadcs7f3558816218ffa3@mail.gmail.com> <20071031172121.GA14226@homer.boeblingen.de.ibm.com> <87zlxty5l4.fsf@firetop.home> <20071105092430.GA7464@homer.boeblingen.de.ibm.com> <87ve8hxc1j.fsf@firetop.home> <20071105103043.GA8118@homer.boeblingen.de.ibm.com> <87r6j5x8ee.fsf@firetop.home> <20071105134109.GA10193@homer.boeblingen.de.ibm.com> <87ode76nml.fsf@firetop.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ode76nml.fsf@firetop.home> User-Agent: Mutt/1.4.2.2i 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 X-SW-Source: 2007-11/txt/msg00318.txt.bz2 > Maybe I'm misunderstanding what you want, but I thought we were > simply talking about renaming the "all valid memory addresses" > constraint from 'm' to some target-specific value. That renamed > constraint would be treated exactly as 'm' is treated now, without > the need for any special back-end code to handle it. I was thinking about the usage of that new "all valid memory addresses" constraint in the back end. That constraint letter will only be usable for instructions which support the old as well as the new address format which is probably a rare case. I was hoping that this could be improved when having a target hook with extra logic instead of a macro but I don't think anymore that this would help. Another thing I was worrying about was that for an inline assembly using the "m" constraint different (maybe worse) code can be generated when "m" is handled as extra constraint instead of as standard memory constraint. That wouldn't be a problem with the target hook returning "m" for previous archs since the standard "m" codepath would be taken. But at least for reload this does not seem to be a problem. The code handling extra memory constraints matches what is done for the "m" case. To sum up I think you've convinced me that the target macro will do the job and is simpler to implement than the rewriting hook. As next step I would like to give the "let the back end redefine standard constraints" idea a whirl and will come back to your target macro if this doesn't turn out to be feasible. Thanks for your suggestions! > True. Is s390 out of single constraint letters? Not yet. But there are not many left. > > What about the idea of letting the back end override all the existing > > standard constraints using the existing constraint definitions. > > Reload and co could check whether a back end accepts one of the > > standard constraint letters as extra constraint and would fallback to > > the standard behaviour if not. > > That sounds OK too, although I'm not the one you need to convince ;) I'll post a patch. Bye, -Andreas-