+ Acquire/Release. (See also <a href="LangRef.html#ordering">LangRef</a>.)</p>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="o_notatomic">NotAtomic</a>
+</h3>
+
+<div>
+
+<p>NotAtomic is the obvious, a load or store which is not atomic. (This isn't
+ really a level of atomicity, but is listed here for comparison.) This is
+ essentially a regular load or store. If there is a race on a given memory
+ location, loads from that location return undef.</p>
+
+<dl>
+ <dt>Relevant standard</dt>
+ <dd>This is intended to match shared variables in C/C++, and to be used
+ in any other context where memory access is necessary, and
+ a race is impossible. (The precise definition is in
+ <a href="LangRef.html#memmodel">LangRef</a>.)
+ <dt>Notes for frontends</dt>
+ <dd>The rule is essentially that all memory accessed with basic loads and
+ stores by multiple threads should be protected by a lock or other
+ synchronization; otherwise, you are likely to run into undefined
+ behavior. If your frontend is for a "safe" language like Java,
+ use Unordered to load and store any shared variable. Note that NotAtomic
+ volatile loads and stores are not properly atomic; do not try to use
+ them as a substitute. (Per the C/C++ standards, volatile does provide
+ some limited guarantees around asynchronous signals, but atomics are
+ generally a better solution.)
+ <dt>Notes for optimizers</dt>
+ <dd>Introducing loads to shared variables along a codepath where they would
+ not otherwise exist is allowed; introducing stores to shared variables
+ is not. See <a href="#outsideatomic">Optimization outside
+ atomic</a>.</dd>
+ <dt>Notes for code generation</dt>
+ <dd>The one interesting restriction here is that it is not allowed to write
+ to bytes outside of the bytes relevant to a store. This is mostly
+ relevant to unaligned stores: it is not allowed in general to convert
+ an unaligned store into two aligned stores of the same width as the
+ unaligned store. Backends are also expected to generate an i8 store
+ as an i8 store, and not an instruction which writes to surrounding
+ bytes. (If you are writing a backend for an architecture which cannot
+ satisfy these restrictions and cares about concurrency, please send an
+ email to llvmdev.)</dd>
+</dl>
+
+</div>
+
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="o_unordered">Unordered</a>
+</h3>
+
+<div>