[PATCH] D47108: [CodeGenCXX] Add -fforce-emit-vtables
John McCall via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed May 23 14:15:49 PDT 2018
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
More information about the cfe-commits
mailing list