similar to: [LLVMdev] RFC: SDNode Flags

I also want a way to add target specific flag to a SDNode (which should be transferred to MachineInstr). For example, on x86 lots of opcodes have *lock* variants. Right now, these are separate instructions. I'd prefer to make it into a target specific flag that can be toggled by some sort of post-isel action routine. One way to handle this might be to expand the use of SubclassData.

On Jul 31, 2009, at 11:26 AM, David Greene wrote: > Right now the MemSDNode keeps a volatile bit in the SubclassData to > mark > volatile memory operations. > > We have some changes we'd like to push back that adds a NonTemporal > flag > to MemSDNode to mark instructions where movnt (on x86) and other > goodness > can happen (we'll also add the TableGen

On Saturday 01 August 2009 15:12, Dan Gohman wrote: > LoadSDNode, which inherits from MemSDNode is the largest > SDNode. With the current SDNode allocation strategy, making it > bigger will increase the allocation needed for all nodes. Ok. > > new (N) LoadSDNode(..., isVolatile|isNonTemporal); > > > > Thoughts? > > This sounds reasonable. I'd suggest

On Aug 3, 2009, at 9:30 AM, David Greene wrote: > On Saturday 01 August 2009 15:12, Dan Gohman wrote: > >> LoadSDNode, which inherits from MemSDNode is the largest >> SDNode. With the current SDNode allocation strategy, making it >> bigger will increase the allocation needed for all nodes. > > Ok. > > >>> new (N) LoadSDNode(...,

On Sunday 02 August 2009 20:57, Evan Cheng wrote: > I also want a way to add target specific flag to a SDNode (which > should be transferred to MachineInstr). For example, on x86 lots of > opcodes have *lock* variants. Right now, these are separate > instructions. I'd prefer to make it into a target specific flag that > can be toggled by some sort of post-isel action routine.

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

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

Here is the patch 0002-Add-HLE-target-feature.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 support

Here is the patch 0003-Add-XACQ-XREL-prefix-and-encoding-asm-printer-suppor.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

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:

On Thursday 11 February 2010 14:44:23 Dan Gohman wrote: > > Then we can't use it to hold a non-temporal flag. The operand might be > > non-temporal in one context but it may not be in another. > > Sharing only happens when two instructions have the "same" memory > reference info. You just need to make sure that the non-temporal > flag is significant.

On Feb 11, 2010, at 3:15 PM, David Greene wrote: > On Thursday 11 February 2010 14:44:23 Dan Gohman wrote: > >>> Then we can't use it to hold a non-temporal flag. The operand might be >>> non-temporal in one context but it may not be in another. >> >> Sharing only happens when two instructions have the "same" memory >> reference info. You

Hello, After commit r114523, I start to get crash when compiling with clang (Release+Asserts) for i386: (I know I should fill a bug report instead of posting here, but I don't get much time right now). Trying to compile the following simple code, clang asserts. ---------- round.c -------- #include <math.h> float test() { return llround(1); } -------------------- [MacPro:~/Desktop]

I will take a look in the next couple hours. Feel free to revert it in the meantime, thanks! -Chris On Sep 22, 2010, at 1:53 AM, Jean-Daniel Dupas <devlists at shadowlab.org> wrote: > Hello, > > After commit r114523, I start to get crash when compiling with clang (Release+Asserts) for i386: > (I know I should fill a bug report instead of posting here, but I don't get

On Feb 11, 2010, at 12:07 PM, David Greene wrote: > On Thursday 11 February 2010 14:02:13 Dan Gohman wrote: > >>>> Putting a bit (or multiple bits) in MachineMemOperand for this >>>> would also make sense. >>> >>> Is there any chance a MachineMemOperand will be shared by multiple >>> instructions? >> >> Yes. > > Then

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Duncan Sands > Sent: Thursday, March 31, 2011 7:43 PM > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Assert in VerifySDNode > > Hi Micah, > > > assert(!isa<MemSDNode>(N) && "Bad MemSDNode!"); > > you

Hi Micah, > assert(!isa<MemSDNode>(N) && "Bad MemSDNode!"); you can't use getNode to allocate a MemSDNode because it does not allocate enough memory (MemSDNode has extra fields beyond the operands). Ciao, Duncan.

Nadav, I've been reading over the patches and I was wondering if you could elaborate your concerns here. I share your goal of reducing compilation time regressions for users that don't care about new feature X. From my very quick glance over the patches, I didn't see anything I couldn't opt out of. Maybe we can talk about specifics and figure out a way to make these changes not

The current specification of the behavior of the !nontemporal attribute in LLVM, and the __builtin_nontemporal_* functions in Clang, is rather spartan and underspecified. In effect, it says the following things: * Atomic !nontemporal has no defined semantics * !nontemporal may use special instructions to save cache bandwidth, such as "MOVNT" on x86. What is crucially lacking