6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2025-03-26 07:34:14 +00:00
Code Issues Projects Releases Wiki Activity

Misc atomic doc tweaks; reordering operations across Acquire/Release can be beneficial.

Browse Source 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137425 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Eli Friedman 2011-08-12 03:38:32 +00:00
parent 1221139f10
commit 79d7de7650
1 changed files with 19 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
docs/Atomics.html
View File

@ -251,8 +251,10 @@ instructions has been clarified in the IR.</p>
Acquire only provides a semantic guarantee when paired with a Release Acquire only provides a semantic guarantee when paired with a Release
operation.</dd> operation.</dd>
<dt>Notes for optimizers</dt> <dt>Notes for optimizers</dt>
<dd>In general, optimizers should treat this like a nothrow call; the <dd>Optimizers not aware of atomics can treat this like a nothrow call.
the possible optimizations are usually not interesting.</dd> 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> <dt>Notes for code generation</dt>
<dd>Architectures with weak memory ordering (essentially everything relevant <dd>Architectures with weak memory ordering (essentially everything relevant
today except x86 and SPARC) require some sort of fence to maintain today except x86 and SPARC) require some sort of fence to maintain
@ -284,11 +286,13 @@ instructions has been clarified in the IR.</p>
Release only provides a semantic guarantee when paired with a Acquire Release only provides a semantic guarantee when paired with a Acquire
operation.</dd> operation.</dd>
<dt>Notes for optimizers</dt> <dt>Notes for optimizers</dt>
<dd>In general, optimizers should treat this like a nothrow call; the <dd>Optimizers not aware of atomics can treat this like a nothrow call.
the possible optimizations are usually not interesting.</dd> 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> <dt>Notes for code generation</dt>
<dd>See the section on Acquire; a fence before the relevant operation is <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 sufficient to implement Release semantics; store-store fences are
generally not exposed to IR because they are extremely difficult to generally not exposed to IR because they are extremely difficult to
use correctly.</dd> use correctly.</dd>
@ -345,17 +349,18 @@ instructions has been clarified in the IR.</p>
reason about for the programmer than other kinds of operations, and using reason about for the programmer than other kinds of operations, and using
them is generally a practical performance tradeoff.</dd> them is generally a practical performance tradeoff.</dd>
<dt>Notes for optimizers</dt> <dt>Notes for optimizers</dt>
<dd>In general, optimizers should treat this like a nothrow call. <dd>Optimizers not aware of atomics can treat this like a nothrow call.
However, optimizers may improve performance by reordering a For SequentiallyConsistent loads and stores, the same reorderings are
store followed by a load unless both operations are sequentially allowed as for Acquire loads and Release stores, except that
consistent.</dd> SequentiallyConsistent operations may not be reordered.</dd>
<dt>Notes for code generation</dt> <dt>Notes for code generation</dt>
<dd>SequentiallyConsistent loads minimally require the same barriers <dd>SequentiallyConsistent loads minimally require the same barriers
as Acquire operations and SequeuentiallyConsistent stores require as Acquire operations and SequeuentiallyConsistent stores require
Release barriers. Additionally, the code generator must enforce Release barriers. Additionally, the code generator must enforce
ordering between SequeuentiallyConsistent stores followed by ordering between SequeuentiallyConsistent stores followed by
SequeuentiallyConsistent loads. On common architectures, this SequeuentiallyConsistent loads. This is usually done by emitting
requires emitting a full fence after SequeuentiallyConsistent stores.</dd> either a full fence before the loads or a full fence after the
stores; which is preferred varies by architecture.</dd>
</dl> </dl>
</div> </div>