Hi all, I've been poking at AsmParser support for powerpc64 (ppc64-elf-linux-abi) and have run into some behavior I don't understand with the ptr_rc references coming out of the PPC*.td files when generating the asm-matcher files. For instance : $ ./build/bin/llvm-tblgen llvm/lib/Target/PowerPC/PPC.td -I ~/llvm-head/llvm/include -I ~/llvm-head/llvm/lib/Target/PowerPC/ -gen-asm-matcher <...> Included from llvm/lib/Target/PowerPC/PPC.td:16: /home/willschm/llvm-head/llvm/include/llvm/Target/Target.td:494:1: error: Operand `ptr_rc' does not derive from class Operand! def ptr_rc : PointerLikeRegClass<0>; ^ The comments in Target.td suggest to me that tablegen should be able to handle this in some way, but it's not clear to me what I'm missing that would enable this to begin working. /// PointerLikeRegClass - ... TableGen treats the register class as having a symbolic /// type that it doesn't know, and resolves the actual regclass to use by using /// the TargetRegisterInfo::getPointerRegClass() hook at codegen time. I do see ptr_rc and ptr_rc_nosp references in X86/X86InstrInfo.td ; but I can't tell how or why it works differently there than in PowerPC/PPCInstr64Bit.td Thoughts/comments/suggestions? Thanks, -Will
Will Schmidt
2012-Sep-19 23:41 UTC
[LLVMdev] "Unknown node flavor ..." Was: Re: tablegen and ptr_rc: PointerLikeRegClass
On Fri, 2012-09-14 at 13:10 -0500, Will Schmidt wrote:> Hi all, > > I've been poking at AsmParser support for powerpc64 > (ppc64-elf-linux-abi) and have run into some behavior I don't understand > with the ptr_rc references coming out of the PPC*.td files when > generating the asm-matcher files. > > For instance : > $ ./build/bin/llvm-tblgen llvm/lib/Target/PowerPC/PPC.td -I > ~/llvm-head/llvm/include -I ~/llvm-head/llvm/lib/Target/PowerPC/ > -gen-asm-matcher > > <...> > > Included from llvm/lib/Target/PowerPC/PPC.td:16: > /home/willschm/llvm-head/llvm/include/llvm/Target/Target.td:494:1: > error: Operand `ptr_rc' does not derive from class Operand! > > def ptr_rc : PointerLikeRegClass<0>; > ^ > > > The comments in Target.td suggest to me that tablegen should be able to > handle this in some way, but it's not clear to me what I'm missing that > would enable this to begin working. > > /// PointerLikeRegClass - ... TableGen treats the register class as having a symbolic > /// type that it doesn't know, and resolves the actual regclass to use by using > /// the TargetRegisterInfo::getPointerRegClass() hook at codegen time. > > I do see ptr_rc and ptr_rc_nosp references in X86/X86InstrInfo.td ; but I can't > tell how or why it works differently there than in PowerPC/PPCInstr64Bit.td > > > Thoughts/comments/suggestions?I've been poking at this a bit more, and have tried wrapping the ptr_rc within a larger blob; I'm getting different error messages out, but can't tell whether or not this is progress. Using the memri definitions as inspiration: +def ptr_rc_wrapper : Operand<iPTR> { + let PrintMethod = "printMemRegImm"; + let MIOperandInfo = (ops ptr_rc:$ea_result); +} And then swapping out the ptr_rc: references like so: -def LBZU : DForm_1<35, (outs GPRC:$rD, ptr_rc:$ea_result), (ins memri: $addr), +def LBZU : DForm_1<35, (outs GPRC:$rD, ptr_rc_wrapper:$ea_result), (ins memri:$addr), "lbzu $rD, $addr", LdStLoadUpd, []>, RegConstraint<"$addr.reg = $ea_result">, NoEncode<"$ea_result">; I now get an "Unknown node flavor used in pattern: ptr_rc_wrapper". I.e.: llvm[3]: Building PPC.td instruction information with tblgen STBU: (set ptr_rc_wrapper:<empty>:$ea_res, (ist:iPTR GPRC:i32:$rS, ptr_rc_wrapper:iPTR:$ptrreg, iaddroff:iPTR: $ptroff)<<P:Predicate_itruncstore>><<P:Predicate_pre_truncst>><<P:Predicate_pre_truncsti8>>) Included from /home/willschm/dev/llvm.gitmirror/llvm/lib/Target/PowerPC/PPC.td:68: /home/willschm/dev/llvm.gitmirror/llvm/lib/Target/PowerPC/PPCInstrInfo.td:825:1: error: In STBU: Unknown node flavor used in pattern: ptr_rc_wrapper Help! Thanks, -Will> > Thanks, > -Will > > >
On Wed, 2012-09-19 at 18:41 -0500, Will Schmidt wrote:> On Fri, 2012-09-14 at 13:10 -0500, Will Schmidt wrote: > > Hi all, > > > > I've been poking at AsmParser support for powerpc64 > > (ppc64-elf-linux-abi) and have run into some behavior I don't understand > > with the ptr_rc references coming out of the PPC*.td files when > > generating the asm-matcher files. > > > > For instance : > > $ ./build/bin/llvm-tblgen llvm/lib/Target/PowerPC/PPC.td -I > > ~/llvm-head/llvm/include -I ~/llvm-head/llvm/lib/Target/PowerPC/ > > -gen-asm-matcher > > > > <...> > > > > Included from llvm/lib/Target/PowerPC/PPC.td:16: > > /home/willschm/llvm-head/llvm/include/llvm/Target/Target.td:494:1: > > error: Operand `ptr_rc' does not derive from class Operand! > > > > def ptr_rc : PointerLikeRegClass<0>; > > ^ > > > > > > The comments in Target.td suggest to me that tablegen should be able to > > handle this in some way, but it's not clear to me what I'm missing that > > would enable this to begin working. > > > > /// PointerLikeRegClass - ... TableGen treats the register class as having a symbolic > > /// type that it doesn't know, and resolves the actual regclass to use by using > > /// the TargetRegisterInfo::getPointerRegClass() hook at codegen time. > > > > I do see ptr_rc and ptr_rc_nosp references in X86/X86InstrInfo.td ; but I can't > > tell how or why it works differently there than in PowerPC/PPCInstr64Bit.td > > > > > > Thoughts/comments/suggestions? > > I've been poking at this a bit more, and have tried wrapping the ptr_rc > within a larger blob; I'm getting different error messages out, but > can't tell whether or not this is progress. > > Using the memri definitions as inspiration: > +def ptr_rc_wrapper : Operand<iPTR> { > + let PrintMethod = "printMemRegImm"; > + let MIOperandInfo = (ops ptr_rc:$ea_result); > +} > > And then swapping out the ptr_rc: references like so: > > -def LBZU : DForm_1<35, (outs GPRC:$rD, ptr_rc:$ea_result), (ins memri: > $addr), > +def LBZU : DForm_1<35, (outs GPRC:$rD, ptr_rc_wrapper:$ea_result), (ins > memri:$addr), > "lbzu $rD, $addr", LdStLoadUpd, > []>, RegConstraint<"$addr.reg = $ea_result">, > NoEncode<"$ea_result">; > > > I now get an "Unknown node flavor used in pattern: ptr_rc_wrapper". > I.e.: > llvm[3]: Building PPC.td instruction information with tblgen > STBU: (set ptr_rc_wrapper:<empty>:$ea_res, (ist:iPTR GPRC:i32:$rS, > ptr_rc_wrapper:iPTR:$ptrreg, iaddroff:iPTR: > $ptroff)<<P:Predicate_itruncstore>><<P:Predicate_pre_truncst>><<P:Predicate_pre_truncsti8>>) > Included > from /home/willschm/dev/llvm.gitmirror/llvm/lib/Target/PowerPC/PPC.td:68: > /home/willschm/dev/llvm.gitmirror/llvm/lib/Target/PowerPC/PPCInstrInfo.td:825:1: error: In STBU: Unknown node flavor used in pattern: ptr_rc_wrapper > > > Help!Ping! (Chris, looks like you may have been both the first and last person to really touch PointerLikeRegClass since it was added in '09, so I've added you to cc directly. ) I've had this one on a way way back back-burner, but per some test case requirements and commentary on the recent powerpc patches from Uli it's time to poke this some more. The previously noted issue (also http://llvm.org/bugs/show_bug.cgi?id=14011 ) still exists against current llvm trunk, that running tablegen -gen-asm-matcher against the existing ppc.td file results in an error involving the ptr_rc operand, which is itself defined as PointerLikeRegClass<0>. Example: $ ./build/bin/llvm-tblgen llvm/lib/Target/PowerPC/PPC.td -I ~/llvm-head/llvm/include -I ~/llvm-head/llvm/lib/Target/PowerPC/ -gen-asm-matcher <...> Included from llvm/lib/Target/PowerPC/PPC.td:16: /home/willschm/llvm-head/llvm/include/llvm/Target/Target.td:494:1: error: Operand `ptr_rc' does not derive from class Operand! def ptr_rc : PointerLikeRegClass<0>; ^ Comments in Target.td suggest that tablegen has support for PointerLikeRegClass. So I am either misinterpreting the comment, or the support is incomplete. Can anyone confirm or deny tablegen supporting PointerLikeRegClass? /// PointerLikeRegClass - ... TableGen treats the register class as having a symbolic /// type that it doesn't know, and resolves the actual regclass to use by using /// the TargetRegisterInfo::getPointerRegClass() hook at codegen time. If the answer is to wrap the ptr_rc references in a larger blob that is derived from the Operand class, I then hit the "Unknown node flavor" error as noted in the email I am replying to... Thanks, -Will