MachineOperand::TargetFlags question

I’m looking at utilizing the MachineOperand::TargetFlags and I’m wondering if there is a specific reason on limiting the size of the flags to 8 bits. Also are there any assumptions on what can be validly used here that I should keep in mind? Ideally I need 28 bits but I can code the major cases using all 8 bits, but I don’t want to clobber anything that might be used internally in LLVM.

Thanks for any feedback,

Micah

I’m looking at utilizing the MachineOperand::TargetFlags and I’m wondering if there is a specific reason on limiting the size of the flags to 8 bits.

We create *LOTS* of MachineOperand instances, so it needs to be as small as possible.

Also are there any assumptions on what can be validly used here that I should keep in mind? Ideally I need 28 bits but I can code the major cases using all 8 bits, but I don’t want to clobber anything that might be used internally in LLVM.

I think the target gets to decide what all the bits mean.

/jakob

In fact, it looks like we are losing 8 bytes to padding on hosts that align pointers to 8 bytes. MachineOperand ought to fit in 32 bytes on 64-bit hosts.

Someone should take a look at that.

I understand that there are lots of MachineOperands created, but I need a way to keep track of the channel that the operand utilizes within a vector register. Since my target uses 32x4 vector registers, I need to store at least 3 bits of information for each channel(x, y, z, w, _, 0, 1) in the fully generic case. In the most common case I only need 2 bits(x, y, z, w) and that will fit in the current size.

If there is a better way to do this, I'm open for suggestions. Otherwise I'll move forward with the TargetFlags.

Micah

Micah, you shouldn't encode this into TargetFlags, this should become an immediate operand of its own.

-Chris

I’m looking at utilizing the MachineOperand::TargetFlags and I’m wondering if there is a specific reason on limiting the size of the flags to 8 bits. Also are there any assumptions on what can be validly used here that I should keep in mind? Ideally I need 28 bits but I can code the major cases using all 8 bits, but I don’t want to clobber anything that might be used internally in LLVM.

Micah, you shouldn’t encode this into TargetFlags, this should become an immediate operand of its own.

-Chris

[Villmow, Micah] This is the approach I currently take, however I don’t like it because if I change an operand and it requires a change to the channel, I have to modify a different operand instead of modifying the current operand. I don’t want to differentiate between an immediate that is an actual compile time literal versus an immediate that is used to represent the channel swizzle. There should be a cleaner approach where this type of check isn’t required.