[cfe-dev] Clang builtins for C++20 STL features

[JF Bastien via cfe-dev]

> On Nov 30, 2018, at 1:10 PM, James Y Knight <jyknight at google.com> wrote:
> 
> 
> 
> On Fri, Nov 30, 2018 at 4:06 PM JF Bastien <jfbastien at apple.com <mailto:jfbastien at apple.com>> wrote:
> 
> 
>> On Nov 30, 2018, at 12:39 PM, Casey Carter via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>> 
>> On Fri, Nov 30, 2018 at 12:35 PM James Y Knight via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>> On Thu, Nov 29, 2018, 9:53 PM Richard Smith via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org> wrote:
>> * P0528R3 Atomic Compare-And-Exchange With Padding Bits
>> We need compiler magic here, in some form. Billy O'Neal wrote to the C1XX team: "To implement the new atomic_ref as well as the change to compare the value representation of atomics only, the library needs a way to zero out the padding in arbitrary T, which we can't discover with library tech alone. We would like an intrinsic that accepts a trivially-copyable T and produces a copy with the padding zeroed, or takes a T* and zeros the padding inside that T, or similar."
>> 
>> I think this should be done in-place in memory; producing a copy has the problem that you're passing around a value of type T, and that might permit the padding bits to become undefined again.
>> 
>> void __builtin_clear_padding(T *ptr)
>> Effects: Set to zero all bits that are padding bits in the representation of every value of type T.
>> 
>> Is the intent here that every value stored into a std::atomic (e.g. via store, exchange, or compare_exchange) would be passed through __builtin_clear_padding first, before being stored into the atomic object? And presumably the same would need to occur implicitly for C-style `_Atomic T`?
>> 
>> Yes; see P0582R3 "The Curious Case of Padding Bits" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0528r3.html <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0528r3.html>) for details. The intent is to make compare-exchange work for types with padding bits by zeroing those padding bits before storing a value in an atomic or comparing with the value stored in an atomic.
> 
> I think you rather want to zero out padding bits in the atomic, not in the value, and you want to do it after storing into the atomic (unless you’re doing zeroing, and then copying the non-padding elements one at a time, in which case you could just memset instead of having a builtin).
> 
> Errr...certainly you can't do additional stores into an atomic after storing a new value into it, that would kinda ruin the "atomic" part.

Haha yeah you’re totally right! Ignore me, no idea what I was thinking.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181130/f31ef5bc/attachment.html>