Types in TableGen instruction selection patterns

Project Infrastructure LLVM Dev List Archives
1

I have updated TableGen to support a new format for instruction selection patterns.

Before:

  def : Pat<(subc IntRegs:$b, IntRegs:$c), (SUBCCrr IntRegs:$b, IntRegs:$c)>;

After:

  def : Pat<(subc i32:$b, i32:$c), (SUBCCrr $b, $c)>;

Since the pattern matching happens on a DAG with type labels, not register classes, I think it makes more sense to specify types directly on the input patterns. The new syntax also helps avoid the problem where TableGen emits lots of type inference errors when multiple types are added to a register class.

In the output pattern, it is no longer necessary to duplicate the register classes or types of register operands.

For immediate operands, the 'imm' tag is still required:

  def : Pat<(subc i32:$b, simm13:$val), (SUBCCri $b, imm:$val)>;

I would like for the old register class notation to go away eventually.

/jakob

2

Jakob Stoklund Olesen wrote:

I have updated TableGen to support a new format for instruction selection patterns.

Before:

  def : Pat<(subc IntRegs:$b, IntRegs:$c), (SUBCCrr IntRegs:$b, IntRegs:$c)>;

After:

  def : Pat<(subc i32:$b, i32:$c), (SUBCCrr $b, $c)>;

Since the pattern matching happens on a DAG with type labels, not register
classes, I think it makes more sense to specify types directly on the input
patterns.

Does it make sense to also make this mechanism available in the definition of
instructions' matching code , this is the only other place I see where this
same mechanism could be useful. It would be nice to be able to write this:

  def insn : Inst<(outs i32:$dst), (ins i32:$src1, i32:$src2),
            "some assembler",
            [(set $dst, (Op $src1, $src2))]>;

The new syntax also helps avoid the problem where TableGen emits
lots of type inference errors when multiple types are added to a register
class.

This is nice! Thanks for the cleanup!

Sebastian

3

No, the ins and outs lists must contain register classes. They define the encoding constraints of the instruction operands.

But you should put types in the patterns instead of register classes:

def STFrr : F3_1<3, 0b100100,
                   (outs), (ins MEMrr:$addr, FPRegs:$src),
                   "st $src, [$addr]",
                   [(store f32:$src, ADDRrr:$addr)]>;

/jakob

4

Sebastian Pop wrote:

same mechanism could be useful. It would be nice to be able to write this:

  def insn : Inst<(outs i32:$dst), (ins i32:$src1, i32:$src2),
            "some assembler",
            [(set $dst, (Op $src1, $src2))]>;

From the PPC changes, I see that this is already possible under a slightly

different form:

   def FSUBS : AForm_2<59, 20,
                       (outs F4RC:$FRT), (ins F4RC:$FRA, F4RC:$FRB),
                       "fsubs $FRT, $FRA, $FRB", FPGeneral,
- [(set F4RC:$FRT, (fsub F4RC:$FRA, F4RC:$FRB))]>;
+ [(set f32:$FRT, (fsub f32:$FRA, f32:$FRB))]>;

Sebastian

5

Yes, that is exactly how it should be done.

Thanks, Ulrich!

/jakob

6

I have updated TableGen to support a new format for instruction selection patterns.

Before:

  def : Pat<(subc IntRegs:$b, IntRegs:$c), (SUBCCrr IntRegs:$b, IntRegs:$c)>;

After:

  def : Pat<(subc i32:$b, i32:$c), (SUBCCrr $b, $c)>;

Since the pattern matching happens on a DAG with type labels, not register classes, I think it makes more sense to specify types directly on the input patterns. The new syntax also helps avoid the problem where TableGen emits lots of type inference errors when multiple types are added to a register class.

In the output pattern, it is no longer necessary to duplicate the register classes or types of register operands.

For immediate operands, the 'imm' tag is still required:

  def : Pat<(subc i32:$b, simm13:$val), (SUBCCri $b, imm:$val)>;

I would like for the old register class notation to go away eventually.

Hi Jakob,

I'm going through the R600 target and converting all the patterns to the
new syntax, and I've come across a pattern that I'm unable to convert:

class BitConvert <ValueType dt, ValueType st, RegisterClass rc> : Pat <
  (dt (bitconvert (st rc:$src0))),
  (dt rc:$src0)

;

def : BitConvert <i32, f32, R600_Reg32>;

In this example R600_Reg32 is a register that can hold f32 or i32
types, so bitconvert is a free operation. Any suggestions for how to
re-work this pattern?

Thanks,
Tom

7

It's a bit annoying, but COPY_TO_REGCLASS does the trick.

/jakob