[LLVMdev] Intended semantics for ``fence seq_cst``

[JF Bastien]

Hi,

TL;DR: should we add a new memory ordering to fences?


``fence seq_cst`` is currently use to represent two things:
 - GCC-style builtin ``__sync_synchronize()`` [0][1].
 - C11/C++11's sequentially-consistent thread fence
``std::atomic_thread_fence(std::memory_order_seq_cst)`` [2].

As far as I understand:
 - The former orders all memory and emits an actual fence instruction.
 - The latter only provides a total order with other
sequentially-consistent loads and stores, which means that it's
possible to move non-sequentially-consistent loads and stores around
it.

The GCC-style builtin effectively does the same as the C11/C++11
sequentially-consistent thread fence, surrounded by compiler barriers
(``call void asm sideeffect "", "~{memory}"``).

The LLVM language reference [3] describes ``fence seq_cst`` in terms
of the C11/C++11 primitive, but it looks like LLVM's codebase treats
it like the GCC-style builtin. That's strictly correct, but it seems
desirable to represent the GCC-style builtin with a ninth
LLVM-internal memory ordering that's stricter than
``llvm::SequentiallyConsistent``. ``fence seq_cst`` could then fully
utilize C11/C++11's semantics, without breaking the GCC-style builtin.
>From C11/C++11's point of view this other memory ordering isn't useful
because the primitives offered are sufficient to express valid and
performant code, but I believe that LLVM needs this new memory
ordering to accurately represent the GCC-style builtin while fully
taking advantage of the C11/C++11 memory model.

Am I correct?

I don't think it's worth implementing just yet since C11/C++11 are
still relatively new, but I'd like to be a bit forward looking for
PNaCl's sake.

Thanks,

JF


[0] http://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/_005f_005fsync-Builtins.html
[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793
[2] C++11 Standard section 29.8 - Fences
[3] http://llvm.org/docs/LangRef.html#fence-instruction