Jakob Stoklund Olesen
2013-Mar-24 19:50 UTC
[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
Sebastian Pop
2013-Mar-25 19:50 UTC
[LLVMdev] Types in TableGen instruction selection patterns
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
Jakob Stoklund Olesen
2013-Mar-25 19:55 UTC
[LLVMdev] Types in TableGen instruction selection patterns
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
2013-Mar-25 19:58 UTC
[LLVMdev] Types in TableGen instruction selection patterns
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 slightlydifferent 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
Tom Stellard
2013-Apr-20 04:55 UTC
[LLVMdev] Types in TableGen instruction selection patterns
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
Jakob Stoklund Olesen
2013-Apr-20 17:07 UTC
[LLVMdev] Types in TableGen instruction selection patterns
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
Maybe Matching Threads
- [LLVMdev] Types in TableGen instruction selection patterns
- [LLVMdev] Types in TableGen instruction selection patterns
- [LLVMdev] Types in TableGen instruction selection patterns
- [LLVMdev] returning a double in two registers
- [LLVMdev] returning a double in two registers