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

Eric Fiselier via cfe-dev cfe-dev at lists.llvm.org
Thu Nov 29 22:36:57 PST 2018


On Thu, Nov 29, 2018 at 9:53 PM Richard Smith via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Thu, 29 Nov 2018 at 17:55, Stephan T. Lavavej via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> Hi Clang devs,
>>
>> WG21 has voted in a bunch of C++20 STL features that need compiler
>> support via builtins/intrinsics. As usual, MSVC's STL would like to use
>> identically-named builtins for Clang, C1XX, and EDG, so I wanted to ask if
>> you've chosen any names (and interfaces) yet. Also as usual, I have utterly
>> no opinion about naming - any name that gets the compiler to do my work for
>> me is amazing (as long as all compilers are consistent). :-)
>>
>> * P0595R2 std::is_constant_evaluated()
>> Should this be __is_constant_evaluated() or
>> __builtin_is_constant_evaluated() or something else?
>>
>
> For us (and I'd guess for GCC), __builtin_is_constant_evaluated() would be
> the most natural choice.
>
> * P0482R6 char8_t
>> Given std::is_constant_evaluated(), we might not need anything new here.
>> Otherwise, should there be analogues of __builtin_memcmp(),
>> __builtin_strlen(), and __builtin_char_memchr() for constexpr
>> char_traits<char8_t>?
>>
>
> These seem low-priority given std::is_constant_evaluated(), but I think it
> might still be nice to have the builtins even if you don't formally need
> them. Our __builtin_mem* and __builtin_str* are a lot faster to evaluate
> than the equivalent hand-rolled C++ code would be. (Clang has a
> __has_builtin builtin macro to allow these to be detected and used if
> available. Does MSVC have anything similar?)
>
> Approximately following the naming convention of wcscmp etc, maybe
> __builtin_u8scmp, __builtin_u8slen, __builtin_u8scpy, ...? (Should we also
> add __builtin_u16s* and __builtin_u32s* while we're here?)
>
> * P0476R2 std::bit_cast()
>> This came up a month ago, where Richard Smith suggested
>> __builtin_bit_cast(To, value) or __bit_cast<To>(value), preferring the
>> former (for C friendliness). Was a final name chosen?
>>
>
> (I need to keep reminding myself: this can't be __builtin_bit_cast(&dest,
> &src) because the To type might not be default-constructible.)
>
> Unless someone wants to provide a counterargument, let's go with
> __builtin_bit_cast(To, value).
>
> constexpr T __builtin_bit_cast(typename T, const U &src)
> Effects: Bit-cast the value of src to type T. Ill-formed if T and U are of
> different sizes. Only guaranteed to be usable in constant expressions in
> the conditions specified for std::bit_cast.
>
>
>> * 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.
>
> Do we need to allow this to be called in constant expressions?
>
>
>> * P0758R1 std::is_nothrow_convertible
>> This can be implemented without an intrinsic (std::is_nothrow_invocable_r
>> already demands it; std::is_convertible plus noexcept plus library
>> cleverness works), but an intrinsic is higher throughput (and simpler for
>> third-party libraries that want to imitate the STL without using the STL
>> for whatever reason). MSVC's spelling for the plain trait is
>> __is_convertible_to(From, To); should the new trait be
>> __is_nothrow_convertible_to(From, To) or __is_nothrow_convertible(From, To)?
>>
>
> I would generally prefer that we expose traits that exactly match the
> library requirements with the same name as the library trait with a leading
> dunder, with an argument list matching the library trait. So:
> Add __is_convertible(From, To) and __is_nothrow_convertible(From, To)
> Make __is_convertible_to a (deprecated) synonym for __is_convertible.
>
> * P1007R3 std::assume_aligned()
>> MSVC supports a general __assume() although I'm unsure if it's
>> applicable/desirable here. Should there be a dedicated builtin?
>>
>
> Well, Clang already supports __assume() for MSVC compatibility (only in MS
> mode) and __builtin_assume() (our preferred spelling, available in
> general). But a general assume intrinsic is probably not the best choice
> here.
>
> Clang and GCC also already have:
>
> void *__builtin_assume_aligned(const void *p, size_t align, size_t
> offset_from_aligned = 0)
> See https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
>
> That's not ideal because it's not const-correct.
>
> Even for library wording, the spec is weak on specifying when a call to
> std::assume_aligned is allowed in constant expressions. For Clang at least,
> we treat a call to __builtin_assume_aligned as non-constant if we cannot
> prove the object is suitably aligned (that is, if the complete object's
> alignment and the offset within it don't result in a suitable alignment)
> even if we happen to know that (for instance) a global variable will
> typically be aligned to 16 bytes in practice.
>

Could `std::assume_aligned` be correctly implemented on top of
`__attribute__((assume_aligned(N)))` instead? This solves the constexpr and
const-correctness problems, and it doesn't depend on `std::assume_aligned`
getting inlined to work.


>
>
>> * I think this list is complete but I might be missing some features.
>>
>
> How about:
> * invocation type traits from Library Fundamentals V1
> * source_location from Library Fundamentals V2
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181130/8ee232c0/attachment.html>


More information about the cfe-dev mailing list