<div dir="ltr">I wonder if the correct approach here might be to add yet another new visibility macro specifically for externally instantiated symbols<div>which are currently hidden but might want to be used with _LIBCPP_LARGE_CODEBASE.</div><div><br></div><div>1. Introduce a new visibility macro _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY (Technically this macro already exists, but I think we should repurpose it and change existing users to something else).</div><div>2. Mark the symbols in std::string which _LIBCPP_LARGE_CODEBASE doesn't want inlined using _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY.<br><div>3. When building the dylib define _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY to __attribute__((__always_inline__, visibility("default"))).</div><div><br></div><div>Then, by default _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY can be defined to _LIBCPP_INLINE_VISIBILITY, which should ensure the external definitions are not used.</div><div>If a user wants to use the external definitions and prevent inlining they could define _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY to simply "__attribute__((visibility("default")))"</div><div><br></div><div>I think this should work without doing anything too drastic.</div><div><br></div><div><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 4, 2018 at 4:56 PM, Duncan P. N. Exon Smith via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<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;line-break:after-white-space"><div><div class="h5"><br><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><br class="m_4637492116288827622Apple-interchange-newline"><div><div dir="ltr"><br><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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><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="m_4637492116288827622m_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-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"><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="m_4637492116288827622m_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="m_4637492116288827622m_8689707890761057179Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer" target="_blank">cfe-dev@lists.llvm.<wbr>org</a>></span><span class="m_4637492116288827622m_8689707890761057179Apple-converted-space"> </span>wrote:<br><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>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-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><br>The new configuration option could be called _LIBCPP_DISABLE_INLINE_<wbr>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/_<wbr>LIBCPP_HIDE_FROM_ABI to drop the "always_inline" but keep the "hidden".  Have you considered _LIBCPP_DISABLE_ALWAYS_INLINE_<wbr>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_<wbr>11char_traitsIcEENS_<wbr>9allocatorIcEEEpLEPKc' is not defined locally</div></div>
</div></blockquote></div><br></div></div><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_<wbr>inline))</div><div>- __attribute__((hidden,no_<wbr>extern_template))</div><div><br></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_<wbr>FROM_OBJECTS (to switch from always_inline (maybe, eventually, internal_linkage) to no_extern_template).</div></div><br>______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">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/<wbr>mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div></div></div>