search for: targetflag

Jakob and anyone else who might be interested... Base on this patch back in August, I sense some need to double check with you whether it is OK to start making a heavy use of MachineOperand TargetFlags? We do seem to have a compelling reason for it in Hexagon, and I wanted to make sure that it is OK with everyone. I plan to use it for attributing target specific info to MOs and in more general case to MIs that those MOs belongs to. Part of my question would be - is it still unsafe to use it fo...

...me of the code 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 a...

...ses the approach by extending the memory order flag in __atomic_* builtins with target-specific memory model in high bits (bit 31-16 for target-specific memory model, bit 15-0 for the general memory model.) To follow the similar approach, I propose to change LLVM/clang by adding: + a metadata 'targetflags' in LLVM atomic IR to pass this target-specific memory model hint + one extra target flag in AtomicSDNode & MemIntrinsicSDNode to specify XACQUIRE or XRELEASE hints This extra target flag is embedded into the SubclassData fields. The following is rationale how such target flags are em...

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 anyth...

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. 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...

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 customEmitter pass. This emulates the existence of a NEG/ABS instruction, but is not optimal as it costs an extra (often uneeded) MOV instruction. I'm trying to rework this : I'...

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 I need 28 bi...

...he operands before an instruction is executed. The output modifiers are CLAMP (clamp result between 0.0f and 1.0f) and OMOD (multiply the result by 0.5f, 2.0f, or 4.0f). These are applied to the result of an instruction after it is executed. For the R600 backend, I'm using the MachineOperand TargetFlags to keep track of the modifiers, but I've noticed when I use them on operands to COPY instructions they are not propagated when registers are coalesced. Is this a bug, or should I not be using TargetFlags for storing this kind of information? -Tom

...ses the approach by extending the memory order flag in __atomic_* builtins with target-specific memory model in high bits (bit 31-16 for target-specific memory model, bit 15-0 for the general memory model.) To follow the similar approach, I propose to change LLVM/clang by adding: + a metadata 'targetflags' in LLVM atomic IR to pass this target-specific memory model hint + one extra target flag in AtomicSDNode & MemIntrinsicSDNode to specify XACQUIRE or XRELEASE hints This extra target flag is embedded into the SubclassData fields. The following is rationale how such target flags are em...

...> 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 <sla...

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...

...extending the memory order > flag in __atomic_* builtins with target-specific memory model in high bits (bit 31-16 for target-specific memory model, bit 15-0 for the general memory model.) To follow the similar approach, I propose to > change LLVM/clang by adding: > > + a metadata 'targetflags' in LLVM atomic IR to pass this > target-specific memory model hint > > + one extra target flag in AtomicSDNode & MemIntrinsicSDNode to specify XACQUIRE or XRELEASE hints > This extra target flag is embedded into the SubclassData fields. The following is rationale how such t...

...the memory order > flag in __atomic_* builtins with target-specific memory model in high > bits (bit 31-16 for target-specific memory model, bit 15-0 for the > general memory model.) To follow the similar approach, I propose to > change LLVM/clang by adding: > > + a metadata 'targetflags' in LLVM atomic IR to pass this > target-specific memory model hint > > + one extra target flag in AtomicSDNode & MemIntrinsicSDNode to specify > XACQUIRE or XRELEASE hints > This extra target flag is embedded into the SubclassData fields. The > following is rational...

...the memory order > flag in __atomic_* builtins with target-specific memory model in high > bits (bit 31-16 for target-specific memory model, bit 15-0 for the > general memory model.) To follow the similar approach, I propose to > change LLVM/clang by adding: > > + a metadata 'targetflags' in LLVM atomic IR to pass this > target-specific memory model hint > > + one extra target flag in AtomicSDNode & MemIntrinsicSDNode to specify > XACQUIRE or XRELEASE hints > This extra target flag is embedded into the SubclassData fields. The > following is rational...

...the memory order > flag in __atomic_* builtins with target-specific memory model in high > bits (bit 31-16 for target-specific memory model, bit 15-0 for the > general memory model.) To follow the similar approach, I propose to > change LLVM/clang by adding: > > + a metadata 'targetflags' in LLVM atomic IR to pass this > target-specific memory model hint > > + one extra target flag in AtomicSDNode & MemIntrinsicSDNode to specify > XACQUIRE or XRELEASE hints > This extra target flag is embedded into the SubclassData fields. The > following is rational...

...b Stoklund Olesen <stoklund at 2pi.dk> > À : Vincent Lejeune <vljn at ovi.com> > Cc : "llvmdev at cs.uiuc.edu (LLVMdev at cs.uiuc.edu)" <llvmdev at cs.uiuc.edu> > Envoyé le : Lundi 6 août 2012 20h06 > Objet : Re: [LLVMdev] Register Coalescer does not preserve TargetFlag > > > 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() ca...

...ginal Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Owen Anderson >> Sent: Tuesday, August 21, 2012 11:37 AM >> To: Stellard, Thomas >> Cc: llvmdev at cs.illinois.edu >> Subject: Re: [LLVMdev] No more TargetFlags on MO_Register >> MachineOperands >> >> Tom, >> >> The generally accepted way of achieving this is to leave the built-in >> pattern on the instruction empty, and to use def : Pat constructs to >> provide the default values. >> >> def : Pat&l...

> -----Original Message----- > From: Owen Anderson [mailto:resistor at mac.com] > Sent: Wednesday, August 22, 2012 11:41 AM > To: Villmow, Micah > Cc: Stellard, Thomas; llvmdev at cs.illinois.edu > Subject: Re: [LLVMdev] No more TargetFlags on MO_Register > MachineOperands > > > On Aug 22, 2012, at 11:34 AM, "Villmow, Micah" <Micah.Villmow at amd.com> > wrote: > > > > > > >> -----Original Message----- > >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bou...

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Owen Anderson > Sent: Tuesday, August 21, 2012 11:37 AM > To: Stellard, Thomas > Cc: llvmdev at cs.illinois.edu > Subject: Re: [LLVMdev] No more TargetFlags on MO_Register > MachineOperands > > Tom, > > On Aug 21, 2012, at 11:21 AM, Tom Stellard <thomas.stellard at amd.com> > wrote: > > > I've been working on replacing the MachineOperand flags in the R600 > > backend with immediate operands, but I can'...

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 register operands. This is because many target-independent passes are ma...