From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28782 invoked by alias); 31 Oct 2007 16:30:34 -0000 Received: (qmail 28643 invoked by uid 22791); 31 Oct 2007 16:30:32 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate5.de.ibm.com (HELO mtagate5.de.ibm.com) (195.212.29.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 31 Oct 2007 16:30:29 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id l9VGUQWL481722 for ; Wed, 31 Oct 2007 16:30:26 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.5) with ESMTP id l9VGUPEe2199798 for ; Wed, 31 Oct 2007 17:30:25 +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 l9VGUPPV030310 for ; Wed, 31 Oct 2007 17:30:25 +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 l9VGUOe1030296; Wed, 31 Oct 2007 17:30:24 +0100 Received: by lc4eb0107015440.ibm.com (sSMTP sendmail emulation); Wed, 31 Oct 2007 17:29:11 +0100 From: "Andreas Krebbel" Date: Wed, 31 Oct 2007 18:55:00 -0000 To: Richard Guenther Cc: gcc-patches@gcc.gnu.org Subject: Re: [PING] Target hook for rewriting inline asm constraints Message-ID: <20071031162911.GA13462@homer.boeblingen.de.ibm.com> References: <20071030115424.GA6864@homer.boeblingen.de.ibm.com> <84fc9c000710310830i10fb4bc5vd8c73a3ade568811@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84fc9c000710310830i10fb4bc5vd8c73a3ade568811@mail.gmail.com> 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-10/txt/msg01887.txt.bz2 Hi, > I also wonder how you can distinguish between "old" and "new" "m" used > in asms. How do you know which semantics the user chose? IMHO > "semantics" of asm constrains should never change, but instead you should > introduce new machine specific constraints if necessary. Actually the point of the target hook is to prevent the "m" constraint semantics from changing when the back end changes. Consider the case you want to add a new instruction to a back end. This new instruction supports loading a value from memory locations given by base + index register. All the existing instructions just accepted a single base register as memory address. In order to prevent reload from trying to reload all base + index addresses into a single base address register you have to change the GO_IF_LEGITIMATE_ADDRESS hook to accept base + index addresses. This change would depend on the availability of the new instruction supporting base + index like addresses so most likely it would depend on an architecture flag. As a consequence the "m" constraint also would accept base + index addresses for the added architecture. Unfortunately this breaks all places where one of the old instructions is coupled to the "m" constraint. Instruction patterns in the back end using the "m" constraint have to be changed. The straightforward solution would be to add a new constraint letter accepting memory addresses with just a single base register and replace all occurrences of "m" with that new constraint letter. But unfortunately our internally used constraint letters are exposed to the GCC user via the GCC inline assembly construct. So if you have an inline assembly containing one of the old instructions accepting just a base as address its operand constraint is probably the "m" constraint. If you now would compile the very same inline assembly setting the architecture flag which makes the back end to enable base + index addresses GCC will pass a base + index address for that operand which would make gas to complain about that instruction. The problem is that the "m" semantics changed but not the instruction in the inline assembly. To distingiush between the different "m" constraint versions the back end hook has to use the same logic which will be added to GO_IF_LEGITIMATE_ADDRESS. The new hook should replace every occurrence of "m" in an inline assembly operand list with the constraint letter for the former address format and it only has to do it for architecture flags which would change the behaviour of GO_IF_LEGITIMATE_ADDRESS (although it wouldn't be a problem to always do the rewrite). > The patch doesn't come with a testcase or an example showing how this > should work or how it would break without it, so it's hard to tell if you > have a point. But in general - asm constrains rewriting?? uh no. I don't have a testcase yet. But my explanations above probably give you an idea why this target hook is necessary sooner or later. Bye, -Andreas-