<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 4, 2018, at 14:57, Erik van der Poel <<a href="mailto:erikv@google.com" class="">erikv@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Jun 4, 2018 at 2:11 PM Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com" class="">dexonsmith@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jun 4, 2018, at 13:52, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank" class="">richard@metafoo.co.uk</a>> wrote:</div><br class="m_8689707890761057179Apple-interchange-newline"><div class=""><div dir="auto" style="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;text-decoration:none" class=""><div class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, 4 Jun 2018, 21:43 Duncan P. N. Exon Smith via cfe-dev, <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</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;line-break:after-white-space" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On May 31, 2018, at 15:35, Richard Smith via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="m_8689707890761057179m_-6882760512182839703Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On 31 May 2018 at 14:38, Friedman, Eli via cfe-dev<span class="m_8689707890761057179Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer" target="_blank" class="">cfe-dev@lists.llvm.org</a>></span><span class="m_8689707890761057179Apple-converted-space"> </span>wrote:<br class=""><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"><span class="">On 5/31/2018 1:07 PM, Erik van der Poel via cfe-dev wrote:<br class=""><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">This is a proposal to add a configuration option to disable _LIBCPP_INLINE_VISIBILITY, which causes large stack frames in non-optimized builds because it uses the always_inline attribute to force significant amounts of inlining of libc++ code.<br class=""><br class="">The new configuration option could be called _LIBCPP_DISABLE_INLINE_VISIBILITY.<br class=""><br class="">Note that _LIBCPP_INLINE_VISIBILITY and _LIBCPP_ALWAYS_INLINE have identical definitions. One could be renamed to the other or both could be renamed to _LIBCPP_HIDE_FROM_ABI as part of this work.<br class=""></blockquote></span></blockquote></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I think it's useful to have different names for these, since they have different intent. It would be reasonable to change the definition of one without changing the other.</div><div class=""><br class=""></div><div class="">Renaming _LIBCPP_INLINE_VISIBILITY to _LIBCPP_HIDE_FROM_ABI makes sense to me though.</div><div class=""><br class=""></div><div class="">One option we'd like to investigate (but haven't yet) is changing _LIBCPP_INLINE_VISIBILITY/_LIBCPP_HIDE_FROM_ABI to drop the "always_inline" but keep the "hidden". Have you considered _LIBCPP_DISABLE_ALWAYS_INLINE_IN_INLINE_VISIBILITY (or equivalent)? If not, why not?</div></div></div></blockquote></div></div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">IIRC that results in missing definitions for all of the explicitly instantiated template members, because the versions in the DSO are not visible to their consumers.</div></div></div></blockquote><div class=""><br class=""></div><div class="">It seems wrong to have any explicitly instantiated template members with _LIBCPP_INLINE_VISIBILITY. Do we really do that?</div></div></div></blockquote><div class=""> </div>Removing always_inline from _LIBCPP_INLINE_VISIBILITY was actually the first thing I tried. I got errors like these (from ld):<br class=""><br class="">hidden symbol '_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEpLEPKc' is not defined locally</div></div>
</div></blockquote></div><br class=""><div class="">Okay, I see; we're opting specific symbols out of living in the dylib. Once you remove the always_inline, the `extern template` promises that these symbols will be in the libc++.dylib, but they're not actually available there...</div><div class=""><br class=""></div><div class="">I don't think we should give up on hiding these symbols from the ABI though, and adding weak external symbols is not a great outcome. I'd rather we add an attribute (straw man: "no_extern_template") that opts these symbols out of any `extern template` declaration.</div><div class=""><br class=""></div><div class="">Then, depending on a macro setting, we pick between:</div><div class="">- __attribute__((hidden,always_inline))</div><div class="">- __attribute__((hidden,no_extern_template))</div><div class=""><br class=""></div><div class="">Also, I think we can use semantic names for the macros.</div><div class="">- _LIBCPP_HIDE_FROM_ABI to apply the attributes (replacing _LIBCPP_INLINE_VISIBILITY, as you suggested).</div><div class="">- _LIBCPP_DISABLE_HIDE_FROM_ABI_FROM_OBJECTS (to switch from always_inline (maybe, eventually, internal_linkage) to no_extern_template).</div></body></html>