public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <rsandifo@nildram.co.uk>
To: "Andreas Krebbel" <Andreas.Krebbel@de.ibm.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PING] Target hook for rewriting inline asm constraints
Date: Mon, 05 Nov 2007 11:02:00 -0000	[thread overview]
Message-ID: <87r6j5x8ee.fsf@firetop.home> (raw)
In-Reply-To: <20071105103043.GA8118@homer.boeblingen.de.ibm.com> (Andreas 	Krebbel's message of "Mon\, 5 Nov 2007 11\:30\:43 +0100")

"Andreas Krebbel" <Andreas.Krebbel@de.ibm.com> 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.

  reply	other threads:[~2007-11-05 11:02 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-30 12:54 Andreas Krebbel
2007-10-31 16:31 ` Tom Tromey
2007-10-31 16:43   ` Richard Guenther
2007-10-31 18:55     ` Andreas Krebbel
2007-10-31 19:13       ` Richard Guenther
2007-10-31 20:40         ` Andreas Krebbel
2007-11-04 23:05           ` Richard Sandiford
2007-11-05  9:25             ` Andreas Krebbel
2007-11-05  9:43               ` Richard Sandiford
2007-11-05 10:32                 ` Andreas Krebbel
2007-11-05 11:02                   ` Richard Sandiford [this message]
2007-11-05 13:42                     ` Andreas Krebbel
2007-11-06 22:00                       ` Richard Sandiford
2007-11-07 11:55                         ` Andreas Krebbel
2007-10-31 17:22   ` Andreas Krebbel
2007-10-31 17:56     ` Tom Tromey
2007-11-06 18:20 ` Michael Meissner
2007-11-07  9:10   ` Andreas Krebbel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r6j5x8ee.fsf@firetop.home \
    --to=rsandifo@nildram.co.uk \
    --cc=Andreas.Krebbel@de.ibm.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).