[GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?
GHC
ghc-devs at haskell.org
Thu Aug 1 18:30:21 CEST 2013
#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
More information about the ghc-tickets
mailing list