#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