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

Sorry, my bad - there was a problem with available_externally vtables that
we were unable to generate when there was a inline virtual function.

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/20160604/141c0b63/attachment.html>