<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 29, 2017, at 20:16, Eric Fiselier <<a href="mailto:eric@efcs.ca" class="">eric@efcs.ca</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Mar 29, 2017 at 9:00 PM, Duncan P. N. Exon Smith <span dir="ltr" class=""><<a href="mailto:dexonsmith@apple.com" target="_blank" class="">dexonsmith@apple.com</a>></span> wrote:<br class=""><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 class=""></blockquote><div class=""><br class=""></div><div class="">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 class="">The way it did that is by removing the __attribute__((visibility("hidden"))) part while building the dylib, because GCC was ignoring the</div><div class="">`visibility("default")` on the extern template declarations for basic string.</div><div class=""> </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 class=""></blockquote><div class=""><br class=""></div><div class="">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 class="">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 class=""></div><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><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Also I think the doc for _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY is misleading. I'll try to update it in the coming days.</div></div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="">
It has major downsides:<br class="">
- It causes inlining at -O0, which causes major regressions in debugging experiences.<br class="">
- It causes inlining at -O0, which, without other optimizations, can blow up stack size of static_initializers.<br class=""></blockquote></div></div></div></div></blockquote><div><br class=""></div><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><br class=""></div><div></div></div></body></html>