From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3901 invoked by alias); 31 Oct 2007 16:43:32 -0000 Received: (qmail 3891 invoked by uid 22791); 31 Oct 2007 16:43:31 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.182) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 31 Oct 2007 16:43:27 +0000 Received: by py-out-1112.google.com with SMTP id a29so432011pyi for ; Wed, 31 Oct 2007 09:43:25 -0700 (PDT) Received: by 10.65.95.12 with SMTP id x12mr1577983qbl.1193849003077; Wed, 31 Oct 2007 09:43:23 -0700 (PDT) Received: by 10.65.232.20 with HTTP; Wed, 31 Oct 2007 09:43:23 -0700 (PDT) Message-ID: <84fc9c000710310943i7c45fadcs7f3558816218ffa3@mail.gmail.com> Date: Wed, 31 Oct 2007 19:13:00 -0000 From: "Richard Guenther" To: "Andreas Krebbel" Subject: Re: [PING] Target hook for rewriting inline asm constraints Cc: gcc-patches@gcc.gnu.org In-Reply-To: <20071031162911.GA13462@homer.boeblingen.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071030115424.GA6864@homer.boeblingen.de.ibm.com> <84fc9c000710310830i10fb4bc5vd8c73a3ade568811@mail.gmail.com> <20071031162911.GA13462@homer.boeblingen.de.ibm.com> X-IsSubscribed: yes 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/msg01889.txt.bz2 On 10/31/07, Andreas Krebbel wrote: > 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). Why not leave "m" as is, even with the new addressing mode and add a new constraint allowing the new base + index addressing mode. This way existing patterns and inline asm will continue to work (it couldn't know about the new addressing mode or instructions anyway) and if one wants to use the new stuff use the new constraint? Are you suggesting the rewriting for optimization (I think you do)? Or do you believe there is no way you can keep correctness without the patch (I don't believe that)? > > 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. The only thing I could imagine would be that the new architecture forces you to use base + index addressing, but only on _some_ insns. So where insn0 %0 insn1 %1 with both "m" constraints would be valid before, only (and truly only) the second insn1 is now forced to do base + index addressing? That is, you have to split semantics of "m" based on the instruction it is used in? Which is the root of my doubt that you can automatically rewrite "m"s in any case - or proves that this is not the situation you need to handle. Richard.