[cfe-dev] libc++ is not using always_inline anymore!

[David Blaikie via cfe-dev]

Yeah, that helps - answers some questions I didn't know I had either! :)

On Tue, Oct 30, 2018 at 3:56 PM Louis Dionne <ldionne at apple.com> wrote:

> On Oct 30, 2018, at 18:00, David Blaikie <dblaikie at gmail.com> wrote:
>
> Awesome!
>
> What are the new semantics? That this ABI stability guarantee is provided
> by hiding the functions in each user so they can't be deduplicated with
> anotehr user's copy? (what about other copies that are from the same build?
> I guess even those won't get coalesced/collapsed together? Would that be
> useful to support?)
>
>
> There are currently two modes (in LLVM trunk, and that is the plan for
> LLVM 8 too):
>
> 1. (the default) All TUs linked together inside the same final linked
> image need to have use the same libc++ version. Inline functions are
> ODR-merged across TUs like they normally are. In this mode, we don't use
> any funny attribute to control linkage (neither always_inline nor
> internal_linkage).
>
> 2. (can be opted-in) TUs can be linked together even if they use different
> headers of libc++. This is achieved by using internal_linkage on
> implementation detail functions of libc++. Those functions are local to a
> TU and they are NOT ODR-merge across TUs. This results in more code
> duplication than option (1).
>
>
> I assume this doesn't change the defaults, but does it make it any easier
> for users who don't need the ABI stability guarantee? (or was it already
> easy/no change here?)
>
>
> It actually does change the default. However, it depends of what ABI
> guarantee you're talking about.
>
> 1. The ABI stability of the shared objects is always (and has always been,
> and will most likely always) be guaranteed. The only way to change that is
> to explicitly use the _LIBCPP_ABI_UNSTABLE macro, which says "use all the
> ABI breaking features". This obviously only works if you're also linking
> against a library that was built to provide that ABI. This ability to use
> the unstable ABI has been provided for a long time, it wasn't the default,
> and it still isn't the default -- my change is completely orthogonal to
> that.
>
> 2. The "ABI stability" of static archives is a different matter. The
> question here is whether you can link programs against static archives
> built with different versions of libc++. The answer used to be YES by
> default, not it is NO by default. If you want to retain that ability, you
> need to use the `_LIBCPP_HIDE_FROM_ABI_PER_TU` macro. And also please give
> us a heads up so we know someone is using it.
>
> Does that answer your questions?
>
> Louis
>
>
> On Mon, Oct 29, 2018 at 2:41 PM Louis Dionne via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> Folks,
>>
>> Today, I pushed a change that disables the use of always_inline for
>> visibility purposes in libc++. The change was reviewed as
>> https://reviews.llvm.org/D52405. This patch is the culminating point of
>> several discussions about libc++'s visibility annotations.
>>
>> This change should have a positive impact on code size for almost any
>> application using the libc++ headers. For example, Eric Fiselier reported a
>> 7% improvement in size for the Chrome binary after applying this patch. We
>> are still in the process of gathering more data like this, but we expect
>> similar gains to be possible in other applications. The debugging
>> experience should also be much improved as we don't inline every function
>> into its caller.
>>
>> However, one word of caution: even though we were very careful not to
>> break the ABI or any of libc++'s users ABI, this patch changes things that
>> have been in place in libc++ for a long time. It is possible that we
>> uncover problems with it, although we hope that won't be the case. If you
>> start seeing problems you think are caused by this change, please notify me
>> right away so we can take a look.
>>
>> I'll post updates here as we're able to publish more data and
>> observations about the results of this patch.
>>
>> Thanks,
>> Louis
>>
>> _______________________________________________
>> 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/20181030/212b50e3/attachment.html>