[cfe-dev] Could we emit inline virtual member functions as available_externally when there's a key function (same as vtable and debug info)?

[David Blaikie via cfe-dev]

On Fri, Jun 3, 2016 at 7:07 PM, John McCall <rjmccall at apple.com> wrote:

> > On Jun 3, 2016, at 7:05 PM, John McCall via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
> >> On Jun 3, 2016, at 8:43 AM, David Blaikie via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
> >> I assume there's a good reason we don't do this - but I can't quite
> figure it out off the top of my head.
> >>
> >> Any thoughts?
> >
> > The translation unit that emits the key function is required to emit the
> v-table symbol with as a strong definition with the type's visibility.  It
> is not required to emit visible symbols for any of the inline virtual
> functions.  It is, of course, required to emit those functions as part of
> emitting the v-table; but it doesn't have to provide symbols for them at
> all, because even if it were possible to take the address of a virtual
> member function in a comparable way, there is no way to take that address
> *via the v-table* and so the v-table's reference may be to its own
> implementation.  This is good because it allows virtual methods to be given
> hidden visibility by default; it also permits v-tables to contain
> specialized method implementations, e.g. methods that use a known
> most-derived class.
>
> To be clear, your idea would be a reasonable guarantee to make in a
> revised C++ ABI; it's just that it's not guaranteed to work under the
> current one.
>

Ah, right. Thanks for the context, John!

(in throwing this around with Chandler & Richard, we're also considering
about an even bigger (& user facing, not just ABI breaking) possibility:
(we discussed a few variants, but this was one of them) require that all
inline member functions originally declared inline be defined in any
translation unit that defines a non-inline member function (or perhaps just
virtual ones?) - and use that to emit weak_odr+available_externally
definitions of those inline functions (mostly because we have protobufs
with lots and lots of inline functions). I may try prototyping this to see
how valuable it is to us, then figure out the finer points if it is worth
pursuing.

This starts to look a lot like modules codegen would look like (where we
would build an object file from a module definition with weak_odr
definitions of any inline functions, with debug info as well as debug info
for any types defined there (like the current modules debug info), etc))
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160604/74250aef/attachment.html>