How do I determine what type of register(i.e. i32, f32, etc..) I am
accessing from a MachineOperand? I.e. how do I get to the MVT struct, or
equivalent information, from a MachineOperand object?
Micah Villmow
Systems Engineer
Advanced Technology & Performance
Advanced Micro Devices Inc.
4555 Great America Pkwy,
Santa Clara, CA. 95054
P: 408-572-6219
F: 408-572-6596
You can get to the MachineInstr from a MachineOperand. Then get to its TargetInstrDesc and TargetOperandInfo which has register class information.
Evan
This only has the register class information, not the register type
information.
My register class has multiple register types and I need to know how to
differentiate which register type of my register class of the current
register.
The information in the MVT data type is what I need, i.e. the position
in the GPRVT array of each register.
Something equivalent to MVT getValueType() but for registers.
Thanks,
To my knowledge, I don’t think there is an easy way to get the MVT information from a MachineOperand. Why do you need it for? In my mind, the MachineInstr and its associated operands represent a physical machine instruction and I typically want to think of those as machine opcodes and machine register files. I am typically interested in the mapping of MVTs to register classes when I’m generating machine instructions. Note that a register class may map to multiple MVTs depending on your description.
– Mon Ping
To my knowledge, I don't think there is an easy way to get the MVT
information from a MachineOperand. Why do you need it for? In my
See the thread I started on this very topic. Spilling is one place you'd like
to have this information.
mind, the MachineInstr and its associated operands represent a
physical machine instruction and I typically want to think of those as
machine opcodes and machine register files. I am typically interested
in the mapping of MVTs to register classes when I'm generating machine
instructions. Note that a register class may map to multiple MVTs
depending on your description.
Right, but the instruction opcode should give a clue about what the bits
represent. That mapping is what's currently missing.
-Dave
Yes,
Another reason this is useful is for register-type specific
representations of said register.
For example, all my registers are 128bit vector registers, however, if I
am only dealing with 32 bit vector registers, I can add write/read masks
that tell the underlying hardware not to work on the whole register, but
just a subset of the components.
32bit scalar mov: mov r1.x___, r0.x000
64bit scalar mov: mov r1.xy__, r0.xy00
96bit scalar mov: mov r1.xyz_, r0.xyz0
128bit scalar mov: mov r1, r0
If I had the register type information at code generation time, then I
can use the exact same tablegen pattern for all my register types and
would only need to add the write/read masks in the printer instead of
multiple patterns.
Multiply this by over 100 opcodes and I save A LOT of work.
Sounds like you should specify a few class of pseudo registers mapped to the same set of registers. This is something we are considering for x86. That is, have xmm0_64, xmm0_32, and xmm0 all mapping to xmm0. If the first one is used, it means only the lower 64-bits are needed.
An alternative is to encode such information in the opcode or as a pseudo immediate operand. Or, in the worst case, you can just iterate through all the uses / defs to determine the type
Type information just doesn't belong on MachineOperand's. They belong to machine instructions, i.e. how they are defined / used.
Evan