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

[Zack Weinberg <zack@codesourcery.com>]

Richard Sandiford <rsandifo@redhat.com> writes:

> 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.

This is rather belated, but I'd like to throw in a few comments.  In
general I really like this, it looks like it's got potential to make
it much easier to write machine descriptions.  I've got some
suggestions, though, which which I think can be implemented as
incremental improvements to the patch you've already got.

First thing is, Pmode is a bit of a special case.  For one thing,
we've got a "pmode_register_operand" predicate which does exactly what
you want for *this* use of Pmode.  You could write

        (define_insn "indirect_jump_internal"
          [(set (pc) (match_operand 0 "pmode_register_operand" "d"))]
          ""
          "%*j\t%0%/"
          [(set_attr "type" "jump")
           (set_attr "mode" "none")])

However, this doesn't help with any other place where one would like
to use a :P mode suffix.  And I agree that :P should work.

The other way Pmode is special is that it's already defined by every
target, and it would be nice if every target didn't have to re-specify
it with a mode macro in order to get it to work in the machine
description.  When Pmode is a compile-time constant, in fact, you
ought to get the same code out of gen* that you would if you
search-and-replaced every :P in the machine description with the
underlying mode.

When it's not a compile-time constant the question becomes more
difficult, but I think it's still doable; one has to think carefully
about the code that genrecog would have to emit, but the rest of the
generated code doesn't change much.

The other thing I wonder about is extension to places where the
pattern varies, not just the strings.  For instance, consider the
floating point patterns in ia64.md.  Notionally, every DFmode pattern
is multiplied fourfold, like so:

(define_insn "adddf3"
  [(set (match_operand:DF 0 "fr_register_operand" "=f")
        (plus:DF (match_operand:DF 1 "fr_register_operand" "%f")
                 (match_operand:DF 2 "fr_reg_or_fp01_operand" "fG")))]
  ""
  "fadd.d %0 = %1, %F2"
  [(set_attr "itanium_class" "fmac")])

(define_insn "*adddf3_alts"
  [(set (match_operand:DF 0 "fr_register_operand" "=f")
        (plus:DF (match_operand:DF 1 "fr_register_operand" "%f")
                 (match_operand:DF 2 "fr_reg_or_fp01_operand" "fG")))
   (use (match_operand:SI 3 "const_int_operand" ""))]
  ""
  "fadd.d.s%4 %0 = %1, %F2"
  [(set_attr "itanium_class" "fmac")])

(define_insn "*adddf3_trunc"
  [(set (match_operand:SF 0 "fr_register_operand" "=f")
        (float_truncate:SF
          (plus:DF (match_operand:DF 1 "fr_register_operand" "%f")
                   (match_operand:DF 2 "fr_reg_or_fp01_operand" "fG"))))]
  ""
  "fadd.s %0 = %1, %F2"
  [(set_attr "itanium_class" "fmac")])

(define_insn "*adddf3_trunc_alts"
  [(set (match_operand:SF 0 "fr_register_operand" "=f")
        (float_truncate:SF
          (plus:DF (match_operand:DF 1 "fr_register_operand" "%f")
                   (match_operand:DF 2 "fr_reg_or_fp01_operand" "fG"))))
   (use (match_operand:SI 3 "const_int_operand" ""))]
  ""
  "fadd.s.s%4 %0 = %1, %F2"
  [(set_attr "itanium_class" "fmac")])

You won't actually find these "_alts" patterns in ia64.md, because
they haven't been added consistently, but you will find the "_trunc"
variant.  Now, this was definitely out of scope of your original
patch, and (since the extra patterns are for matching only) it might
be feasible to use match_operator for them.  In fact, that's on my
list of things to try in the near future.  But if I do do it with
match_operator, the result may not be all that readable, and the code
one has to write for a nontrivial match_operator predicate isn't
exactly nice, either.  So I'm curious if you have any ideas for how to
handle this sort of thing.

zw