git: 054ce2b03710 - main - atomic: add stub atomic_load_consume_ptr

[Jessica Clarke]

On 25 Jan 2021, at 22:42, Mateusz Guzik <mjg at FreeBSD.org> wrote:
> 
> The branch main has been updated by mjg:
> 
> URL: https://cgit.FreeBSD.org/src/commit/?id=054ce2b0371042c0dbc4b3ab1d7e7795ad75d51e
> 
> commit 054ce2b0371042c0dbc4b3ab1d7e7795ad75d51e
> Author:     Mateusz Guzik <mjg at FreeBSD.org>
> AuthorDate: 2021-01-25 20:09:41 +0000
> Commit:     Mateusz Guzik <mjg at FreeBSD.org>
> CommitDate: 2021-01-25 22:40:15 +0000
> 
>    atomic: add stub atomic_load_consume_ptr

Consume semantics is a waste of time, it's basically impossible to
implement in an optimising compiler as, in order to not emit the same
fences as an acquire, you need the source dependencies to be mapped to
data dependencies in the output assembly, but all manner of
transformations can cause that to break. And that's before you get to
hand-written atomic implementations where it is impossible for you to
ensure that, as you're not even telling the compiler what you're doing.
For example:

  int x = atomic_load_consume_int(p);
  int y = q[x - x];

This looks like stupid code, but the `x - x` cannot be constant-folded
without inserting a barrier, as currently there is data dependence at
the source level. If you use language-level atomics then it "works" by
virtue of compilers just turning consumes into acquires so the later
constant folding is safe. But if your atomic_load_consume_int is
hand-rolled magic assembly then the compiler has no clue and will
blindly go and constant fold that subtraction for you, completely
breaking your synchronisation.

Providing consume loads just doesn't make sense for FreeBSD's atomics
except for documenting the exact requirements of the code being written;
they can never be implemented as anything other than acquire loads
unless we migrate to using actual C11 atomics, but even then you won't
get any code generation difference and likely never will.

Jess