<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">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 class="">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_VISIBIL<wbr>ITY.<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>
<br>
Alternatives considered and rejected:<br>
<br>
1. Remove __attribute__((__always_inline<wbr>__)) 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_ANN<wbr>OTATIONS 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_linkag<wbr>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">http://lists.llvm.org/pipermai<wbr>l/cfe-dev/2016-October/051151.<wbr>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>