search for: machineoperands

...nk: > include/llvm/CodeGen/MachineOperand.h lib/CodeGen/MachineInstr.cpp > > Author: stoklund > Date: Tue Aug 28 13:05:48 2012 > New Revision: 162770 > > URL: http://llvm.org/viewvc/llvm-project?rev=162770&view=rev > Log: > Don't allow TargetFlags on MO_Register MachineOperands. > > Register operands are manipulated by a lot of target-independent code, > and it is not always possible to preserve target flags. That means it > is not safe to use target flags on register operands. > > None of the targets in the tree are using register operand target >...

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

...in CodeGen that deals with register operands does not appropriately handle target flags on the register operand (it might not transfer the information from an "old" operand to an "updated" operand). I guess I am asking you to clarify what you mean by heavy use of TargetFlags on MachineOperands. What specifically do you plan to do? Jakob, TargetFlags on immediate machine operands introduced as early as ISel Lowering should not be a problem, right? Thanks, Arnold On Mon, Oct 29, 2012 at 12:17 PM, Sergei Larin <slarin at codeaurora.org> wrote: > > Jakob and anyone else who m...

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!

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

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

...h register operands does not appropriately handle target flags > on the register operand (it might not transfer the information from an > "old" operand to an "updated" operand). > > I guess I am asking you to clarify what you mean by heavy use of > TargetFlags on MachineOperands. What specifically do you plan to do? > > Jakob, > TargetFlags on immediate machine operands introduced as early as ISel > Lowering should not be a problem, right? > > > Thanks, > Arnold > > On Mon, Oct 29, 2012 at 12:17 PM, Sergei Larin <slarin at codeaurora.or...

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

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

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

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

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 Aug 6, 2012, at 11:00 AM, Vincent Lejeune <vljn at ovi.com> wrote: > Ok. > > I tried to do it using a pass after register allocation, lowering NEG/ABS instructions. > However I met a problem : apparently getNextOperandForReg() can returns a MachineOperand before the one I'm processing. > > The following code snippet : > > > void

All, The code generator operand class, MachineOperand, has an 8-bit TargetFlags field that the individual targets can use as they please. X86 and ARM use it to encode linker magic on symbol operands. It has been mentioned a couple of times on this list that it is not safe to use TargetFlags on register operands. This is because many target-independent passes are manipulating register operands

Hi, I am writing a small tool to gather some static statistics on machine code using LLVMs MachineInstr, etc., infrastructure. My current goal is to count the number of bytes of integer and floating point data being processed per iteration of a loop. Now I've ran into the problem that I can't find any obvious way to get the actual type of a MachineOperand. After some digging I noticed

Hi, R600 hardware (Radeon gfx card) does neither have a NEG nor an ABS instruction ; however any sources operand can be negated/abs'd by setting a bit for every source operand in the final bytecode (but not DST). A good way of modeling this behavior in LLVM is by using TargetFlag on operand. Currently the R600 LLVM backend in Mesa lower NEG and ABS DAG instruction to a MOV + TargetFlag using

Hi all, I have a question about the types of MachineOperand. There are 12 different types of MachineOperand such as MO_Register, MO_Immediate and so on. Some of the names are self-explanatory such as MO_Register and MO_Immediate. Some of them are a little confusing such as MO_FrameIndex, MO_ConstantPoolIndex and so on. For example, what is the different between MO_ExternalSymbol and

On Mon, Aug 20, 2012 at 04:30:13PM -0700, Jakob Stoklund Olesen wrote: > All, > > The code generator operand class, MachineOperand, has an 8-bit TargetFlags field that the individual targets can use as they please. X86 and ARM use it to encode linker magic on symbol operands. > > It has been mentioned a couple of times on this list that it is not safe to use TargetFlags on

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