[cfe-dev] FYI, Intel folks might be looking to add the __iso_volatile_Xxx family for MSVC STL <atomic> soon

[Reid Kleckner via cfe-dev]

On Thu, Mar 28, 2019 at 2:28 PM Billy O'Neal (VC LIBS) <bion at microsoft.com>
wrote:

> >Are you sure we shouldn't be marking these as atomic instead of
> volatile? Volatile is usually not suitable for anything except
>
> I am implementing <atomic> 🙂
>

My concern is that volatile in LLVM has nothing to do with atomicity, and I
think what you really want is LLVM atomic loads and stores, with real
ordering markers of monotonic, seq_cst, release, acquire, etc. This is all
described here:
https://llvm.org/docs/LangRef.html#volatile-memory-accesses
https://llvm.org/docs/LangRef.html#memory-model-for-concurrent-operations
In particular: "The optimizers may change the order of volatile operations
relative to non-volatile operations. This is not Java’s “volatile” and has
no cross-thread synchronization behavior."

So, I'm concerned that there is something subtly incorrect about using
__iso_volatile_* to implement atomics.

After looking at the xatomic.h source, I think I have a better
understanding of what is going on. I added some folks who probably have a
better understanding of LLVM IR atomics, and maybe they can help guide the
discussion to a simpler implementation of Visual C++ <atomic> that plays
well with LLVM. We had a similar discussion about over- or under-emitting
dmb fences in this code review: https://reviews.llvm.org/D52807.

The Visual C++ headers currently add fences for ARM themselves. The code
looks like this: https://reviews.llvm.org/P8137 In small test cases, this
generates the appropriate code, a single load followed by a fence.

-----

Completely aside from improving the implementation of <atomic> with clang,
I will go ahead and make those __iso_volatile_* intrinsics available
everywhere.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190328/fdd94112/attachment.html>