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

Tue Oct 30 15:56:47 PDT 2018

> 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 <mailto: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 <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 <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <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/51470bf9/attachment.html>