<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><blockquote type="cite" class=""><div class="">On May 30, 2018, at 12:38 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" 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=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, May 29, 2018 at 4:39 PM JF Bastien <<a href="mailto:jfbastien@apple.com" target="_blank" class="">jfbastien@apple.com</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 style="word-wrap: break-word;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 25, 2018, at 3:12 PM, James Y Knight <<a href="mailto:jyknight@google.com" target="_blank" class="">jyknight@google.com</a>> wrote:</div><br class="gmail-m_2238418630500924095m_8210435829298725463gmail-m_7831315883321387652Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, May 25, 2018 at 5:30 PM JF Bastien <<a href="mailto:jfbastien@apple.com" target="_blank" class="">jfbastien@apple.com</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 style="word-wrap: break-word;" class=""><br class=""><div class=""><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" target="_blank" class="">jyknight@google.com</a>> wrote:</div><br class="gmail-m_2238418630500924095m_8210435829298725463gmail-m_7831315883321387652m_-939798776431736792Apple-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 class=""><br class=""></div><div class="">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 class=""><br class=""></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);" class="">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);" class=""><br class=""></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);" class="">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 class=""><br class=""></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 class=""><br class=""><div class="">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 class=""><br class=""></div><div class="">There's been 3 options discussed so far -- I'm not sure which (#1 or #2) you're now proposing to implement.</div></div></div></div></blockquote><div><br class=""></div><div>It’ll depend on what people think of these options next week.</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_quote"><div class=""><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);" class="">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);" class=""> 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);" class=""> 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);" class=""> 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);" class=""><br class=""></div><div class="">2. Choose a single "good enough" constant value for each platform.</div><div class=""> Good: eliminate ABI/ODR issues.</div><div class=""> Bad: value might be too conservative for users' desires.</div><div class=""> e.g. returning 128 for hardware_destructive_interference_size when 64 would've been sufficient will waste memory.<br class=""></div><div class=""> 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); float: none; display: inline;" class=""> </span>might invalidate the constant generic value, requiring either that it be changed (introducing an ABI issue again), or remain incorrect forever.</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=""> e.g.<span class="Apple-converted-space"> </span></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 class=""><br class=""></div><div class="">(Or, 2b: YOLO, 64 bytes should be good enough for all platforms!)</div><div class=""><br class=""></div><div class="">3. Decline to implement at all.</div><div class=""> Good: avoid these issues.</div><div class=""> Bad: users who need it must do something themselves, e.g. choose some arbitrary value e.g. 64.</div></div></div></div></blockquote></div><br class=""></body></html>