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

[Hal Finkel]

----- Original Message -----
> From: "Nico Weber" <thakis at chromium.org>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>, "Richard Smith" <richard at metafoo.co.uk>
> Sent: Thursday, July 16, 2015 2:52:46 PM
> Subject: Re: [cfe-dev] C++11 and enhacned devirtualization
> 
> 
> 
> 
> 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?
> 

Speaking only for myself, most of my users are just now beginning the transition to C++11 and beyond, and have started asking questions about how various new language features help, or not, with optimization. The answers to these questions will determine how these features will be adopted going forward. In short, I don't have a good answer to your question, but if adding 'final' will help with optimization, then going forward, I'll see a lot more of it.

 -Hal

> 
> 
> 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
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory