[GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?

[GHC]

#7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?
-----------------------------+----------------------------------------------
Reporter:  carter            |          Owner:                  
    Type:  feature request   |         Status:  new             
Priority:  normal            |      Component:  Compiler        
 Version:  7.7               |       Keywords:                  
      Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
 Failure:  None/Unknown      |      Blockedby:                  
Blocking:                    |        Related:                  
-----------------------------+----------------------------------------------
 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
 [http://llvm.org/docs/LangRef.html#cmpxchg-instruction Atomic llvm ops]

 [http://llvm.org/docs/Atomics.html semantics of the various ordering
 levels]

 relevant locations in the ghc source
 [https://github.com/ghc/ghc/blob/master/includes/stg/SMP.h#L170 CAS inline
 assembly]

 [https://github.com/ghc/ghc/blob/master/rts/PrimOps.cmm#L282 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#comment:10

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7883>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler