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

Nico Weber thakis at chromium.org
Thu Jul 16 12:52:46 PDT 2015


On Wed, Jul 15, 2015 at 10:11 PM, 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).
>

Out of interest, is there data to suggest that this type of optimization
will happen often in practice?


>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150716/6ba7c86b/attachment.html>


More information about the cfe-dev mailing list