dumb question about tblgen

Dumb question about llvm-tblgen for “XyzGenInstrInfo.inc”

If I have a pattern in my dot-td-file like this

[(set i32:$dst (add i32:$rs1, i32:$rs2))]

The question is where does the token “i32” come from,

I don’t see any definitions for i1, i8, i16, i32, … in

include/llvm/Target/*.td

while I do see definitions for tokens like “set”, “add”, …

coming from

include/llvm/Target/TargetSelectionDAG.td

presumably these tokens are related to the enum in

include/llvm/CodeGen/MachineValueType.h

but how does tblgen know about them,

To put the question into context, if I add an item to the enum in “MachineValueType.h”

What do I do about

“error: Variable not defined:”

Coming from tblgen when I try to use it in my dot-td-file,

I’ve already tried re-building tblgen, but that didn’t help.

thanks,

–Peter Lawrence.

Hi Peter,

I would recommend looking into the implementation of the matcher if you want to add more builtin types:
utils/TableGen//DAGISelMatcherGen.cpp

That being said, you can define your own types without having to go through that hassle.
E.g., from AArch64
def simm9 : Operand<i64>, ImmLeaf<i64, [{ return Imm >= -256 && Imm < 256; }]> {
  let ParserMatchClass = SImm9Operand;
}

Wouldn’t that work for you?

Cheers,
-Quentin

Quentin,

My real problem is that my target has separate address and data registers.

The way I’d like to try getting better reg-alloc than I am now is to bring out the difference as

Early as possible, so I have added p16, p32, p64 to the enum in “MachineValueType.h”

And I have called addRegisterClass(MVT::p32, &XyzAddrRegsRegClass);

And I have an override for virtual TargetLowering::getPointerTy() that returns MVT::p32,

And some other minor changes that altogether cause virt-regs that contain pointers

To get my AddrRegs reg-class rather than the “GPR” reg-class that i32 types get.

So far so good, except that llvm-tblgen barfs on “p32”, so the question remains,

How does tblgen know the symbol names “i16”, “i32”, “i64”, etc…

They don’t seem to come from explicit “def” statements like the symbols “add”, “sub”, etc… do

Unless I’m missing something obvious (wouldn’t be the first time!)

And I’m mystified because my interpretation of reading “utils/TableGen/TableGen.cpp”

And “lib/TableGen/Main.cpp”, Is that the input is fully read and parsed before the backend is invoked,

So the back-end can’t be providing symbol-table init for the front-end,

So the definitions have to be in the input source, but I can’t find them…

Thanks, Peter Lawrence.

I don’t quite follow why you are doing something like this.

What is the advantage of this instead of just attaching the AddrRegs regsister class as the register class for your instruction?
So that you would have an ADD instruction like
%AddrRegOut = ADD %AddrRegIn1, %AddrRegIn2

What kind of problematic regalloc are you trying to avoid with introducing a new backend data type?

Marcello

The i32 class is defined in include/llvm/CodeGen/ValueTypes.td along with a class for every type in MachineValueTypes.h

Craig,

Ahha, thanks.

Even with that info I had to resort to “find-grep” to figure out how it gets #included,

Being indirectly included from “include/llvm/IR/Intrinsics.td” isn’t exactly obvious :=((

Would it be possible move the #include into “Target.td” ?

Also, in “ValueTypes.td” there is a comment about needing to keep it coordinated

With “MahineValueType.h”, but there is no such comment in “MachineValueType.h”,

Would it be possible for someone to add such a complementary comment ?

Thanks,

–Peter Lawrence.

There is a comment in MachineValueTypes.h in the enum.

// If you change this numbering, you must change the values in

// ValueTypes.td as well!
Other = 0, // This is a non-standard value

I don’t think the .td include can be fixed easily. Tablegen doesn’t support include guards and can only include each file once. Looks like there is a build step that runs tablegen directly on Intrinsics.td so that file needs to include ValueTypes.td on its own.

Marcello,

The short answer is this, like you say the register-class for target machine instructions comes from that instructions’ pattern, but this is not the case for CopyFromReg and CopyToReg machine instructions, those are “machine-independent” machine instructions, you currently have little control over what register-class gets associated with them, in fact the register-class they get is derived from the MVT, and there is currently no MVT that means “pointer” (yes, there is MVT::iPTR, but that is not a pointer, it is an integer with the same size as a pointer, and IIUC it always gets replaced with an explicitly sized integer type).

The long answer would have a description of how other compilers are typically more explicit in distinguishing between “local” virtual registers (only live in a single BB) and “global” virtual registers (live across more than a single BB). In LLVM “local” virtual registers don’t exist in the SelectionDAG, but “global” virtual registers are what appear in CopyToReg and CopyFromReg instructions. It is the register-class of these “global” virtual registers that I need to control to get “better register allocation” than I am already getting by having address-register-class specifications on my pointer-arithmetic instructions.

If you have any better ideas I’m all ears. It is conceivable that re-designing the logic around “MVT::iPTR” could be made to work, but I don’t know enough yet about TableGen and CodeGen to say whether that is possible, or even plausible, and then the notion of “an integer the same size as a pointer” is a fairly firmly established concept, it might not be prudent to mess with it.

Thanks,

–Peter Lawrence.

Craig,

I would humbly ask that “Target.td” be edited to include a commented out include of ValueTypes.td (just ahead of the include of Intrinsics.td) with an appropriate comment in the include line so that you see it when you grep for “include”

Secondly, the files “ValueTypes.td” and “MachineValueType.h” are redundant, and in a more typical system one would be generated from the other and “make” would keep them in sync, since that isn’t currently the case here both source files need top level comments to explain the situation and the need to manually keep the files in sync. Such a comment needs to be in extreme bold case at the top of both files, it has to be impossible to not notice.

Thanks,

–Peter Lawrence.