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

Billy O'Neal (VC LIBS) via cfe-dev cfe-dev at lists.llvm.org
Wed Jul 31 12:06:02 PDT 2019


[cid:image001.png at 01D54798.5211D880]

________________________________
From: jfbastien at apple.com <jfbastien at apple.com> on behalf of JF Bastien <jfbastien at apple.com>
Sent: Tuesday, July 30, 2019 9:00:43 PM
To: Billy O'Neal (VC LIBS) <bion at microsoft.com>
Cc: Eli Friedman <efriedma at quicinc.com>; rnk at google.com <rnk at google.com>; cfe-dev <cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] FYI, Intel folks might be looking to add the __iso_volatile_Xxx family for MSVC STL <atomic> soon


On Jul 30, 2019, at 8:59 PM, Billy O'Neal (VC LIBS) <bion at microsoft.com<mailto:bion at microsoft.com>> wrote:

These are the builtins I have, not necessarily the builtins I desire.

Definitely the builtins you deserve 🦹‍♂️


Billy3

________________________________
From: jfbastien at apple.com<mailto:jfbastien at apple.com> <jfbastien at apple.com<mailto:jfbastien at apple.com>> on behalf of JF Bastien <jfbastien at apple.com<mailto:jfbastien at apple.com>>
Sent: Tuesday, July 30, 2019 8:58:14 PM
To: Billy O'Neal (VC LIBS) <bion at microsoft.com<mailto:bion at microsoft.com>>
Cc: Eli Friedman <efriedma at quicinc.com<mailto:efriedma at quicinc.com>>; rnk at google.com<mailto:rnk at google.com> <rnk at google.com<mailto:rnk at google.com>>; cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Subject: Re: [cfe-dev] FYI, Intel folks might be looking to add the __iso_volatile_Xxx family for MSVC STL <atomic> soon

Eh, those aren’t the builtins I’d choose, but you do you… Reid’s implementation seems to match the quirks chosen, so I’m not sure there’s anything else to do here.


On Jul 30, 2019, at 8:54 PM, Billy O'Neal (VC LIBS) <bion at microsoft.com<mailto:bion at microsoft.com>> wrote:

> TL;DR: what are these _iso_ things?

They are volatile ops that are guaranteed to use 1 instruction to do that load. So for x86 that means using x87, or MMX, or SSE to do the load. They also suppress the ‘volatile is affected by the /volatile:ms vs. /volatile:iso setting’ warnings. <atomic> uses these in conjunction with barrier instrinsics.

#if defined(_M_ARM) || defined(_M_ARM64)
#define _Memory_barrier() __dmb(0xB) // inner shared data memory barrier
#define _Compiler_or_memory_barrier() _Memory_barrier()

#define _ISO_VOLATILE_STORE8(_Storage, _Value) __iso_volatile_store8(_Atomic_address_as<char>(_Storage), _Value)
#define _ISO_VOLATILE_STORE16(_Storage, _Value) __iso_volatile_store16(_Atomic_address_as<short>(_Storage), _Value)
#define _ISO_VOLATILE_STORE32(_Storage, _Value) __iso_volatile_store32(_Atomic_address_as<int>(_Storage), _Value)
#define _ISO_VOLATILE_STORE64(_Storage, _Value) __iso_volatile_store64(_Atomic_address_as<long long>(_Storage), _Value)
#define _ISO_VOLATILE_LOAD8(_Storage) __iso_volatile_load8(_Atomic_address_as<const char>(_Storage))
#define _ISO_VOLATILE_LOAD16(_Storage) __iso_volatile_load16(_Atomic_address_as<const short>(_Storage))

#elif defined(_M_IX86) || defined(_M_X64)
// x86/x64 hardware only emits memory barriers inside _Interlocked intrinsics
#define _Compiler_or_memory_barrier() _Compiler_barrier()

#define _ISO_VOLATILE_STORE8(_Storage, _Value) (*_Atomic_address_as<char>(_Storage) = _Value)
#define _ISO_VOLATILE_STORE16(_Storage, _Value) (*_Atomic_address_as<short>(_Storage) = _Value)
#define _ISO_VOLATILE_STORE32(_Storage, _Value) (*_Atomic_address_as<long>(_Storage) = _Value)
#define _ISO_VOLATILE_STORE64(_Storage, _Value) (*_Atomic_address_as<long long>(_Storage) = _Value)
#define _ISO_VOLATILE_LOAD8(_Storage) (*_Atomic_address_as<const char>(_Storage))
#define _ISO_VOLATILE_LOAD16(_Storage) (*_Atomic_address_as<const short>(_Storage))

#else // ^^^ x86/x64 / unsupported hardware vvv
#error Unsupported hardware
#endif // hardware


…. Later…

// in _Atomic_storage<1>
    _NODISCARD _Ty load() const noexcept { // load with sequential consistency
        char _As_bytes = _ISO_VOLATILE_LOAD8(_Storage);
        _Compiler_or_memory_barrier();
        return reinterpret_cast<_Ty&>(_As_bytes);
    }

    _NODISCARD _Ty load(const memory_order _Order) const noexcept { // load with given memory order
        char _As_bytes = _ISO_VOLATILE_LOAD8(_Storage);
        _Load_barrier(_Order);
        return reinterpret_cast<_Ty&>(_As_bytes);
    }

Billy3

From: JF Bastien<mailto:jfbastien at apple.com>
Sent: Tuesday, July 30, 2019 8:43 PM
To: Eli Friedman<mailto:efriedma at quicinc.com>
Cc: rnk at google.com<mailto:rnk at google.com>; Billy O'Neal (VC LIBS)<mailto:bion at microsoft.com>; cfe-dev<mailto:cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] FYI, Intel folks might be looking to add the __iso_volatile_Xxx family for MSVC STL <atomic> soon




On Jul 30, 2019, at 5:21 PM, Eli Friedman via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:

From: cfe-dev <cfe-dev-bounces at lists.llvm.org<mailto:cfe-dev-bounces at lists.llvm.org>> On Behalf Of Reid Kleckner via cfe-dev
Sent: Tuesday, July 30, 2019 4:54 PM
To: Billy O'Neal (VC LIBS) <bion at microsoft.com<mailto:bion at microsoft.com>>
Cc: cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Subject: [EXT] Re: [cfe-dev] FYI, Intel folks might be looking to add the __iso_volatile_Xxx family for MSVC STL <atomic> soon

On Tue, Jul 30, 2019 at 4:15 PM Billy O'Neal (VC LIBS) <bion at microsoft.com<mailto:bion at microsoft.com>> wrote:
> we can worry about optimization, perhaps using _Atomic, later

We can’t use _Atomic because it would not be ABI compatible with our std::atomic; in particular, because we put the spinlock for non-lock-free atomics inside the atomic, for instance. And because that isn’t a thing for some of our supported frontends.

It is possible that there are different intrinsics we could call for Clang that would make you folks happier, but we don’t know what those are or even if they exist at present.

I was thinking that perhaps the _Atomic_address_as template would do the necessary casts to use it when necessary without changing the storage type inside the std::atomic object.

There are actually multiple APIs to access C++11 atomics in clang, since we invented APIs in parallel with gcc.  The __atomic_* builtins (https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc%2F_005f_005fatomic-Builtins.html&data=02%7C01%7Cbion%40microsoft.com%7Ce5cdfd7a59ef4bc401c808d7156bc3cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637001424903353452&sdata=0HD%2Fnjljz37kArc%2BBOnIBT7ZLlt%2F3zKYeGmpOMHFlew%3D&reserved=0>) don’t require the use of _Atomic types.

Using volatile loads and stores with barriers probably prevents the compiler from performing any breaking optimizations, assuming the RMW atomics are protected appropriately, and the user doesn’t call any of the clang atomic builtins directly.  But it’s not a good idea; it won’t optimize well.  For example, on AArch64, it will prevent the compiler from using the dedicated load-acquire and store-release instructions.

TL;DR: what are these _iso_ things? I read the bug report, I don’t see the details I’d expect.
I think the __atomic_* builtins should work as Eli suggests.



-Eli
_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcfe-dev&data=02%7C01%7Cbion%40microsoft.com%7Ce5cdfd7a59ef4bc401c808d7156bc3cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637001424903353452&sdata=YPtBoQ%2FYgbB9oVZCAVv0yq0Myjsj5k6aNreh1qO41N8%3D&reserved=0>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190731/2350385d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 9F86E4F3B0B0430399A2CC2EBEF87ED8.png
Type: image/png
Size: 27674 bytes
Desc: 9F86E4F3B0B0430399A2CC2EBEF87ED8.png
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190731/2350385d/attachment.png>


More information about the cfe-dev mailing list