From e2d8cf77c8df45768a3902a97cd357dcf2a5d719 Mon Sep 17 00:00:00 2001 From: Eli Friedman Date: Wed, 10 Aug 2011 20:17:43 +0000 Subject: [PATCH] Changes per Jeffrey's comments. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137243 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/Atomics.html | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/docs/Atomics.html b/docs/Atomics.html index a7bfe18f7e0..3adeafc7100 100644 --- a/docs/Atomics.html +++ b/docs/Atomics.html @@ -138,14 +138,16 @@ instructions has been clarified in the IR.

those optimizations useful.

Acquire provides a barrier of the sort necessary to acquire a lock to access - other memory with normal loads and stores. This corresponds to the - C++0x/C1x memory_order_acquire. This is a low-level + other memory with normal loads and stores. This corresponds to the + C++0x/C1x memory_order_acquire. It should also be used for + C++0x/C1x memory_order_consume. This is a low-level synchronization primitive. In general, optimizers should treat this like a nothrow call.

Release is similar to Acquire, but with a barrier of the sort necessary to - release a lock.This corresponds to the C++0x/C1x - memory_order_release.

+ release a lock. This corresponds to the C++0x/C1x + memory_order_release. In general, optimizers should treat this + like a nothrow call.

AcquireRelease (acq_rel in IR) provides both an Acquire and a Release barrier. This corresponds to the C++0x/C1x memory_order_acq_rel. In general, @@ -171,8 +173,9 @@ instructions has been clarified in the IR.

cmpxchg and atomicrmw are essentially like an atomic load followed by an atomic store (where the store is conditional for - cmpxchg), but no other memory operation operation can happen - between the load and store.

+ cmpxchg), but no other memory operation can happen between + the load and store. Note that our cmpxchg does not have quite as many + options for making cmpxchg weaker as the C++0x version.

A fence provides Acquire and/or Release ordering which is not part of another operation; it is normally used along with Monotonic memory @@ -203,7 +206,7 @@ instructions has been clarified in the IR.

Unordered. This would be checked, for example, by LICM before hoisting an operation.
  • mayReadFromMemory()/mayWriteToMemory(): Existing predicate, but note - that they returns true for any operation which is volatile or at least + that they return true for any operation which is volatile or at least Monotonic.
  • Alias analysis: Note that AA will return ModRef for anything Acquire or Release, and for the address accessed by any Monotonic operation.