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

[James Y Knight via cfe-dev]

On Fri, Nov 30, 2018 at 4:06 PM JF Bastien <jfbastien at apple.com> wrote:

>
>
> On Nov 30, 2018, at 12:39 PM, Casey Carter via cfe-dev <
> 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> wrote:
>
>> On Thu, Nov 29, 2018, 9:53 PM Richard Smith via cfe-dev <
>> 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) 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181130/68aedbfd/attachment.html>