[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfe-dev
Subject:    Re: [cfe-dev] C++11 and enhacned devirtualization
From:       Hal Finkel <hfinkel () anl ! gov>
Date:       2015-07-16 23:36:44
Message-ID: 22541577.601.1437089802563.JavaMail.javamailuser () localhost
[Download RAW message or body]

----- Original Message -----
> From: "Nico Weber" <thakis@chromium.org>
> To: "Hal Finkel" <hfinkel@anl.gov>
> Cc: "cfe-dev@cs.uiuc.edu Developers" <cfe-dev@cs.uiuc.edu>, "Richard Smith" \
>                 <richard@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@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@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


[prev in list] [next in list] [prev in thread] [next in thread]