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

[Rafael Espíndola]

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