<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 4, 2016 at 9:36 AM, Piotr Padlewski <span dir="ltr"><<a href="mailto:piotr.padlewski@gmail.com" target="_blank">piotr.padlewski@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Sorry, my bad - there was a problem with available_externally vtables that we were unable to generate when there was a inline virtual function. </div></blockquote><div><br></div><div>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?<br><br>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.<br><br>It'd bloat object files a bit, but only in the cases where there's an optimization win - right?<br><br>But I guess there's a reason that doesn't work/wasn't implemented.<br><br>- David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2016-06-04 17:55 GMT+02:00 David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm curious - how did it come up as a problem in devirtualization?</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 4, 2016 at 7:33 AM, Piotr Padlewski via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div><div>2016-06-04 4:07 GMT+02:00 John McCall via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span>:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><span>> On Jun 3, 2016, at 7:05 PM, John McCall via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>> On Jun 3, 2016, at 8:43 AM, David Blaikie via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>> 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.<br>
>><br>
>> Any thoughts?<br>
><br>
> 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.<br>
<br>
</span>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.<br>
</div></div><div><div><br>
John.<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra">This problem was pretty annoying when I was working on devirtualization. It would be cool to fix ABI to support that. </div><div class="gmail_extra"><br></div></div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>