From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26179 invoked by alias); 31 Oct 2007 17:22:51 -0000 Received: (qmail 26169 invoked by uid 22791); 31 Oct 2007 17:22:49 -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, 31 Oct 2007 17:22:38 +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 l9VHMa1C303424 for ; Wed, 31 Oct 2007 17:22:36 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 l9VHMZiA2277502 for ; Wed, 31 Oct 2007 18:22:36 +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 l9VHMZvn001537 for ; Wed, 31 Oct 2007 18:22:35 +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 l9VHMYJJ001529; Wed, 31 Oct 2007 18:22:34 +0100 Received: by lc4eb0107015440.ibm.com (sSMTP sendmail emulation); Wed, 31 Oct 2007 18:21:21 +0100 From: "Andreas Krebbel" Date: Wed, 31 Oct 2007 20:40:00 -0000 To: Richard Guenther Cc: gcc-patches@gcc.gnu.org Subject: Re: [PING] Target hook for rewriting inline asm constraints Message-ID: <20071031172121.GA14226@homer.boeblingen.de.ibm.com> References: <20071030115424.GA6864@homer.boeblingen.de.ibm.com> <84fc9c000710310830i10fb4bc5vd8c73a3ade568811@mail.gmail.com> <20071031162911.GA13462@homer.boeblingen.de.ibm.com> <84fc9c000710310943i7c45fadcs7f3558816218ffa3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84fc9c000710310943i7c45fadcs7f3558816218ffa3@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/msg01890.txt.bz2 Hi, > 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? Unfortunately this is not possible. The problem is that the GO_IF_LEGITIMATE_ADDRESS_P hook is coupled to the "m" constraint. Currently it isn't possible to change one without the other. But you *have* to add the new addressing mode the GO_IF_LEGITIMATE_ADDRESS_P hook otherwise these addresses would never pass the reload step. The definition of the "m" constraint is to accept every possible address the back end accepts. Or in the words of the interals manual: m: "A memory operand is allowed, with any kind of address that the machine supports in general." So you actually can't support new addressing formats in the back end without changing the semantics of it. The proper way would be to disallow the "m" constraint in inline assemblies but thats probably a bit late ;) > 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. I must admit that it is probably are rare case that an architecture changes so fundamentally that new address types are supported. But actually we already had such a change for S/390 - with the long displacement extension. Originally only Base + Index + 12 bit displacement addresses were supported. With the long displacement facility the discplacement was extended to 20 bit. Fortunately most of the instructions dealing with memory were extended transparently so it was decided to leave it as is but for 100% correctness we would have needed a mechanism like the "inline asm constraint rewrite hook" already for that change. Bye, -Andreas-