<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Jun 4, 2018 at 6:56 PM Duncan P. N. Exon Smith via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</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"><div><br><blockquote type="cite"><div>On Jun 4, 2018, at 14:57, Erik van der Poel <<a href="mailto:erikv@google.com" target="_blank">erikv@google.com</a>> wrote:</div><div><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 4, 2018 at 2:11 PM Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@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 Jun 4, 2018, at 13:52, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:</div><br class="gmail-m_4171207777786915470m_137717655346250412m_8689707890761057179Apple-interchange-newline"><div><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"><div><div class="gmail_quote"><div dir="ltr">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">cfe-dev@lists.llvm.org</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 31, 2018, at 15:35, Richard Smith via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="gmail-m_4171207777786915470m_137717655346250412m_8689707890761057179m_-6882760512182839703Apple-interchange-newline"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 31 May 2018 at 14:38, Friedman, Eli via cfe-dev<span class="gmail-m_4171207777786915470m_137717655346250412m_8689707890761057179Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer" target="_blank">cfe-dev@lists.llvm.org</a>></span><span class="gmail-m_4171207777786915470m_137717655346250412m_8689707890761057179Apple-converted-space"> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On 5/31/2018 1:07 PM, Erik van der Poel via cfe-dev wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid 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><br>The new configuration option could be called _LIBCPP_DISABLE_INLINE_VISIBILITY.<br><br>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></blockquote></span></blockquote></div></div></div></div></blockquote><div><br></div><div>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><br></div><div>Renaming _LIBCPP_INLINE_VISIBILITY to _LIBCPP_HIDE_FROM_ABI makes sense to me though.</div><div><br></div><div>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"><br></div><div dir="auto">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><br></div><div>It seems wrong to have any explicitly instantiated template members with _LIBCPP_INLINE_VISIBILITY.  Do we really do that?</div></div></div></blockquote><div> </div>Removing always_inline from _LIBCPP_INLINE_VISIBILITY was actually the first thing I tried. I got errors like these (from ld):<br><br>hidden symbol '_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEpLEPKc' is not defined locally</div></div>
</div></blockquote></div><br><div>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><br></div><div>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><br></div><div>Then, depending on a macro setting, we pick between:</div><div>- __attribute__((hidden,always_inline))</div><div>- __attribute__((hidden,no_extern_template))</div></div></blockquote><div><br></div><div>This surely affects only a tiny minority of the symbols currently marked always_inline, right? Could we start by removing it from all the functions which aren't affected by the _LIBCPP_EXTERN_TEMPLATE or _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS, first, to get the largest volume of stuff fixed, before trying to deal with these problematic edge cases?</div><div><br></div><div>Also -- is there really an actual benefit of hiding these symbols from the export list? Once you're exporting any significant functions from a nontrivial class like basic_string<char>, I'm not clear as to how it's of real benefit to hide other functions like operator+=. I'd think that typically everything generated by the explicit template instantiation should just be exported in future versions.</div><div><br></div><div>Of course there is the Apple-platform issue of requiring compatibility of apps compiled with new libc++ headers to be able to run against an old libc++ shared library. When adding new functions to an existing template class, those functions won't be present in the older shared lib version. ISTM that for that case, it'd be entirely reasonable to mark them internal_linkage (or whatever) only when targeting old platforms.</div><div><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"><div> </div></div></blockquote><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"><div></div><div>Also, I think we can use semantic names for the macros.</div><div>- _LIBCPP_HIDE_FROM_ABI to apply the attributes (replacing _LIBCPP_INLINE_VISIBILITY, as you suggested).</div><div>- _LIBCPP_DISABLE_HIDE_FROM_ABI_FROM_OBJECTS (to switch from always_inline (maybe, eventually, internal_linkage) to no_extern_template).</div></div>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>