<div dir="auto"><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">cfe-dev@lists.llvm.org</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 May 31, 2018, at 15:35, Richard Smith via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="m_-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 dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer">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"><span>On 5/31/2018 1:07 PM, Erik van der Poel via cfe-dev wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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 dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><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><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Alternatives considered and rejected:<br>
<br>
1. Remove __attribute__((__always_inline__)) from all include/__config macros.<br>
2. Add _LIBCPP_DISABLE_ALWAYS_INLINE to control whether or not __always_inline__ is included in any __config macro.<br>
3. Use the existing _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS to control both __visibility__ and __always_inline__.<br>
4. Use the existing _LIBCPP_ABI_UNSTABLE to control _LIBCPP_INLINE_VISIBILITY.<br>
</blockquote>
<br></span>
5. Start using __attribute__((internal_linkage)) instead, so a configuration option isn't necessary. See <a href="http://lists.llvm.org/pipermail/cfe-dev/2016-October/051151.html" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/pipermail/cfe-dev/2016-October/051151.html</a> .</blockquote><div><br></div><div>Yes, that'd solve the problem, but it would also result in duplicate definitions for all the INLINE_VISIBILITY member functions that don't get inlined. As a consequence, __attribute__((internal_linkage)) would be a worse solution than the one being proposed here for those who don't care about the ABI stability guarantees that libc++ is trying to provide. Replacing the current use of __always_inline__ with __internal_linkage__ seems like it would probably be an improvement to me (conditional on whether the effects on code size are acceptable), but I think the change Erik is proposing and that one are largely orthogonal.</div></div></div></div></div></blockquote></div><br><div>I agree.</div></div>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div></div>