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

[Eric Fiselier via cfe-dev]

I wonder if the correct approach here might be to add yet another new
visibility macro specifically for externally instantiated symbols
which are currently hidden but might want to be used with
_LIBCPP_LARGE_CODEBASE.

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).
2. Mark the symbols in std::string which _LIBCPP_LARGE_CODEBASE doesn't
want inlined using _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY.
3. When building the dylib define _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY
to __attribute__((__always_inline__, visibility("default"))).

Then, by default _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY can be defined
to _LIBCPP_INLINE_VISIBILITY, which should ensure the external definitions
are not used.
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")))"

I think this should work without doing anything too drastic.

On Mon, Jun 4, 2018 at 4:56 PM, Duncan P. N. Exon Smith via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

>
>
> On Jun 4, 2018, at 14:57, Erik van der Poel <erikv at google.com> wrote:
>
>
>
> On Mon, Jun 4, 2018 at 2:11 PM Duncan P. N. Exon Smith <
> dexonsmith at apple.com> wrote:
>
>>
>>
>> On Jun 4, 2018, at 13:52, Richard Smith <richard at metafoo.co.uk> wrote:
>>
>> On Mon, 4 Jun 2018, 21:43 Duncan P. N. Exon Smith via cfe-dev, <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>>
>>>
>>> On May 31, 2018, at 15:35, Richard Smith via cfe-dev <
>>> cfe-dev at lists.llvm.org> wrote:
>>>
>>> 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.
>>>>>
>>>>
>>> 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.
>>>
>>> Renaming _LIBCPP_INLINE_VISIBILITY to _LIBCPP_HIDE_FROM_ABI makes sense
>>> to me though.
>>>
>>> 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?
>>>
>>
>> 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.
>>
>>
>> It seems wrong to have any explicitly instantiated template members with
>> _LIBCPP_INLINE_VISIBILITY.  Do we really do that?
>>
>
> Removing always_inline from _LIBCPP_INLINE_VISIBILITY was actually the
> first thing I tried. I got errors like these (from ld):
>
> hidden symbol '_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEpLEPKc'
> is not defined locally
>
>
> 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...
>
> 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.
>
> Then, depending on a macro setting, we pick between:
> - __attribute__((hidden,always_inline))
> - __attribute__((hidden,no_extern_template))
>
> Also, I think we can use semantic names for the macros.
> - _LIBCPP_HIDE_FROM_ABI to apply the attributes (replacing
> _LIBCPP_INLINE_VISIBILITY, as you suggested).
> - _LIBCPP_DISABLE_HIDE_FROM_ABI_FROM_OBJECTS (to switch from
> always_inline (maybe, eventually, internal_linkage) to no_extern_template).
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180604/b6e7fee0/attachment.html>