public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: James E Wilson <wilson@specifixinc.com>
To: Richard Sandiford <rsandifo@redhat.com>
Cc: gcc@gcc.gnu.org
Subject: Re: RFC: Using mode and code macros in *.md files
Date: Sun, 08 Aug 2004 04:30:00 -0000	[thread overview]
Message-ID: <411574A9.4000704@specifixinc.com> (raw)
In-Reply-To: <87vffux323.fsf@redhat.com>

Richard Sandiford wrote:
> This is an RFC about using mode and code macros in *.md files.
> I've attached a patch that implements the suggested constructs
> and an example of how they might be used in mips.md.

Some interesting stuff.

My first question would be how this affects debugging gcc.  Being able 
to match rtl insns to the md pattern for them is important.  These 
macros obscure the connection.  If I have a insn that has been 
recognized, and claims to match the slesi pattern, then I will be 
confused if I can't find such a pattern.  How am I supposed to know to 
look for the s<floatcond><mode> pattern instead?  The port maintainer 
would know this, but someone else wouldn't.  Maybe it would help to 
print md file line numbers instead of or in addition to pattern names 
when dumping rtl.

If I have an insn that hasn't been recognized, then I have a similar but 
slightly different problem.  If I try grepping for the operator (le:SI I 
am not going to find it.  How I am supposed to know to search for 
(<floatcond>:<mode> instead?

This stuff will probably work itself out eventually.  People will get 
used to the new syntax and learn to look for macros.

> For example, code macros allow us to combine 7 of the c.cond.fmt patterns:

You can already do this via match_operator.  Just define a predicate 
that accepts the 7 comparison codes you care about, and you can write a 
single pattern to patch all 7.  This gives a somewhat different affect 
though, as your macro approach gives 7 patterns whereas we only have one 
pattern if we use match_operator.

Match_operator has some of the same issues with respect to debugging. 
Once you use match_operator, it gets harder to find the pattern, as a 
simple grep for the operation code won't find the pattern that matches 
it.  Your proposal seems a little friendlier, since at least the macro 
definition is in the md file, whereas the match_operator predicate has 
to be in the .c file.

We should consider whether we need or want two different mechanisms that 
do the same thing.

If we don't need match_operator, then we also don't need match_op_dup.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

  reply	other threads:[~2004-08-08  0:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-07 18:38 Richard Sandiford
2004-08-08  4:30 ` James E Wilson [this message]
2004-08-08  8:43   ` Richard Sandiford
2004-08-09 18:29     ` James E Wilson
2004-08-09  9:02   ` Michael Matz
2004-08-09 18:09     ` James E Wilson
2004-08-10  8:57 ` Segher Boessenkool
2004-08-23 10:32 ` Zack Weinberg
2004-08-26 21:08   ` Richard Sandiford
2004-08-31 18:19     ` Steve Ellcey
2004-08-31 18:37       ` Richard Sandiford
2004-08-31 19:27         ` Joern Rennecke
2004-08-31 21:04         ` Steve Ellcey
2004-09-01 12:20           ` Joern Rennecke
2004-09-01 18:33             ` Steve Ellcey
2004-09-01 19:00               ` James E Wilson
2004-09-02 10:37               ` Joern Rennecke

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=411574A9.4000704@specifixinc.com \
    --to=wilson@specifixinc.com \
    --cc=gcc@gcc.gnu.org \
    --cc=rsandifo@redhat.com \
    /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).