#7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rrnewton): Some notes on which operations the "atomic-primops" library is currently exposing, and the other concurrent data structure libs (e.g. chaselev- deque) are using: * CAS on MutVars, MutableArray#, and MutableByteArray# * fetch and add on MutableByteArray# * barriers / memory fences Drafts of .cmm for these can be found inside the atomic-primops library. Note that *only* casMutVar# is currently shipped with GHC. Ultimately there's no reason that we shouldn't aim for a fairly "complete set". For example, why not have fetch-and-sub and the other "atomicrmw" variants? Relating these to the LLVM atomics and memory orderings, they become: * CAS variants = LLVM cmpxchg with SequentiallyConsistent ordering * fetch-and-X variants = LLVM atomicrmw with SequentiallyConsistent * store_load_barrier = LLVM fenceInst with SequentiallyConsistent * write_barrier and load_load_barrier = I *think* these are both covered by a FenceInst with AcquireRelease ordering... I'm not an LLVM expert, so please double check these yourself before trusting them. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7883#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler