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

[Piotr Padlewski]

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