[llvm-commits] [llvm] r137425 - /llvm/trunk/docs/Atomics.html

[Eli Friedman]

Author: efriedma
Date: Thu Aug 11 22:38:32 2011
New Revision: 137425

URL: http://llvm.org/viewvc/llvm-project?rev=137425&view=rev
Log:
Misc atomic doc tweaks; reordering operations across Acquire/Release can be beneficial.


Modified:
    llvm/trunk/docs/Atomics.html

Modified: llvm/trunk/docs/Atomics.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/Atomics.html?rev=137425&r1=137424&r2=137425&view=diff
==============================================================================
--- llvm/trunk/docs/Atomics.html (original)
+++ llvm/trunk/docs/Atomics.html Thu Aug 11 22:38:32 2011
@@ -251,8 +251,10 @@
       Acquire only provides a semantic guarantee when paired with a Release
       operation.</dd>
   <dt>Notes for optimizers</dt>
-  <dd>In general, optimizers should treat this like a nothrow call; the
-      the possible optimizations are usually not interesting.</dd>
+  <dd>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.</dd>
   <dt>Notes for code generation</dt>
   <dd>Architectures with weak memory ordering (essentially everything relevant
       today except x86 and SPARC) require some sort of fence to maintain
@@ -284,11 +286,13 @@
       Release only provides a semantic guarantee when paired with a Acquire
       operation.</dd>
   <dt>Notes for optimizers</dt>
-  <dd>In general, optimizers should treat this like a nothrow call; the
-      the possible optimizations are usually not interesting.</dd>
+  <dd>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.</dd>
   <dt>Notes for code generation</dt>
   <dd>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.</dd>
@@ -345,17 +349,18 @@
       reason about for the programmer than other kinds of operations, and using
       them is generally a practical performance tradeoff.</dd>
   <dt>Notes for optimizers</dt>
-  <dd>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.</dd>
+  <dd>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.</dd>
   <dt>Notes for code generation</dt>
   <dd>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.</dd>
+     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.</dd>
 </dl>
 
 </div>