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

[Eli Friedman]

On Thu, Aug 11, 2011 at 5:36 PM, Andrew Trick <atrick at apple.com> wrote:
> Author: atrick
> Date: Thu Aug 11 19:36:38 2011
> New Revision: 137403
>
> URL: http://llvm.org/viewvc/llvm-project?rev=137403&view=rev
> Log:
> Clarify the definition of SequentiallyConsistent operations.
>
> 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=137403&r1=137402&r2=137403&view=diff
> ==============================================================================
> --- llvm/trunk/docs/Atomics.html (original)
> +++ llvm/trunk/docs/Atomics.html Thu Aug 11 19:36:38 2011
> @@ -330,9 +330,10 @@
>
>  <div>
>
> -<p>SequentiallyConsistent (<code>seq_cst</code> in IR) provides Acquire and/or
> -   Release semantics, and in addition guarantees a total ordering exists with
> -   all other SequentiallyConsistent operations.
> +<p>SequentiallyConsistent (<code>seq_cst</code> in IR) provides
> +   Acquire semantics for loads and Release semantics for
> +   stores. Additionally, it guarantees that a total ordering exists
> +   between all SequentiallyConsistent operations.
>
>  <dl>
>   <dt>Relevant standard</dt>
> @@ -344,11 +345,17 @@
>       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; the
> -      the possible optimizations are usually not interesting.</dd>
> +  <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>

It's legal, but how is it likely to improve performance?  I can't
think of any transformation that would try to do this... maybe GVN?

>   <dt>Notes for code generation</dt>
> -  <dd>SequentiallyConsistent operations generally require the strongest
> -      barriers supported by the architecture.</dd>
> +  <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>
>  </dl>

See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2745.html
?  It's actually kind of nasty: you can implement seq_cst load/store
by add a fence for either the load or the store, and people don't
appear to be making the choice consistently.

-Eli