<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Hi atomic fans đ¤âď¸đ¤ (and non-fans I guess),</div><div class=""><br class=""></div><div class="">C++17 adds support for hardware destructive / constructive interference size constexpr values.</div><ul class=""><li class="">cppreference: <a href="https://en.cppreference.com/w/cpp/thread/hardware_destructive_interference_size" class="">https://en.cppreference.com/w/cpp/thread/hardware_destructive_interference_size</a></li><li class="">Paper with motivation: <a href="http://wg21.link/P0154" class="">http://wg21.link/P0154</a></li></ul><div class="">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.</div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><b class="">1. Standard library support</b></div><div class=""><br class=""></div><div class="">Add the following code to header <font face="Courier New" class=""><new></font>:</div><div class=""><br class=""></div><div class=""><font face="Courier New" class="">#if (</font><span style="font-family: "Courier New";" class="">__cplusplus >= 201703L</span><span style="font-family: "Courier New";" class="">) && __has_builtin(__builtin_hardware_destructive_interference_size) && __has_builtin(__builtin_hardware_constructive_interference_size)</span></div><font face="Courier New" class="">inline constexpr std::size_t hardware_destructive_interference_size = __builtin_hardware_destructive_interference_size();<br class="">inline constexpr std::size_t hardware_constructive_interference_size = __builtin_hardware_constructive_interference_size();</font><div class=""><font face="Courier New" class="">#endif</font></div><div class=""><br class=""></div><div class="">Add corresponding tests which ensure that both values are at least <font face="Courier New" class="">alignof(std::max_align_t)</font>, 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 <font face="Courier New" class="">#if __cplusplus >= 201703L</font> 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).</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">2. Compiler support</b></div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">Teach the target infrastructure that hardware interference size is something they can specify (in tablegen files somewhere).</li><li class="">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).</li><li class="">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.</li><li class="">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.</li><li class="">For generic le32 / be32 ARM targets expose constructive / destructive as 64B.</li><li class="">For generic le64 / be64 ARM targets expose constructive as 64B and destructive as 128B.</li><li class="">For generic x86 expose constructive / destructive as 64B.</li><li class="">Honor existing sub-target preferences (AFAICT x86 doesnât have any, ARM has some in AArch64Subtarget::initializeProperties). These override the generic ones above.</li><li class="">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.</li></ol><div class=""><br class=""></div><div class=""><br class=""></div><div class="">What do yâall think?</div><div class=""><br class=""></div><div class="">Thanks,</div><div class=""><br class=""></div><div class="">JF</div></div></div><div class=""><br class=""></div></body></html>