[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 16:24:55
Message-ID: 13333534.1.1437063887922.JavaMail.javamailuser () localhost
[Download RAW message or body]

----- Original Message -----
> From: "Rafael Espíndola" <rafael.espindola@gmail.com>
> 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 10:26:13 AM
> Subject: Re: [cfe-dev] C++11 and enhacned devirtualization
> 
> My preference for cases like PR16984 would be to change how clang
> finds the vtable. Instead of doing a load from this, have clang
> directly use the _ZTV variable when it is known at compile time.

Agreed.

Correction to my previous message: When I said, "PR16984 mentions..." below, I should \
have said, "PR13227 mentions...".

 -Hal

> 
> 
> On 15 July 2015 at 23:12, Hal Finkel <hfinkel@anl.gov> wrote:
> > Hi Rafael,
> > 
> > Thanks for the list of bug reports. The situations I've highlighted
> > are indeed PR16984 and PR13227. Do you have any thoughts on a
> > design to fix them? PR16984 mentions that it is likely best to put
> > the necessary information into the IR and let the optimizer take
> > care of the constant propagation to get rid of the indirect call.
> > I agree, this sounds appealing. The question then is what form
> > should that information take. I could do this with @llvm.assume,
> > but I'm somewhat afraid of littering the IR with them in response
> > to a common core language property.
> > 
> > -Hal
> > 
> > ----- Original Message -----
> > > From: "Rafael Espíndola" <rafael.espindola@gmail.com>
> > > 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 12:48:05 AM
> > > Subject: Re: [cfe-dev] C++11 and enhacned devirtualization
> > > 
> > > 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@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@cs.uiuc.edu
> > > > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> > > 
> > 
> > --
> > Hal Finkel
> > Assistant Computational Scientist
> > Leadership Computing Facility
> > Argonne National Laboratory
> 

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