llvm dev - Mar 2013 - [LLVMdev] Types in TableGen instruction selection patterns

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

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
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The
Linux Foundation

On Mar 25, 2013, at 12:50 PM, Sebastian Pop <spop at codeaurora.org>
wrote:
> 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))]>;
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

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
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The
Linux Foundation

On Sun, Mar 24, 2013 at 12:50:02PM -0700, 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. 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

On Apr 19, 2013, at 9:55 PM, Tom Stellard <tom at stellard.net> wrote:
> 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?
It's a bit annoying, but COPY_TO_REGCLASS does the trick.

/jakob