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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
