From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20739 invoked by alias); 5 Nov 2007 11:02:23 -0000 Received: (qmail 20729 invoked by uid 22791); 5 Nov 2007 11:02:22 -0000 X-Spam-Check-By: sourceware.org Received: from smtp.nildram.co.uk (HELO smtp.nildram.co.uk) (195.149.33.74) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 05 Nov 2007 11:02:20 +0000 Received: from firetop.home (85-211-133-69.dyn.gotadsl.co.uk [85.211.133.69]) by smtp.nildram.co.uk (Postfix) with ESMTP id F15832DEF9A; Mon, 5 Nov 2007 11:02:15 +0000 (GMT) Received: from richard by firetop.home with local (Exim 4.63) (envelope-from ) id 1Iozij-0008Sg-CC; Mon, 05 Nov 2007 11:02:17 +0000 From: Richard Sandiford To: "Andreas Krebbel" Mail-Followup-To: "Andreas Krebbel" ,gcc-patches@gcc.gnu.org, rsandifo@nildram.co.uk Cc: gcc-patches@gcc.gnu.org Subject: Re: [PING] Target hook for rewriting inline asm constraints 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> <20071105092430.GA7464@homer.boeblingen.de.ibm.com> <87ve8hxc1j.fsf@firetop.home> <20071105103043.GA8118@homer.boeblingen.de.ibm.com> Date: Mon, 05 Nov 2007 11:02:00 -0000 In-Reply-To: <20071105103043.GA8118@homer.boeblingen.de.ibm.com> (Andreas Krebbel's message of "Mon\, 5 Nov 2007 11\:30\:43 +0100") Message-ID: <87r6j5x8ee.fsf@firetop.home> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00188.txt.bz2 "Andreas Krebbel" writes: >> I don't understand. What I'm saying is that we should look through >> gcc/*.c for cases where the C construct "'m'" refers to "the constraint >> associated with legitimate addresses", and replace those cases with some >> target macro that is 'm' by default. E.g.: > ... >> and other places would change similarly. If we do that consistently, >> there would no longer be a connection between 'm' and >> GO_IF_LEGITIMATE_ADDRESS. > > Ok I see. The new TARGET_MEM_CONSTRAINT would have to be a hook > returning a new constraint letter for the architecture introducing the > new address format and 'm' otherwise - right ?! Well, I was thinking of making it a macro constant; I should have picked a name other than TARGET_MEM_CONSTRAINT, sorry. It might be nice to define the macro indirectly using a new constraints.md construct (define_general_memory_constraint?). I.e. have genpreds define the macro for you based on the .md file. The implementation could then move away from macros at the same time as the rest of the constraints stuff does[*]. I think that'd still be easier than converting gcc/*.c to treat 'm' as a hook (and easier than rewriting asms). But personally, I'd be happy enough if the macro was defined in the target .h file. Richard [*] E.g. we might eventually generate a constraints parser from the .md file. I can't remember now if that was an explicit goal of the constraints.md stuff.