[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