[LLVMdev] Atomic Operation and Synchronization Proposal v2

[David Greene]

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.

Now, I don't expect we'll see an llvm-based X1 code generator, but looking at 
what the HPC vendors are doing in this area will go a long way toward 
informing the kind of operations we may want to include in llvm.  The trend is 
for vendors to include ever more finely targeted semantics to allow scaling to 
machines with millions of cores.

If we can incrementally refine the size of the memory ordering hammers, I'm
ok with that.  If it's simply a matter of adding finer-grained intrinsics 
later, that's cool.  But I don't want to get us into a situation where llvm 
requires stricter memory ordering than is strictly necessary and we can't get 
out from under the stone.

                                                      -Dave