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

[Piotr Padlewski via cfe-dev]

2016-06-04 4:07 GMT+02:00 John McCall via cfe-dev <cfe-dev at lists.llvm.org>:

> > 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.
>
> John.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

This problem was pretty annoying when I was working on devirtualization. It
would be cool to fix ABI to support that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160604/40eb3408/attachment.html>