[PATCH] D47108: [CodeGenCXX] Add -fforce-emit-vtables

[John McCall via Phabricator via llvm-commits]

rjmccall added a comment.

In https://reviews.llvm.org/D47108#1109145, @Prazek wrote:

> In https://reviews.llvm.org/D47108#1109014, @rjmccall wrote:
>
> > I thought we already had places in Sema that marked inline virtual methods as used, instantiated templates, etc. for devirtualization purposes when optimization was enabled.  Did we rip that out?
>
>
> I only recall the emitting available_externally vtables opportunistically, that is emitting it only if all the inline virtual functions are present (and they are not hidden).
>  (https://reviews.llvm.org/D33437)
>
> > The problem we've had over and over with devirtualization is that we have to emit a perfect v-table because LLVM lacks a lot of the key vocabulary for talking about incomplete information.  For example, if something weird happens and we don't have a definition for an inline virtual method, ideally we'd just say "well, you can't devirtualize this slot", then try to fix that as incremental progress; but instead we have to get everything just right or else disable the whole optimization.  Note that vague-linkage v-tables mean that we'd also need to be able to say things like "there is an object with a definition that looks like this, but its symbol is not available and you can't emit it yourself".
>
> That is correcty, my intention was that this flag would cause all inline virtual functions to be emitted. Can you give a hint how to achieve this in the sane way?


Well, this paragraph was really a call for extending LLVM IR, which might be outside a reasonable scope for your summer project.

Building a v-table should itself cause inline functions to be emitted in IRGen as long as they've been properly marked for instantiation and use by Sema.  I don't know the right place to ensure that that happens.


Repository:
  rL LLVM

https://reviews.llvm.org/D47108