[cfe-dev] libc++ and large stack frames

Richard Smith via cfe-dev cfe-dev at lists.llvm.org
Thu May 31 15:35:50 PDT 2018


On 31 May 2018 at 14:38, Friedman, Eli via cfe-dev <cfe-dev at lists.llvm.org>
wrote:

> On 5/31/2018 1:07 PM, Erik van der Poel via cfe-dev wrote:
>
>> 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.
>>
>> The new configuration option could be called
>> _LIBCPP_DISABLE_INLINE_VISIBILITY.
>>
>> 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.
>>
>> Alternatives considered and rejected:
>>
>> 1. Remove __attribute__((__always_inline__)) from all include/__config
>> macros.
>> 2. Add _LIBCPP_DISABLE_ALWAYS_INLINE to control whether or not
>> __always_inline__ is included in any __config macro.
>> 3. Use the existing _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS to control
>> both __visibility__ and __always_inline__.
>> 4. Use the existing _LIBCPP_ABI_UNSTABLE to control
>> _LIBCPP_INLINE_VISIBILITY.
>>
>
> 5. Start using __attribute__((internal_linkage)) instead, so a
> configuration option isn't necessary.  See http://lists.llvm.org/pipermai
> l/cfe-dev/2016-October/051151.html .


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180531/8045a936/attachment.html>


More information about the cfe-dev mailing list