llvm dev - Sep 2012 - [LLVMdev] tablegen and ptr_rc: PointerLikeRegClass

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

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