similar to: [LLVMdev] MVT (machine value type) for MachineOperand

For the registers on register operands you can query MachineRegisterInfor for their Class. The registerclass should have a list of possible types (usually with the same size in bits) assigned. - Matthias > On May 28, 2015, at 8:11 AM, Fabian Gruber <fabian.gruber at fadeopolis.com> wrote: > > Hi, > > I am writing a small tool to gather some static statistics on machine

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

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

You can get to the MachineInstr from a MachineOperand. Then get to its TargetInstrDesc and TargetOperandInfo which has register class information. Evan On Sep 23, 2008, at 12:44 PM, Villmow, Micah wrote: > 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

Is there an easy way to get the MVT::ValueType of a MachineInstruction MachineOperand? For example, the register operand of an x86 MOVAPD should have an MVT::ValueType of v2f64. A MOVAPS register operand should have an MVT::ValueType of v4f32. So given a MachineInstruction and its MachineOperands is there some easy way to derive this information? I don't see anything in TargetInstrInfo

On Wednesday 24 September 2008 15:23, Mon Ping Wang wrote: > 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 >

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

On Sep 2, 2008, at 10:42 AM, David Greene wrote: > Is there an easy way to get the MVT::ValueType of a MachineInstruction > MachineOperand? For example, the register operand of an x86 MOVAPD > should > have an MVT::ValueType of v2f64. A MOVAPS register operand should > have an > MVT::ValueType of v4f32. The short answer is no. A op of a number of different VTs can map to

On Tuesday 02 September 2008 16:47, Evan Cheng wrote: > On Sep 2, 2008, at 10:42 AM, David Greene wrote: > > Is there an easy way to get the MVT::ValueType of a MachineInstruction > > MachineOperand? For example, the register operand of an x86 MOVAPD > > should > > have an MVT::ValueType of v2f64. A MOVAPS register operand should > > have an > >

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

I have a MachineOperand that could be something other than a Reg: mem, global address, imm, etc... I want to replace a reg MachineOperand with this non-reg MachineOperand. I've tried a few different things, but it doesn't seem like there is some simple functionality to do this? "RemoveOperand" and "addOperand" does not work. There doesn't seem to be a valid

Is there any way to determine if a Register-type MachineOperand represents a fixed machine register? For example, call arguments must end up in specific machine register but I don't see any way to ascertain this from the information in MachineOperand. Basically, I need to know if I am allowed to rename a MachineOperand or not after register allocation. Thanks!

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

Tom, My current example is a global address; however, it could be any operand in theory. The arch allows for direct mem op support for ex instructions, so it could be any type of address or any type of imm or any type of register. For example, we are using intrinsics for some instructions since LLVM does not support them. Table gen does not allow for matching to direct mem op because the

On Oct 18, 2010, at 11:59 AM, Villmow, Micah wrote: > 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

On May 16, 2013, at 2:23 PM, dag at cray.com wrote: > Is there any way to determine if a Register-type MachineOperand > represents a fixed machine register? For example, call arguments must > end up in specific machine register but I don't see any way to ascertain > this from the information in MachineOperand. Basically, I need to know > if I am allowed to rename a

The size suffix thing is a weird quirk in our assembler I should look into fixing. Instructions in at&t syntax usually have a size suffix that is often optional For example: add %ax, %bx and addw %ax, %bx Are equivalent because the register name indicates the size. but for an instruction like this addw $1, (%ax) There is nothing to infer the size from so an explicit suffix is

Hi Sergei, our use of target flags will be on immediate register operands if I am not mistaken (and if not we can always encode it as such)? I guess you are refering to the hexagon backend needing to distinguish between instances of an instruction that uses a constant value that can fit into the 4 byte of the instruction and one that encodes the immediate in an extra instruction slot (what we

I'm working on the post-regalloc dataflow engine I mentioned yesterday. Currently I only need to track register operands. A MachineOperand has both a getReg() and a getSubReg() interface. For a physical register operand, is getReg() guaranteed to be the "most super" register with getSubReg() providing the specific subregister information for the operand? If so then for my current

Hey Ryan, You end with a large constant immediate offset value because the register operand stores the register id in a union together with the offset that's used by the global address operand. Just add 'setOffset(0)' to your change method and that should solve your problem. 2015-06-16 9:15 GMT-07:00 Ryan Taylor <ryta1203 at gmail.com>: > So I have this for