<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-03-29 20:30 GMT-07:00 Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Mar 29, 2017, at 20:16, Eric Fiselier <<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>> wrote:</div><br class="m_-7435804651188982563Apple-interchange-newline"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 29, 2017 at 9:00 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Why are we propagating the use of always_inline?<br></blockquote><div><br></div><div>The intent of this change wasn't to propagate or remove always_inline from any functions. It was to fix incompatible dylibs built by GCC.</div><div>The way it did that is by removing the __attribute__((visibility("<wbr>hidden"))) part while building the dylib, because GCC was ignoring the</div><div>`visibility("default")` on the extern template declarations for basic string.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In other places, we use always_inline to avoid affecting ABI (a visibility hack).  But you're not removing basic_string from the dylib here.<br></blockquote><div><br></div><div>That's a very good point. It's likely we should convert many of the `_LIBCPP_ALWAYS_INLINE`s to inline instead and the compiler should</div><div>do the right thing. However that change is orthogonal to this one, and hence it wasn't made here.</div></div></div></div></div></blockquote><div><br></div></span><div>Reading comprehension issue on my part.  I think probably replied to the wrong commit.  Bisection pointed at r278356, but I saw that that commit was reverted and I couldn't find where it finally landed.  So then I did a careless git-blame for what I thought was the relevant line and ended up here.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Also I think the doc for _LIBCPP_EXTERN_TEMPLATE_<wbr>INLINE_VISIBILITY is misleading. I'll try to update it in the coming days.</div></div></div></div></div></blockquote><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It has major downsides:<br>
- It causes inlining at -O0, which causes major regressions in debugging experiences.<br>
- It causes inlining at -O0, which, without other optimizations, can blow up stack size of static_initializers.<br></blockquote></div></div></div></div></blockquote><div><br></div></span><div>For some extra context: we tracked down a stack overflow to the related changes to add always_inline to basic_string::__init.  Our user had some string => enum value map declared statically, like in the attached stackoverflow.cpp.  At -Os (and higher), there's no difference.  But with -O0 and -O1, they started getting a stack overflow at launch.</div></div></div></blockquote><div><br></div><div>That's not a bug but a feature ;-)</div><div>It was a good way to show the user he's not doing the right thing by using a costly initialization routine!</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div></div></div></div>