<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 2:23 PM, James Y Knight <<a href="mailto:jyknight@google.com" class="">jyknight@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">My own employer doesn't make ABI stability promises for that code, and thus is fine with changing the value anytime it feels like. That's not a generically viable strategy for a value provided by the standard library.<div class=""><div class=""><br class=""></div><div class="">Additionally, before I sent that email, I looked at a number of the uses, and it appeared as though a great many could be easily modified to use a runtime-determined alignment.</div></div></div></div></blockquote><div><br class=""></div><div>That would be useful feedback on the paper… prior to it getting into C++17. The committee’s POV voting the paper in was that having a constexpr value was something we wanted, and so that’s what we have. At this point in time I’d like to focus on implementing C++17 as it is, and / or filing DRs as required.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, May 25, 2018 at 5:07 PM JF Bastien <<a href="mailto:jfbastien@apple.com" class="">jfbastien@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On May 25, 2018, at 2:01 PM, James Y Knight via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="m_-2302698521850545600Apple-interchange-newline"><div class=""><div dir="ltr" style="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;text-decoration:none" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, May 25, 2018 at 3:41 PM Richard Smith via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></div><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 dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On 25 May 2018 at 12:15, Hal Finkel via cfe-dev<span class="m_-2302698521850545600Apple-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="m_-2302698521850545600Apple-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 bgcolor="#FFFFFF" class=""><span class="m_-2302698521850545600m_-673156568187310786gmail-"><p class=""><br class=""></p><div class="m_-2302698521850545600m_-673156568187310786gmail-m_-7615144704090997817moz-cite-prefix">On 05/25/2018 02:01 PM, Friedman, Eli via cfe-dev wrote:<br class=""></div><blockquote type="cite" class=""><div class="m_-2302698521850545600m_-673156568187310786gmail-m_-7615144704090997817moz-cite-prefix">On 5/25/2018 11:46 AM, JF Bastien wrote:<br class=""></div><blockquote type="cite" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On May 25, 2018, at 11:38 AM, Friedman, Eli <<a href="mailto:efriedma@codeaurora.org" target="_blank" class="">efriedma@codeaurora.org</a>> wrote:</div><br class="m_-2302698521850545600m_-673156568187310786gmail-m_-7615144704090997817Apple-interchange-newline"><div class=""><div bgcolor="#FFFFFF" class=""><div class="m_-2302698521850545600m_-673156568187310786gmail-m_-7615144704090997817moz-cite-prefix">On 5/25/2018 11:29 AM, JF Bastien via cfe-dev wrote:<br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><ol class="m_-2302698521850545600m_-673156568187310786gmail-m_-7615144704090997817MailOutline"><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></ol></div></div></blockquote><br class="">We can't change the value based on -mcpu. We generally allow mixing code built with different values of -mcpu. And any code which is linked together must use the same value for hardware_destructive_interference_size, or else we violate ODR.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Interesting point. The case I’d like to cover is one where the developer wants to get the exact right value for their particular CPU, instead of a conservative answer with extra padding. How do you think we should meet this use case?</div><br class=""></div></blockquote><br class="">Go back to the standards committee and ask for a function that isn't constexpr? I can't think of any other reasonable solution.<br class=""></blockquote><br class=""></span>Unfortunately, to define structure layouts they need to be constant.<br class=""><br class="">The best solution I've thought of is to extend the abi_tag support to force the mangling of interfaces depending on values of these constructs to be different.<br class=""></div></blockquote><div class=""><br class=""></div><div class="">abi_tag is not an effective way of maintaining ABI, because it needs to be "viral" / transitive, and can't be (at least, not without huge developer effort).</div><div class=""><br class=""></div><div class="">Perhaps we could add an attribute to hardware_{con,de}structive_interference_size that produces a warning if they are used outside the main source file? We'd also need to make them non-inline, which is an observable conformance break, but seems unlikely to be important compared to the other issues.</div></div></div></div></blockquote><div class=""><br class=""></div><div class=""><span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);float:none;display:inline" class="">It'd certainly be unreasonable for a C++ stdlib to promise that the CPU's cache layout will never change. And, IMO, we'd be better off not implementing these functions, rather than trying to work around the issue with various warnings/restrictions.</span></div><div class=""><span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);float:none;display:inline" class=""><br class=""></span></div><div class=""><span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);float:none;display:inline" class="">ISTM that user requirements may actually be best served by a non-constexpr function which can safely return the correct value on any platform. The situations where it's not feasible to use dynamically-allocated memory for such an object seem pretty slim. And if you're dynamically allocating memory, passing a runtime-constant alignment to the allocator is fine.</span></div></div></div></div></blockquote><br class=""></div><div class="">I disagree, we need a constexpr value. The original paper has an example, from your own employer, which you’ll find copy / pasted all over the various forks of base/. Plenty of other projects just hard-code 64.</div><br class=""></div></blockquote></div>
</div></blockquote></div><br class=""></body></html>