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

[Richard Smith via cfe-dev]

On 25 May 2018 at 11:29, JF Bastien via cfe-dev <cfe-dev at lists.llvm.org>
wrote:

> 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
>
> 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).
>

Why do you propose modeling these as builtin functions rather than as
preprocessor defines? The latter is how we model every other similar
property.

*2. Compiler support*
>
>
>    1. Teach the target infrastructure that hardware interference size is
>    something they can specify (in tablegen files somewhere).
>    2. 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).
>    3. 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.
>    4. 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.
>    5. For generic le32 / be32 ARM targets expose constructive /
>    destructive as 64B.
>    6. For generic le64 / be64 ARM targets expose constructive as 64B and
>    destructive as 128B.
>    7. For generic x86 expose constructive / destructive as 64B.
>    8. Honor existing sub-target preferences (AFAICT x86 doesn’t have any,
>    ARM has some in AArch64Subtarget::initializeProperties). These
>    override the generic ones above.
>    9. 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
>
>
> _______________________________________________
> 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/20180525/8c2d030a/attachment.html>