Types in TableGen instruction selection patterns

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Types in TableGen instruction selection patterns

Jakob Stoklund Olesen-2
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


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Types in TableGen instruction selection patterns

Sebastian Pop-7
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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Types in TableGen instruction selection patterns

Jakob Stoklund Olesen-2

On Mar 25, 2013, at 12:50 PM, Sebastian Pop <[hidden email]> 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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Types in TableGen instruction selection patterns

Sebastian Pop-7
In reply to this post by Sebastian Pop-7
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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Types in TableGen instruction selection patterns

Jakob Stoklund Olesen-2

On Mar 25, 2013, at 12:58 PM, Sebastian Pop <[hidden email]> wrote:

> 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))]>;

Yes, that is exactly how it should be done.

Thanks, Ulrich!

/jakob

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Types in TableGen instruction selection patterns

Tom Stellard-3
In reply to this post by Jakob Stoklund Olesen-2
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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Types in TableGen instruction selection patterns

Jakob Stoklund Olesen-2

On Apr 19, 2013, at 9:55 PM, Tom Stellard <[hidden email]> 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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev