similar to: [LLVMdev] Proposal for a new LLVM concurrency memory model

> Hi all, > > Chandler, Owen, and I have written up a proposal for a new memory > model and atomic intrinsics in LLVM, which will make it possible to > support Java and the upcoming C++0x standard. The proposed changes to > the LangRef are at > <http://docs.google.com/View?docID=ddb4mhxz_22dz5g98dd&revision=_latest > >, > and a rationale for some of the more

On Sunday 25 April 2010 21:26:47 Jeffrey Yasskin wrote: > Hi all, > > Chandler, Owen, and I have written up a proposal for a new memory > model and atomic intrinsics in LLVM, which will make it possible to > support Java and the upcoming C++0x standard. The proposed changes to > the LangRef are at >

One question I had for LLVM folks while we were working on this: does it make sense to transition the atomic operations to instructions instead of intrinsics? I'm not sold on this in either direction, I'd just like to get people's thoughts on it. Certainly for languages such as Java, they will make up a surprisingly large chunk of the loads and stores, and instructions have much mor

On Sun, Jul 31, 2011 at 7:11 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Sun, Jul 31, 2011 at 3:04 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: >> The current memory model section ends with the following discussions: >> >> "Note that in cases where none of the atomic intrinsics are used, this >> model places only one restriction on

On Sun, Jul 31, 2011 at 3:04 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > The current memory model section ends with the following discussions: > > "Note that in cases where none of the atomic intrinsics are used, this > model places only one restriction on IR transformations on top of what > is required for single-threaded execution: introducing a store to a

There was some discussion a while back about adding a C++0x-style memory model and atomics for LLVM a while back (http://thread.gmane.org/gmane.comp.compilers.llvm.devel/31295), but it got stalled. I'm going to try and restart progress on it. Attached are two patches; the first adds a section to LangRef with just the memory model, without directly changing the documentation or implementation

On Sunday 25 April 2010 21:26:47 Jeffrey Yasskin wrote: > Hi all, > > Chandler, Owen, and I have written up a proposal for a new memory > model and atomic intrinsics in LLVM, which will make it possible to > support Java and the upcoming C++0x standard. The proposed changes to > the LangRef are at >

On 26 April 2010 15:59, Jeffrey Yasskin <jyasskin at google.com> wrote: > To be clear, Chandler wasn't suggesting any change to the existing > load and store instructions. Instead, we were wondering if people like > the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe > atomic_exchange and atomic_add instructions. I see, in that case, I don't have any

C++ and Java memory models impose restrictions for locks and unlocks, such as a thread that releases a lock must acquired the lock, or the number of locks must be larger than the number of unlocks in the same thread... for enabling some optimizations, for example, simplifying trylocks (http://www.hpl.hp.com/techreports/2008/HPL-2008-56.html), and moving some instructions inside lock acquires

On Monday 26 April 2010 10:19:06 Renato Golin wrote: > On 26 April 2010 15:59, Jeffrey Yasskin <jyasskin at google.com> wrote: > > To be clear, Chandler wasn't suggesting any change to the existing > > load and store instructions. Instead, we were wondering if people like > > the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe > >

I noticed the patch was already merged into the current LLVM language reference manual with new memory instructions, fence, cmpxchg and atomicrmw. Will the instructions be available in LLVM 3.0? On Mon, Jul 18, 2011 at 8:22 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > There was some discussion a while back about adding a C++0x-style > memory model and atomics for LLVM a while

On Mon, Apr 26, 2010 at 1:09 PM, David Greene <dag at cray.com> wrote: > On Monday 26 April 2010 14:03:35 Chandler Carruth wrote: >> We can allow the IR to represent vectors, but unless hardware supports it, >> I think lowering these by decomposing them is more than LLVM should try to >> do. Because of that, I'm not sure we should support vectors as elsewhere

In the definition of 'monotonic' ordering, ... "If an address is written monotonically by one thread, and other threads monotonically read that address repeatedly, the other threads must eventually see the write"... Does this mean if a thread does multi-writes monotonically, monotonic reads from other threads should see all of them? But intuitively, it seems to be fine for a

Sorry for the delay in getting back to you. I don't know if anything came out of this, since Xiaoyi never wrote back. What does some of the affected code look like? My opinion is still that 'restrict' should mean that no other thread should use a pointer aliasing the restrict pointer, although if many threads are started after the lifetime of the restrict pointer starts, and they

The current memory model section ends with the following discussions: "Note that in cases where none of the atomic intrinsics are used, this model places only one restriction on IR transformations on top of what is required for single-threaded execution: introducing a store to a byte which might not otherwise be stored to can introduce undefined behavior.... " Why is introducing

On Wed, Jul 15, 2009 at 8:52 AM, Owen Anderson<resistor at mac.com> wrote: > > On Jul 15, 2009, at 8:14 AM, John Criswell wrote: > > Dear All, > > Is there a reason why the AllocaInst constructor takes an LLVMContext > argument?  Can't it just determine the context from either the basic > block or instruction pointer argument? > > BasicBlocks and

What would you do with a just-hardware memory fence? If the compiler's free to move operations over the hardware fence, that seems to defeat the purpose. C++0X provides a compiler-only fence, and a hardware+compiler fence, but no hardware-only fence, I believe for this reason. See <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf>, section 29.8. On Sat, May 16, 2009 at

Chandler pointed out another interpretation of C11/6.7.3.1, in which 'restrict' only addresses aliasing within a single thread. If that's the right interpretation, then it's a bug in LLVM that it moves noalias pointers across memory-ordering operations at all, and you still don't need a new fence, just a bug fix. 6.7.3.1 says "During each execution of B, ...".

Surprisingly enough, libatomic_ops doesn't define just a hardware memory fence call as far as I can tell. --Owen On May 16, 2009, at 3:00 PM, Zoltan Varga wrote: > Hi, > > You might want to use this: > > http://www.hpl.hp.com/research/linux/atomic_ops/ > > Zoltan > > On Sat, May 16, 2009 at 11:11 PM, Owen Anderson <resistor at

On Monday 26 April 2010 16:09:48 Jeffrey Yasskin wrote: > > Vector atomics are extremely useful on architectures that support them. > > I'm curious about the architectures/instructions you're thinking of. > Something like 'lock; movdqa'? Don't think X86. Think traditional vector machines like the Cray X1/X2. Atomic vector adds and logicals are common