comparison docs/Atomics.rst @ 77:54457678186b LLVM3.6

LLVM 3.6
author Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
date Mon, 08 Sep 2014 22:06:00 +0900
parents 95c75e76d11b
children 60c9769439b8
comparison
equal deleted inserted replaced
34:e874dbf0ad9d 77:54457678186b
22 <http://www.open-std.org/jtc1/sc22/wg21/>`_.) (`C1x draft available here 22 <http://www.open-std.org/jtc1/sc22/wg21/>`_.) (`C1x draft available here
23 <http://www.open-std.org/jtc1/sc22/wg14/>`_.) 23 <http://www.open-std.org/jtc1/sc22/wg14/>`_.)
24 24
25 * Proper semantics for Java-style memory, for both ``volatile`` and regular 25 * Proper semantics for Java-style memory, for both ``volatile`` and regular
26 shared variables. (`Java Specification 26 shared variables. (`Java Specification
27 <http://java.sun.com/docs/books/jls/third_edition/html/memory.html>`_) 27 <http://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html>`_)
28 28
29 * gcc-compatible ``__sync_*`` builtins. (`Description 29 * gcc-compatible ``__sync_*`` builtins. (`Description
30 <http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html>`_) 30 <https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html>`_)
31 31
32 * Other scenarios with atomic semantics, including ``static`` variables with 32 * Other scenarios with atomic semantics, including ``static`` variables with
33 non-trivial constructors in C++. 33 non-trivial constructors in C++.
34 34
35 Atomic and volatile in the IR are orthogonal; "volatile" is the C/C++ volatile, 35 Atomic and volatile in the IR are orthogonal; "volatile" is the C/C++ volatile,
108 non-atomic loads and stores, but provide additional guarantees in situations 108 non-atomic loads and stores, but provide additional guarantees in situations
109 where threads and signals are involved. 109 where threads and signals are involved.
110 110
111 ``cmpxchg`` and ``atomicrmw`` are essentially like an atomic load followed by an 111 ``cmpxchg`` and ``atomicrmw`` are essentially like an atomic load followed by an
112 atomic store (where the store is conditional for ``cmpxchg``), but no other 112 atomic store (where the store is conditional for ``cmpxchg``), but no other
113 memory operation can happen on any thread between the load and store. Note that 113 memory operation can happen on any thread between the load and store.
114 LLVM's cmpxchg does not provide quite as many options as the C++0x version.
115 114
116 A ``fence`` provides Acquire and/or Release ordering which is not part of 115 A ``fence`` provides Acquire and/or Release ordering which is not part of
117 another operation; it is normally used along with Monotonic memory operations. 116 another operation; it is normally used along with Monotonic memory operations.
118 A Monotonic load followed by an Acquire fence is roughly equivalent to an 117 A Monotonic load followed by an Acquire fence is roughly equivalent to an
119 Acquire load. 118 Acquire load.
428 uses ``XCHG``, ``atomicrmw add`` and ``atomicrmw sub`` use ``XADD``, and all 427 uses ``XCHG``, ``atomicrmw add`` and ``atomicrmw sub`` use ``XADD``, and all
429 other ``atomicrmw`` operations generate a loop with ``LOCK CMPXCHG``. Depending 428 other ``atomicrmw`` operations generate a loop with ``LOCK CMPXCHG``. Depending
430 on the users of the result, some ``atomicrmw`` operations can be translated into 429 on the users of the result, some ``atomicrmw`` operations can be translated into
431 operations like ``LOCK AND``, but that does not work in general. 430 operations like ``LOCK AND``, but that does not work in general.
432 431
433 On ARM, MIPS, and many other RISC architectures, Acquire, Release, and 432 On ARM (before v8), MIPS, and many other RISC architectures, Acquire, Release,
434 SequentiallyConsistent semantics require barrier instructions for every such 433 and SequentiallyConsistent semantics require barrier instructions for every such
435 operation. Loads and stores generate normal instructions. ``cmpxchg`` and 434 operation. Loads and stores generate normal instructions. ``cmpxchg`` and
436 ``atomicrmw`` can be represented using a loop with LL/SC-style instructions 435 ``atomicrmw`` can be represented using a loop with LL/SC-style instructions
437 which take some sort of exclusive lock on a cache line (``LDREX`` and ``STREX`` 436 which take some sort of exclusive lock on a cache line (``LDREX`` and ``STREX``
438 on ARM, etc.). At the moment, the IR does not provide any way to represent a 437 on ARM, etc.).
439 weak ``cmpxchg`` which would not require a loop.