diff --git a/docs/Atomics.html b/docs/Atomics.html index 2b097b3faeb..d5bf9fa5c0f 100644 --- a/docs/Atomics.html +++ b/docs/Atomics.html @@ -330,9 +330,10 @@ instructions has been clarified in the IR.

-

SequentiallyConsistent (seq_cst in IR) provides Acquire and/or - Release semantics, and in addition guarantees a total ordering exists with - all other SequentiallyConsistent operations. +

SequentiallyConsistent (seq_cst in IR) provides + Acquire semantics for loads and Release semantics for + stores. Additionally, it guarantees that a total ordering exists + between all SequentiallyConsistent operations.

Relevant standard
@@ -344,11 +345,17 @@ instructions has been clarified in the IR.

reason about for the programmer than other kinds of operations, and using them is generally a practical performance tradeoff.
Notes for optimizers
-
In general, optimizers should treat this like a nothrow call; the - the possible optimizations are usually not interesting.
+
In general, optimizers should treat this like a nothrow call. + However, optimizers may improve performance by reordering a + store followed by a load unless both operations are sequentially + consistent.
Notes for code generation
-
SequentiallyConsistent operations generally require the strongest - barriers supported by the architecture.
+
SequentiallyConsistent loads minimally require the same barriers + as Acquire operations and SequeuentiallyConsistent stores require + Release barriers. Additionally, the code generator must enforce + ordering between SequeuentiallyConsistent stores followed by + SequeuentiallyConsistent loads. On common architectures, this + requires emitting a full fence after SequeuentiallyConsistent stores.