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

[David Blaikie]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150716/046c4cc4/attachment.html>