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

[Hal Finkel]

----- Original Message -----
> From: "Rafael Espíndola" <rafael.espindola at gmail.com>
> 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 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 at 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 at gmail.com>
> >> 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 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 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
> >>
> >
> > --
> > Hal Finkel
> > Assistant Computational Scientist
> > Leadership Computing Facility
> > Argonne National Laboratory
> 

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