[cfe-dev] [RFC] C++17 hardware constructive / destructive interference size

[JF Bastien via cfe-dev]

Hi atomic fans 🤘⚛️🤟 (and non-fans I guess),

C++17 adds support for hardware destructive / constructive interference size constexpr values.
cppreference: https://en.cppreference.com/w/cpp/thread/hardware_destructive_interference_size <https://en.cppreference.com/w/cpp/thread/hardware_destructive_interference_size>
Paper with motivation: http://wg21.link/P0154 <http://wg21.link/P0154>
I volunteer to implement the necessary bits to support this in clang and libc++, and to give them proper values for current ARM and x86 processors. I’ve discussed this plan with other libc++ folks as well as libstdc++ / GCC folks, and we plan to implement the same builtins in both toolchains as well as adopt the same constexpr values wherever possible to keep ABIs compatible.

Under this plan, ARM and x86 will properly expose the new values in libc++, and other targets will automagically expose these values in C++ when they’re updated with target-specific values in their target tablegen file. After a while targets that haven’t settled on values will fail that one libc++ C++17 conformance test (for now the test will only check targets which expose the builtin).

FWIW MSVC already exposes this, but since they support fewer targets they decided on what everyone knows the right value is to expose: 64B. We’re not so fortunate, so bear with me as I propose a plan:


1. Standard library support

Add the following code to header <new>:

#if (__cplusplus >= 201703L) && __has_builtin(__builtin_hardware_destructive_interference_size) && __has_builtin(__builtin_hardware_constructive_interference_size)
inline constexpr std::size_t hardware_destructive_interference_size = __builtin_hardware_destructive_interference_size();
inline constexpr std::size_t hardware_constructive_interference_size = __builtin_hardware_constructive_interference_size();
#endif

Add corresponding tests which ensure that both values are at least alignof(std::max_align_t), and are constexpr. Conditionalize these tests on the same __has_builtin test for now. File a bug and leave a FIXME to move the test to just #if __cplusplus >= 201703L once targets have adopted this. libc++ will keep the __has_builtin test so that it’ll compile just fine even if the builtin ins’t defined, it just won’t expose the values (so user code will only fail if they try to use these values).


2. Compiler support

Teach the target infrastructure that hardware interference size is something they can specify (in tablegen files somewhere).
Allow overriding the value in sub-targets using -march or -mcpu (the sub-target defines the numeric value, and the user gets the overriden one by using -march or -mcpu).
Allow overriding the value (or defining, if the target doesn’t already) on the command line using flags -mhardware-destructive-interference-size and -mhardware-constructive-interference-size. Initially I thought we’d go with -mattr, but those don’t really allow values being passed.
In clang, if these properties are set, expose the builtin. Don’t expose a builtin if the value is not set by the target or on the command-line, such that the STL won’t expose a random value. I’ll expose them even if we’re in pre-C++17 mode, because they’re builtins and libc++ only exposes the constexpr value if we’re in C++17 or later.
For generic le32 / be32 ARM targets expose constructive / destructive as 64B.
For generic le64 / be64 ARM targets expose constructive as 64B and destructive as 128B.
For generic x86 expose constructive / destructive as 64B.
Honor existing sub-target preferences (AFAICT x86 doesn’t have any, ARM has some in AArch64Subtarget::initializeProperties). These override the generic ones above.
Leave other targets as-is for now, since I can’t test them and I don’t know what the appropriate values would be. Hopefully this RFC will elicit feedback as to what the appropriate values are.


What do y’all think?

Thanks,

JF

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