similar to: [LLVMdev] MachineOperand TargetFlags being ignored in register coalescing pass

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

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

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

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

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

Arnold, I wanted to hear from Jacob is the original patch in question still needed, since our use of this field could surpass const extenders and could potentially include MO_Register. Jacob, Can you please comment? Thanks. Sergei --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > -----Original Message----- > From: Arnold

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

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

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

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

On Oct 29, 2012, at 3:28 PM, "Sergei Larin" <slarin at codeaurora.org> wrote: > Arnold, > > I wanted to hear from Jacob is the original patch in question still needed, > since our use of this field could surpass const extenders and could > potentially include MO_Register. > > Jacob, > > Can you please comment? Thanks. I don't really have

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

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't figure out how to modify > the instruction patterns to make this work. For example, I have the class: > > class R600_1OP <bits<32> inst, string opName,

--- include/cube.h | 18 +++------ plugins/cube.c | 120 +++++++++++++++++-------------------------------------- 2 files changed, 43 insertions(+), 95 deletions(-) diff --git a/include/cube.h b/include/cube.h index 0a87626..293bad1 100644 --- a/include/cube.h +++ b/include/cube.h @@ -87,16 +87,11 @@ typedef void (*CubePaintInsideProc) (CompScreen *s, CompOutput *output,

Do you know any backend that implement instructions as a flag modifier in instruction ? Thank, Vincent Lejeune ----- Mail original ----- > De : Jakob 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 >

On Aug 22, 2012, at 11:52 AM, "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > > >> -----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

Hi All, I'd like to add HLE support in LLVM/clang consistent to GCC's style [1]. HLE from Intel TSX [2] is legacy compatible instruction set extension to specify transactional region by adding XACQUIRE and XRELEASE prefixes. To support that, GCC chooses the approach by extending the memory order flag in __atomic_* builtins with target-specific memory model in high bits (bit 31-16 for

Hi Michael, Why do you want to add transactional memory support to LLVM ? Can't you implement transactional memory using a library call ? Judging by the number of patches it looks like a major change to LLVM, and I am not sure that I understand the motivation for including it in LLVM. Thanks, Nadav On Feb 19, 2013, at 11:52 AM, Michael Liao <michael.liao at intel.com> wrote:

Here is the patch 0004-Enable-HLE-code-generation.patch Yours - Michael On Tue, 2013-02-19 at 14:07 -0800, Michael Liao wrote: > Hi All, > > I'd like to add HLE support in LLVM/clang consistent to GCC's style [1]. > HLE from Intel TSX [2] is legacy compatible instruction set extension to > specify transactional region by adding XACQUIRE and XRELEASE prefixes. > To