[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 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.

- David


>
> 2016-06-04 17:55 GMT+02:00 David Blaikie <dblaikie at gmail.com>:
>
>> I'm curious - how did it come up as a problem in devirtualization?
>>
>> On Sat, Jun 4, 2016 at 7:33 AM, Piotr Padlewski via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>>
>>> 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.
>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> 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/20160614/8ec55771/attachment.html>