[LLVMdev] Atomic Operation and Synchronization Proposal v2

[Dan Gohman]

On Thu, Jul 12, 2007 at 10:06:04AM -0500, David Greene wrote:
> On Thursday 12 July 2007 07:23, Torvald Riegel wrote:
> 
> > > The single instruction constraints can, at their most flexible, constrain
> > > any set of possible pairings of loads from memory and stores to memory
> >
> > I'm not sure about this, but can we get issues due to "special" kinds of
> > data transfers (such as vector stuff, DMA, ...?). Memcpy implementations
> > could be a one thing to look at.
> > This kind of breaks down to how universal you want the memory model to be.
> 
> Right.  For example, the Cray X1 has a much richer set of memory ordering 
> instructions than anything on the commodity micros:
> 
> http://tinyurl.com/3agjjn
> 
> The memory ordering intrinsics in the current llvm proposal can't take 
> advantage of them because they are too coarse-grained.

I guess the descriptions on that page are, heh, a little terse ;-). The
Cray X1 has a dimension of synchronization that isn't covered in this
proposal, and that's the set of observers need to observe the ordering.
For example you can synchronize a team of streams in a multi-streaming
processor without requiring that the ordering of memory operations be
observed by the entire system. That's what motivates most of the variety
in that list.

There's one other specific aspect I'd like to point out here. There's an
"acquire" which orders prior *scalar* loads with *all* subsequent memory
accesses, and a "release" which orders *all* prior accesses with subsequent
*scalar* stores. The Cray X1's interest in distinguishing scalar accesses
from vector accesses is specific to its architecture, but in general, it
is another case that motivates having more granularity than just "all
loads" and "all stores". 

Overall though, I'm quite happy to see that the newest revision of the
proposal has switched from LLVM instructions to LLVM intrinsics. That
will make it easier to experiment with extensions in the future. And
having the string "atomic" right there in the names of each operation
is very much appreciated :-).

Dan

-- 
Dan Gohman, Cray Inc.