From 79d7de7650f20bb95aa5a4799e89e06fde57f005 Mon Sep 17 00:00:00 2001 From: Eli Friedman Date: Fri, 12 Aug 2011 03:38:32 +0000 Subject: [PATCH] Misc atomic doc tweaks; reordering operations across Acquire/Release can be beneficial. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137425 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/Atomics.html | 33 +++++++++++++++++++-------------- 1 file changed, 19 insertions(+), 14 deletions(-) diff --git a/docs/Atomics.html b/docs/Atomics.html index 95040fb4c32..e2effc6a6c8 100644 --- a/docs/Atomics.html +++ b/docs/Atomics.html @@ -251,8 +251,10 @@ instructions has been clarified in the IR.

Acquire only provides a semantic guarantee when paired with a Release operation.
Notes for optimizers
-
In general, optimizers should treat this like a nothrow call; the - the possible optimizations are usually not interesting.
+
Optimizers not aware of atomics can treat this like a nothrow call. + Tt is also possible to move stores from before an Acquire load + or read-modify-write operation to after it, and move non-Acquire + loads from before an Acquire operation to after it.
Notes for code generation
Architectures with weak memory ordering (essentially everything relevant today except x86 and SPARC) require some sort of fence to maintain @@ -284,11 +286,13 @@ instructions has been clarified in the IR.

Release only provides a semantic guarantee when paired with a Acquire operation.
Notes for optimizers
-
In general, optimizers should treat this like a nothrow call; the - the possible optimizations are usually not interesting.
+
Optimizers not aware of atomics can treat this like a nothrow call. + It is also possible to move loads from after a Release store + or read-modify-write operation to before it, and move non-Release + stores from after an Release operation to before it.
Notes for code generation
See the section on Acquire; a fence before the relevant operation is - usually sufficient for Release. Note that a store-store fence is not + usually sufficient for Release. Note that a store-store fence is not sufficient to implement Release semantics; store-store fences are generally not exposed to IR because they are extremely difficult to use correctly.
@@ -345,17 +349,18 @@ 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. - However, optimizers may improve performance by reordering a - store followed by a load unless both operations are sequentially - consistent.
+
Optimizers not aware of atomics can treat this like a nothrow call. + For SequentiallyConsistent loads and stores, the same reorderings are + allowed as for Acquire loads and Release stores, except that + SequentiallyConsistent operations may not be reordered.
Notes for code generation
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.
+ as Acquire operations and SequeuentiallyConsistent stores require + Release barriers. Additionally, the code generator must enforce + ordering between SequeuentiallyConsistent stores followed by + SequeuentiallyConsistent loads. This is usually done by emitting + either a full fence before the loads or a full fence after the + stores; which is preferred varies by architecture. -- 2.34.1