<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=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 25, 2018, at 12:33 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" class="">richard@metafoo.co.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_extra"><div class="gmail_quote">On 25 May 2018 at 11:29, JF Bastien via cfe-dev<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word; 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" target="_blank" class="">https://en.<wbr class="">cppreference.com/w/cpp/thread/<wbr class="">hardware_destructive_<wbr class="">interference_size</a></li><li class="">Paper with motivation: <a href="http://wg21.link/P0154" target="_blank" class="">http://wg21.link/<wbr class="">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<span class="Apple-converted-space"> </span><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_<wbr class="">hardware_destructive_<wbr class="">interference_size) && __has_builtin(__builtin_<wbr class="">hardware_constructive_<wbr class="">interference_size)</span></div><font face="Courier New" class="">inline constexpr std::size_t hardware_destructive_<wbr class="">interference_size = __builtin_hardware_<wbr class="">destructive_interference_size(<wbr class="">);<br class="">inline constexpr std::size_t hardware_constructive_<wbr class="">interference_size = __builtin_hardware_<wbr class="">constructive_interference_<wbr class="">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_<wbr class="">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><span class="Apple-converted-space"> </span>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></div></blockquote><div class=""><br class=""></div><div class="">Why do you propose modeling these as builtin functions rather than as preprocessor defines? The latter is how we model every other similar property.</div></div></div></div></div></blockquote><div><br class=""></div><div>We discussed both, nobody really cared either way, so builtins won. Macro is fine as well.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word; line-break: after-white-space;" class=""><div class=""><div class=""><b class="">2. Compiler support</b></div><div class=""><br class=""></div><div class=""><ol class="m_-8653786450383193184MailOutline"><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-<wbr class="">interference-size and -mhardware-constructive-<wbr class="">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::<wbr class="">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></div><br class="">______________________________<wbr class="">_________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/cfe-dev</a></blockquote></div></div></div></div></blockquote></div><br class=""></body></html>