<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 05/30/2018 02:38 PM, James Y Knight
via cfe-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAA2zVHp1Ke=-79vy0sAjLqC3p7yoB8JcM5ExdP-JHq2Ok5_q5g@mail.gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr"><br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, May 29, 2018 at 4:39 PM JF Bastien <<a
href="mailto:jfbastien@apple.com" target="_blank"
moz-do-not-send="true">jfbastien@apple.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word"><br>
<div>
<blockquote type="cite">
<div>On May 25, 2018, at 3:12 PM, James Y Knight <<a
href="mailto:jyknight@google.com" target="_blank"
moz-do-not-send="true">jyknight@google.com</a>>
wrote:</div>
<br
class="gmail-m_2238418630500924095m_8210435829298725463gmail-m_7831315883321387652Apple-interchange-newline">
<div>
<div dir="ltr"><br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, May 25, 2018 at 5:30 PM
JF Bastien <<a
href="mailto:jfbastien@apple.com"
target="_blank" moz-do-not-send="true">jfbastien@apple.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word"><br>
<div><br>
<blockquote type="cite">
<div>On May 25, 2018, at 2:23 PM, James
Y Knight <<a
href="mailto:jyknight@google.com"
target="_blank"
moz-do-not-send="true">jyknight@google.com</a>>
wrote:</div>
<br
class="gmail-m_2238418630500924095m_8210435829298725463gmail-m_7831315883321387652m_-939798776431736792Apple-interchange-newline">
<div>
<div dir="ltr">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>
<div><br>
</div>
<div>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>
</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>
</div>
</blockquote>
<div><br>
</div>
<div
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">Sure.
I'm not on the committee. Even if I was, I
certainly don't know that I would have
identified the problem...</div>
<div
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"><br>
</div>
<div
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">But
now that it has been identified, there's a
choice of what to do. And not implementing the
function (and presumably filing a DR saying
so) is seeming like a pretty reasonable
option.</div>
</div>
</div>
</div>
</blockquote>
</div>
<div><br>
</div>
The committee discussed ABI issues (Jacksonville 2016) and
decided that they’d rather have them than have a
proliferation of #define SOMETHING 64. That discussion
occurred with Google folks in the room, it might be higher
bandwidth to consult with them? The notes are
unfortunately quite sparse for that discussion.
<div><br>
<div>The libc++ community shouldn't decline to implement
a feature without bringing concrete feedback to the
committee. Without such feedback, I’d like to move
forward with an implementation plan, because we should
offer full C++17 support regardless of our distaste
for specific features. I’ve received good feedback on
the thread so far, I’m happy to leave the discussion
open for a bit, talk to committee people next week in
Rapperswil, and unless feedback goes the committee’s
way I’d like to pursue an implementation. Does this
sound fair?</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>There's been 3 options discussed so far -- I'm not sure
which (#1 or #2) you're now proposing to implement.</div>
<div><br>
</div>
<div>
<div
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">1.
Return an subtarget-dependent value, depending on the
exact CPU model selected at compile-time.</div>
<div
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">
Good: Allows for better memory-usage/performance.</div>
<div
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">
Bad: Potential risk of ODR violations/ABI issues, due to
dependency on cpu tuning flags.</div>
<div
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">
Bad: Potential risk of same across versions of the
compiler, if the default generic cpu tuning is changed.</div>
</div>
<div
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"><br>
</div>
<div>2. Choose a single "good enough" constant value for each
platform.</div>
<div> Good: eliminate ABI/ODR issues.</div>
<div> Bad: value might be too conservative for users'
desires.</div>
<div> e.g. returning 128 for
hardware_destructive_interference_size when 64 would've been
sufficient will waste memory.<br>
</div>
<div> Bad: Future CPU changes<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"> </span>might
invalidate the constant generic value, requiring either that
it be changed (introducing an ABI issue again), or remain
incorrect forever.</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">
e.g. </span>most ARM chips have had 64-byte cache-lines
for a while now, so that would've seemed the only reasonable
number to choose on ARM up until recently. But, now, some of
the newest CPUs have apparently switched to 128-byte
cache-lines; should we change to 128?</div>
<div><br>
</div>
<div>(Or, 2b: YOLO, 64 bytes should be good enough for all
platforms!)</div>
<div><br>
</div>
<div>3. Decline to implement at all.</div>
<div> Good: avoid these issues.</div>
<div> Bad: users who need it must do something themselves,
e.g. choose some arbitrary value e.g. 64.</div>
</div>
</div>
</blockquote>
<br>
I'll add to option 3: Cause many downstream organizations to carry
out-of-tree patches to implement the feature.<br>
<br>
-Hal<br>
<br>
<blockquote type="cite"
cite="mid:CAA2zVHp1Ke=-79vy0sAjLqC3p7yoB8JcM5ExdP-JHq2Ok5_q5g@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>