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

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

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

X86 is using it. You could start by determining what PPC is doing differently.

/jakob

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

>
> 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