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

JF Bastien via cfe-dev cfe-dev at lists.llvm.org
Tue Jul 30 21:00:43 PDT 2019 

> On Jul 30, 2019, at 8:59 PM, Billy O'Neal (VC LIBS) <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 <jfbastien at apple.com> on behalf of JF Bastien <jfbastien at apple.com>
> Sent: Tuesday, July 30, 2019 8:58:14 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
>  
> 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%7C5665cfc981d6467422ac08d7156b5a4d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637001423138742477&sdata=hHYErAA2WohoEM5GDdpGElWzPn4H3xGD%2B3A5R9YOwKE%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%7C5665cfc981d6467422ac08d7156b5a4d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637001423138752468&sdata=yZTakjbq0PLgRsyms%2FAD%2BJZ6PNrZSJmGxzCbQm8icH0%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190730/352931e5/attachment.html>

More information about the cfe-dev mailing list