llvm dev - Nov 2012 - [LLVMdev] Tablegen and ptr_rc: PointerLikeRegClass

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

On Nov 15, 2012, at 2:54 PM, Will Schmidt <will_schmidt at vnet.ibm.com>
wrote:
> 
> Can anyone confirm or deny tablegen supporting PointerLikeRegClass?
X86 is using it. You could start by determining what PPC is doing differently.

/jakob

On Nov 15, 2012, at 2:54 PM, Will Schmidt <will_schmidt at vnet.ibm.com>
wrote:
> 
> (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. )
Hi Will,

I'm sorry, but this is too far paged out of my memory for me to be any
immediate help to you.

-Chris

On Thu, 2012-11-15 at 16:18 -0800, Jakob Stoklund Olesen
wrote:
> On Nov 15, 2012, at 2:54 PM, Will Schmidt <will_schmidt at
vnet.ibm.com> wrote:
> > 
> > Can anyone confirm or deny tablegen supporting PointerLikeRegClass?
> 
> X86 is using it. You could start by determining what PPC is doing
differently.
Yup,..  When I was looking into this before, I did scratch at the x86
usage, but was unable to make sense of how x86 was able to use it and
ppc was not.   I thought it may have been an issue with the order in
which some of the .td files were being included, but attempted changes
there brought me around to some class definition errors, (both unknown
and redefined varieties) and in reality I was just digging a deeper
hole. 

I'll take another look and see if anything pops out at me this time
around.

Thanks, 
-Will

> /jakob
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>