<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 May 31, 2018, at 15:35, Richard Smith via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-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 dir="ltr" class=""><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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: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 class="">
<br class="">
The new configuration option could be called _LIBCPP_DISABLE_INLINE_VISIBIL<wbr class="">ITY.<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><br class=""></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 class=""></div><div>Renaming _LIBCPP_INLINE_VISIBILITY to _LIBCPP_HIDE_FROM_ABI makes sense to me though.</div><div><br class=""></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><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><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 class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Alternatives considered and rejected:<br class="">
<br class="">
1. Remove __attribute__((__always_inline<wbr class="">__)) from all include/__config macros.<br class="">
2. Add _LIBCPP_DISABLE_ALWAYS_INLINE to control whether or not __always_inline__ is included in any __config macro.<br class="">
3. Use the existing _LIBCPP_DISABLE_VISIBILITY_ANN<wbr class="">OTATIONS to control both __visibility__ and __always_inline__.<br class="">
4. Use the existing _LIBCPP_ABI_UNSTABLE to control _LIBCPP_INLINE_VISIBILITY.<br class="">
</blockquote>
<br class=""></span>
5. Start using __attribute__((internal_linkag<wbr class="">e)) instead, so a configuration option isn't necessary. See <a href="http://lists.llvm.org/pipermail/cfe-dev/2016-October/051151.html" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/pipermai<wbr class="">l/cfe-dev/2016-October/051151.<wbr class="">html</a> .</blockquote><div class=""><br class=""></div><div class="">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 class=""><div class="">I agree.</div></body></html>