LLVM provides a number of atomicity / memory ordering primitives.

currently the CAS primops exposed at the CMM level are ffi'd inline assembly fun calls. this means that for certain concurrency primops, we've got fun calls within funcalls that could be easily inlined if we did it in a more llvm direct way. A notable example of this is the implementation of stg_atomicModifyMutVarzh

relevant basic llmv docs are the following Atomic llvm ops

semantics of the various ordering levels

relevant locations in the ghc source CAS inline assembly

defn of atomicModifyMutVar cmm code

Based upon my reading of the relevant GHC cmm code, and reading the semantics of the LLVM operations, the right level of atomic ordering in the generated bit code would be "SequentiallyConsistent".

a first step would be to modify the CMM -> LLVM pass to substitute the cas funcall with the right llvm operation. This ** SEEMS ** like it'd be very very easy to do and low hanging fruit.

Theres a few upsides that ** might ** come out of this.

1. would be easy to augment to also provide a doubleCAS primitive, which would be useful in writing various lock free data structures.
2. would increase the portability / ease of retargeting new platforms / hardware via LLVM. (not needing to worry about the target's memory consistency model / write new cases of inline assembly)
3. (this would need benchmarks) could potentially improve the performance of certain heavy concurrency operations by eliminating a funcall in an otherwise tight loop.
4. Theres probably other interesting possible upside, such as perhaps having more of the rts be nicely writeable in CMM? (esp since theres now native funcall support)
5. Also would make the CMM memory model a bit more explicit perhaps?

This seems like a *relatively* managable patch to write. I'm up for spending time on this if, should it work, it'd be likely to be merged in.

it'd also be a good warm up for a number of other things I want to do, including http://hackage.haskell.org/trac/ghc/ticket/5567\##7883