Re: [PATCH memory-barriers.txt 1/7] documentation: Clarify relationship of barrier() to control dependencies

[Steven Rostedt]

On Tue, 12 Apr 2016 08:52:49 -0700
"Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> wrote:

> The current documentation claims that the compiler ignores barrier(),
> which is not the case.  Instead, the compiler carefully pays attention
> to barrier(), but in a creative way that still manages to destroy
> the control dependency.  This commit sets the story straight.
> 
> Reported-by: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx>
> Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>
> ---
>  Documentation/memory-barriers.txt | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> index 3729cbe60e41..ec1289042396 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -813,9 +813,10 @@ In summary:
>        the same variable, then those stores must be ordered, either by
>        preceding both of them with smp_mb() or by using smp_store_release()
>        to carry out the stores.  Please note that it is -not- sufficient
> -      to use barrier() at beginning of each leg of the "if" statement,
> -      as optimizing compilers do not necessarily respect barrier()
> -      in this case.
> +      to use barrier() at beginning of each leg of the "if" statement
> +      because, as shown by the example above, optimizing compilers can
> +      destroy the control dependency while respecting the letter of the
> +      barrier() law.

Which country has the jurisdiction over this barrier() law?

What about "the letter of the barrier() rules"?

-- Steve

>  
>    (*) Control dependencies require at least one run-time conditional
>        between the prior load and the subsequent store, and this