From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9132 invoked by alias); 5 Nov 2007 09:25:52 -0000 Received: (qmail 9122 invoked by uid 22791); 5 Nov 2007 09:25:51 -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; Mon, 05 Nov 2007 09:25:50 +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 lA59PiOY380122 for ; Mon, 5 Nov 2007 09:25:44 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 lA59PfCm1544202 for ; Mon, 5 Nov 2007 10:25:42 +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 lA59Pf3C025488 for ; Mon, 5 Nov 2007 10:25:41 +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 lA59PeQG025450; Mon, 5 Nov 2007 10:25:40 +0100 Received: by lc4eb0107015440.ibm.com (sSMTP sendmail emulation); Mon, 05 Nov 2007 10:24:31 +0100 From: "Andreas Krebbel" Date: Mon, 05 Nov 2007 09:25:00 -0000 To: Richard Sandiford Cc: gcc-patches@gcc.gnu.org Subject: Re: [PING] Target hook for rewriting inline asm constraints Message-ID: <20071105092430.GA7464@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> <20071031172121.GA14226@homer.boeblingen.de.ibm.com> <87zlxty5l4.fsf@firetop.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zlxty5l4.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/msg00181.txt.bz2 > Sorry if this has already been suggested, but why not just replace > hard-coded uses of 'm' in constraint-handling code with uses of some > target macro? You could then treat your current 'm' as an ordinary > define_memory_constraint. I'm not sure this would work. I think reload relies on the relationship between the 'm' constraint and GO_IF_LEGITIMATE_ADDRESS. There is an early loop invoking find_reloads_address. This reloads all addresses which aren't supported by the target at all i.e. all addresses for which GO_IF_LEGITIMATE_ADDRESS is false (or does not jump to the given label). If reload later on sees an 'm' constraint it considers the address already been fixed by that early loop. So I would expect that in order to make such a hook work I would have to mess around with the reload logic which is not preferable I think. Bye, -Andreas-