[PATCH] D129802: [DRAFT] Implementing new atomic orderings in LLVM and generate barriers for legacy __sync builtins. Support corresponding memory model in outline atomics as well.

[James Y Knight via Phabricator via cfe-commits]

jyknight added a comment.

In D129802#3654943 <https://reviews.llvm.org/D129802#3654943>, @Wilco1 wrote:

> The general requirement is that inline and outline atomics have identical behaviour, and that GCC and LLVM emit the same sequences. I agree sync is badly documented, so it's hard to figure whether an extra DMB barrier could actually make a difference, but it's best to be conservative with atomics. Also it was trivial to add (GCC just adds an extra flag for sync which then emits the extra barrier if the flag is set, so you don't need to introduce new atomic models).

But it _is_ a new atomic model. If we add this, then for every architecture LLVM supports, now or in the future, we'll need to figure out whether more barriers are needed in the "SYNC" mode vs C++11 standard memory orders. That's a non-trivial thing to ask.

> However if sync primitives are hardly used in the real world then perhaps it is about time to deprecate them with annoying warnings, and completely remove support next year. Does that sound reasonable?

I don't know that they are "hardly used" in the real world -- there is certainly legacy code using them, although I haven't attempted to quantify the amount. Another interesting question would be: how much of that code is actually correct, at all. I'd be rather surprised if someone could identify a single piece of software which is actually correct when using the __sync_* operations on GCC, but is incorrect on Clang.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129802/new/

https://reviews.llvm.org/D129802