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

[Hal Finkel]

----- Original Message -----
> From: "Piotr Padlewski" <prazek at google.com>
> To: "David Blaikie" <dblaikie at gmail.com>
> Cc: "Rafael Espíndola" <rafael.espindola at gmail.com>, "Hal Finkel" <hfinkel at anl.gov>, "Richard Smith"
> <richard at metafoo.co.uk>, "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>
> Sent: Thursday, July 16, 2015 12:02:47 PM
> Subject: Re: [cfe-dev] C++11 and enhacned devirtualization
> 
> The proposal of our solution will be published next week. Brief
> introduction:
> 
> "Basic idea is to mark vtable loads with !invariant , and also put
> assume() after calling constructor to show how vtable will look
> like.

Interesting, thanks. Just putting these after the constructor call would not, however, handle the case I outlined in my original e-mail.

> Function @llvm.invariant.barrier that breaks the invariant
> will be needed to cope with placement new and other cases where the
> vptr is legitimately permitted to change."

We already have @llvm.invariant.start/@llvm.invariant.end, could those be used instead? (No need to address this now -- just address this in the proposal when you make it.)

Thanks,
Hal

> 
> We also want to make some improvements on generating vtables as
> avaliable_externally - for example when there are no virtual inline
> functions
> 
> 
> Piotr
> 
> 
> On Thu, Jul 16, 2015 at 9:11 AM, David Blaikie < dblaikie at gmail.com >
> wrote:
> 
> 
> 
> I believe Piotr Prazek (cc'd) is working with Richard Smith on a
> proposal/plan for a general device for devirtualization (something
> like a restricted assume for pointer loads, if I understand it
> correctly - as we have nonnull and other attributes for other
> special cases of assume)
> 
> 
> 
> On Thu, Jul 16, 2015 at 8:26 AM, Rafael Espíndola <
> rafael.espindola at gmail.com > wrote:
> 
> 
> 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.
> 
> 
> 
> 
> 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
> 
> _______________________________________________
> 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