[LLVMdev] Tablegen and ptr_rc: PointerLikeRegClass

[Will Schmidt]

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