<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, May 25, 2018 at 3:41 PM Richard Smith via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 25 May 2018 at 12:15, Hal Finkel via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><span class="m_-673156568187310786gmail-">
<p><br>
</p>
<div class="m_-673156568187310786gmail-m_-7615144704090997817moz-cite-prefix">On 05/25/2018 02:01 PM, Friedman, Eli
via cfe-dev wrote:<br>
</div>
<blockquote type="cite">
<div class="m_-673156568187310786gmail-m_-7615144704090997817moz-cite-prefix">On 5/25/2018 11:46 AM, JF Bastien
wrote:<br>
</div>
<blockquote type="cite"> <br>
<div><br>
<blockquote type="cite">
<div>On May 25, 2018, at 11:38 AM, Friedman, Eli
<<a href="mailto:efriedma@codeaurora.org" target="_blank">efriedma@codeaurora.org</a>>
wrote:</div>
<br class="m_-673156568187310786gmail-m_-7615144704090997817Apple-interchange-newline">
<div>
<div bgcolor="#FFFFFF">
<div class="m_-673156568187310786gmail-m_-7615144704090997817moz-cite-prefix">On 5/25/2018 11:29 AM, JF
Bastien via cfe-dev wrote:<br>
</div>
<blockquote type="cite">
<div>
<div>
<ol class="m_-673156568187310786gmail-m_-7615144704090997817MailOutline">
<li>Teach the target infrastructure
that hardware interference size is something
they can specify (in tablegen files
somewhere).</li>
<li>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>
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>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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>
</div>
</blockquote>
<br>
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>
</blockquote>
<br></span>
Unfortunately, to define structure layouts they need to be constant.<br>
<br>
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></div></blockquote><div><br></div><div>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><br></div><div>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><br></div><div><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);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">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><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);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><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);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">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><br></div></div></div>