[cfe-dev] C++11 and enhacned devirtualization

[Rafael Espíndola]

There a quite a few open bugs about devirtualization. A quick search finds

pr18972, pr3100, pr13227, pr15961, pr15963, pr16984, pr17863, pr19545, pr6747.

A fairly important restriction to keep in mind is that the itanium abi
requires some vtables to be exported from a given file (the one with
the key function), but the functions in those vtables don't have to be
exported.

That means that to devirtualize we have to produce a copy, which hits
issues with code that wants avoid #including definitions.

See the commit message of r189852 for more details.

Cheers,
Rafael


On 15 July 2015 at 22:11, Hal Finkel <hfinkel at anl.gov> wrote:
> Hi everyone,
>
> C++11 added features that allow for certain parts of the class hierarchy to be closed, specifically the 'final' keyword and the semantics of anonymous namespaces, and I think we take advantage of these to enhance our ability to perform devirtualization. For example, given this situation:
>
> struct Base {
>   virtual void foo() = 0;
> };
>
> void external();
> struct Final final : Base {
>   void foo() {
>     external();
>   }
> };
>
> void dispatch(Base *B) {
>   B->foo();
> }
>
> void opportunity(Final *F) {
>   dispatch(F);
> }
>
> When we optimize this code, we do the expected thing and inline 'dispatch' into 'opportunity' but we don't devirtualize the call to foo(). The fact that we know what the vtable of F is at that callsite is not exploited. To a lesser extent, we can do similar things for final virtual methods, and derived classes in anonymous namespaces (because Clang could determine whether or not a class (or method) there is effectively final).
>
> One possibility might be to @llvm.assume to say something about what the vtable ptr of F might be/contain should it be needed later when we emit the initial IR for 'opportunity' (and then teach the optimizer to use that information), but I'm not at all sure that's the best solution. Thoughts?
>
> Thanks again,
> Hal
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev