RFC: Using mode and code macros in *.md files

[James E Wilson]

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