[prev in list] [next in list] [prev in thread] [next in thread]
List: cfe-dev
Subject: Re: [cfe-dev] C++11 and enhacned devirtualization
From: David Blaikie <dblaikie () gmail ! com>
Date: 2015-07-16 16:11:33
Message-ID: CAENS6EtqQASWrx60c1N+1Hr-7zGA-fSfKsiKH-wynpC_OtT8DQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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@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@gmail.com>
> >> To: "Hal Finkel" <hfinkel@anl.gov>
> >> Cc: "cfe-dev@cs.uiuc.edu Developers" <cfe-dev@cs.uiuc.edu>, "Richard
> Smith" <richard@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@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@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@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
[Attachment #5 (text/html)]
<div dir="ltr">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)<br></div><div \
class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 16, 2015 at 8:26 AM, \
Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" \
target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">My preference for cases like PR16984 would be to change how \
clang<br> finds the vtable. Instead of doing a load from this, have clang<br>
directly use the _ZTV variable when it is known at compile time.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 15 July 2015 at 23:12, Hal Finkel <<a \
href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br> > Hi Rafael,<br>
><br>
> 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.<br> \
><br> > -Hal<br>
><br>
> ----- Original Message -----<br>
>> From: "Rafael Espíndola" <<a \
href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>><br> \
>> To: "Hal Finkel" <<a \
href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br> >> Cc: "<a \
href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a> Developers" <<a \
href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>>, "Richard \
Smith" <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>><br>
>> Sent: Thursday, July 16, 2015 12:48:05 AM<br>
>> Subject: Re: [cfe-dev] C++11 and enhacned devirtualization<br>
>><br>
>> There a quite a few open bugs about devirtualization. A quick search<br>
>> finds<br>
>><br>
>> pr18972, pr3100, pr13227, pr15961, pr15963, pr16984, pr17863,<br>
>> pr19545, pr6747.<br>
>><br>
>> A fairly important restriction to keep in mind is that the itanium<br>
>> abi<br>
>> requires some vtables to be exported from a given file (the one with<br>
>> the key function), but the functions in those vtables don't have to<br>
>> be<br>
>> exported.<br>
>><br>
>> That means that to devirtualize we have to produce a copy, which hits<br>
>> issues with code that wants avoid #including definitions.<br>
>><br>
>> See the commit message of r189852 for more details.<br>
>><br>
>> Cheers,<br>
>> Rafael<br>
>><br>
>><br>
>> On 15 July 2015 at 22:11, Hal Finkel <<a \
href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br> >> > Hi \
everyone,<br> >> ><br>
>> > C++11 added features that allow for certain parts of the class<br>
>> > hierarchy to be closed, specifically the 'final' keyword and \
the<br> >> > semantics of anonymous namespaces, and I think we take \
advantage<br> >> > of these to enhance our ability to perform \
devirtualization. For<br> >> > example, given this situation:<br>
>> ><br>
>> > struct Base {<br>
>> > virtual void foo() = 0;<br>
>> > };<br>
>> ><br>
>> > void external();<br>
>> > struct Final final : Base {<br>
>> > void foo() {<br>
>> > external();<br>
>> > }<br>
>> > };<br>
>> ><br>
>> > void dispatch(Base *B) {<br>
>> > B->foo();<br>
>> > }<br>
>> ><br>
>> > void opportunity(Final *F) {<br>
>> > dispatch(F);<br>
>> > }<br>
>> ><br>
>> > When we optimize this code, we do the expected thing and inline<br>
>> > 'dispatch' into 'opportunity' but we don't \
devirtualize the call<br> >> > to foo(). The fact that we know what the \
vtable of F is at that<br> >> > callsite is not exploited. To a lesser \
extent, we can do similar<br> >> > things for final virtual methods, and \
derived classes in anonymous<br> >> > namespaces (because Clang could \
determine whether or not a class<br> >> > (or method) there is effectively \
final).<br> >> ><br>
>> > One possibility might be to @llvm.assume to say something about<br>
>> > what the vtable ptr of F might be/contain should it be needed<br>
>> > later when we emit the initial IR for 'opportunity' (and \
then<br> >> > teach the optimizer to use that information), but I'm not \
at all<br> >> > sure that's the best solution. Thoughts?<br>
>> ><br>
>> > Thanks again,<br>
>> > Hal<br>
>> ><br>
>> > --<br>
>> > Hal Finkel<br>
>> > Assistant Computational Scientist<br>
>> > Leadership Computing Facility<br>
>> > Argonne National Laboratory<br>
>> > _______________________________________________<br>
>> > cfe-dev mailing list<br>
>> > <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
>> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" \
rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>><br>
><br>
> --<br>
> Hal Finkel<br>
> Assistant Computational Scientist<br>
> Leadership Computing Facility<br>
> Argonne National Laboratory<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" rel="noreferrer" \
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br> \
</div></div></blockquote></div><br></div>
_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic