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

[Reid Kleckner via cfe-dev]

On Tue, Jun 14, 2016 at 12:51 PM, David Blaikie via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Sat, Jun 4, 2016 at 9:36 AM, Piotr Padlewski <piotr.padlewski at gmail.com
> > wrote:
>
>> Sorry, my bad - there was a problem with available_externally vtables
>> that we were unable to generate when there was a inline virtual function.
>>
>
> Ah, I've found the code and some of the comments for that - do you
> remember the details or have pointers to the related threads/reviews/etc
> that came to that conclusion?
>
> Could we not emit the inline functions as linkonce_odr as usual and then
> emit the available_externally vtable on top of that. Presumably once we do
> all the optimization and drop the vtable, any of these inline virtual
> functions that haven't got any devirtualized calls to them will disappear
> due to lacking any reference holding them alive.
>
> It'd bloat object files a bit, but only in the cases where there's an
> optimization win - right?
>
> But I guess there's a reason that doesn't work/wasn't implemented.
>

It's complicated. Here's an interesting test case where it is hard to
generate an available_externally vtable for C:

#include <memory>
struct A;
struct B {
  virtual void ~B();
};
struct C : B {
  C();
  virtual void f();
  std::unique_ptr<A> a;
};
C *getit() {
  C *p = new C;
  p->f();
  return p;
}

In order to emit an externally_available vtable, we need to emit all the
inline virtual functions as linkonce_odr, which requires semantically
checking them up front, which would implicitly define ~C, which would
instantiate ~unique_ptr<A>, which requires A to be complete.

The question is, are we allowed to require 'A' to be a complete type so
that we can emit the implicit definition of C::~C?

Blink/WebKit/Nico want the answer to be "no", and most compilers give that
answer, because there is no vtable reference required here to generate
code. Richard's interpretation of the standard says that the call to the
virtual function 'f' allows us to do the semantic checking, so we could
change our minds if we think it's worth the hassle of compatibility issues
and user confusion.

I think it will be very hard to explain to users why 'A' needs to be
complete, since there's no clear vtable reference. We would need a
diagnostic note saying that the vtable was required to be complete at this
virtual call to support devirtualization.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160615/940e9a52/attachment.html>