[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]

>MSVC’s volatiles on x86 were traditionally seq_cst when they could.

Normal loads are already seq_cst on x86 with no extra work. We still intend to use _InterlockedCompareExchange64 (on x86) or _InterlockedExchange64 (on amd64) to implement store. To be clear, this is in response to a specific customer bug where they want to put an atomic<8 bytes> into read only memory, and want load() to not break their program with STATUS_ACCESS_VIOLATION. ( https://developercommunity.visualstudio.com/content/problem/274938/vs2017-1567158p2-stdatomicload-causes-write-access.html )

>I think you should add type-generic versions as well.

I don't think C1XX or EDG have the ability to do that form of intrinsics right now, so to implement volatile_load/volatile_store we're going to need library tech that calls the __iso_volatile family.

>who doesn’t love C++ library features that require compiler support? Right Billy?

I don't hate things that require compiler support. I hate things that require compiler support of the form nobody has demonstrated to be reasonably implementable. Things that can be implemented in terms of traditional builtins or intrinsics (like volatile_load / volatile_store) are fine.

Billy3
________________________________
From: jfbastien at apple.com <jfbastien at apple.com> on behalf of JF Bastien <jfbastien at apple.com>
Sent: Tuesday, March 19, 2019 01:52 PM
To: Billy O'Neal (VC LIBS)
Cc: cfe-dev
Subject: Re: [cfe-dev] FYI, Intel folks might be looking to add the __iso_volatile_Xxx family for MSVC STL <atomic> soon

These? https://docs.microsoft.com/en-us/cpp/intrinsics/arm-intrinsics?view=vs-2017#IsoVolatileLoadStore<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fcpp%2Fintrinsics%2Farm-intrinsics%3Fview%3Dvs-2017%23IsoVolatileLoadStore&data=02%7C01%7Cbion%40microsoft.com%7C9e4e63a643884977521e08d6acacc3e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636886255355080579&sdata=zfDNjIZrzKkc3RvHQSGdUadTzJytsmU5vmBbwyk%2FJW0%3D&reserved=0>

__int16 __iso_volatile_load16(const volatile __int16 * Location)
__int32 __iso_volatile_load32(const volatile __int32 * Location)
__int64 __iso_volatile_load64(const volatile __int64 * Location)
__int8 __iso_volatile_load8(const volatile __int8 * Location)

void __iso_volatile_store16(volatile __int16 * Location, __int16 Value)
void __iso_volatile_store32(volatile __int32 * Location, __int32 Value)
void __iso_volatile_store64(volatile __int64 * Location, __int64 Value)
void __iso_volatile_store8(volatile __int8 * Location, __int8 Value)

Seems fine, given how MSVC’s volatiles on x86 were traditionally seq_cst when they could. I think the above match the LLVM IR semantics precisely.

I think you should add type-generic versions as well. Then you’ve got a nice builtin for volatile_load<T> / volatile_store<T><https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwg21.link%2FP1382&data=02%7C01%7Cbion%40microsoft.com%7C9e4e63a643884977521e08d6acacc3e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636886255355080579&sdata=H8iAKCg12tAuAqfupoU0MMPFYGrMxDc%2F3QxkPkbdRDE%3D&reserved=0>, and who doesn’t love C++ library features that require compiler support? Right Billy? 😁



On Mar 19, 2019, at 1:32 PM, Billy O'Neal (VC LIBS) via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:

I think Clang has those already implemented for ARM (since our <atomic> compiles there) but we are looking to use them instead of cmpxchg8b to implement load of atomic<8 bytes> on x86 soon.

Billy3
_______________________________________________
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%7C9e4e63a643884977521e08d6acacc3e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636886255355090573&sdata=amedPfjk4WtXDfRgivT9m3clPmrOQGfrl377SJOs7d8%3D&reserved=0>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190319/651be06d/attachment.html>