[cfe-dev] Adding a new attribute: no_extern_template

[Louis Dionne via cfe-dev]

> On Aug 23, 2018, at 16:05, Reid Kleckner <rnk at google.com> wrote:
> 
> On Wed, Aug 22, 2018 at 3:02 PM Louis Dionne <ldionne at apple.com <mailto:ldionne at apple.com>> wrote:
> The problem here is that there's no function in the dylib that we can call that would itself have access to __vector_base_common<true>::__vector_base_common(), which has hidden visibility.
> 
> Also, even disregarding this issue, it turns out that preventing inlining of all methods that are part of the ABI is kind of a big deal -- I'm quite concerned about the performance impact this could have. I’d much rather pursue a path that does not require telling the compiler whether to inline something or not, as this is an orthogonal decision IMO. Does that make sense?
> 
> True, if the dylib does not provide the symbols that are being called directly from user code, then neither of my suggestions will help. You really do need to emit the functions with linkonce_odr linkage, because they are not actually available, and the extern template declaration is a bit of a lie.

Yes, it is indeed a lie. More specifically, the extern template declaration is a lie for a subset of the methods in the class template — some of them are actually in the dylib, but some of them are not.

> 
> At this point, you might want to consider finding a way to make libc++.dylib expose the symbols so that at some point in the future so that these functions can be emitted as avaiable_externally instead of linkonce_odr.


The problem is that we don’t want to increase the surface of the ABI if we can avoid it. The larger our ABI surface is, the harder it is to make changes because we need to maintain ABI stability.

Louis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180823/cf328925/attachment.html>