[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: Piotr Padlewski <prazek () google ! com>
Date: 2015-07-16 17:02:47
Message-ID: CABUQfFq1UDRfjM7kB7xTix9fTpXOrEAUv_pZLoErYPWSaMX52g () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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@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">The proposal of our solution will be published next week. Brief \
introduction:<div><br></div><div><span><span \
style="font-size:14.6666666666667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">"Basic \
idea is to mark vtable loads with </span><span \
style="font-size:14.6666666666667px;font-family:Arial;color:rgb(0,0,0);font-weight:bol \
d;vertical-align:baseline;white-space:pre-wrap;background-color:transparent">!invariant</span><span \
style="font-size:14.6666666666667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent"> \
, and also put </span><span \
style="font-size:14.6666666666667px;font-family:Arial;color:rgb(0,0,0);font-weight:bol \
d;vertical-align:baseline;white-space:pre-wrap;background-color:transparent">assume()</span><span \
style="font-size:14.6666666666667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent"> \
after calling constructor to show how vtable will look like. Function </span><span \
style="font-size:14.6666666666667px;font-family:Arial;color:rgb(0,0,0);font-weight:bol \
d;vertical-align:baseline;white-space:pre-wrap;background-color:transparent">@llvm.invariant.barrier</span><span \
style="font-size:14.6666666666667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent"> \
that breaks the invariant will be needed to cope with placement new and other cases \
where the vptr is legitimately permitted to \
change."</span></span><br></div><div><span><span \
style="font-size:14.6666666666667px;font-family:Arial;color:rgb(0,0,0);vertical-align: \
baseline;white-space:pre-wrap;background-color:transparent"><br></span></span></div><div><span><span \
style="font-size:14.6666666666667px;font-family:Arial;color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">We \
also want to make some improvements on generating vtables as avaliable_externally - \
for example when there are no virtual inline \
functions</span></span></div><div><span><span \
style="font-size:14.6666666666667px;font-family:Arial;color:rgb(0,0,0);vertical-align: \
baseline;white-space:pre-wrap;background-color:transparent"><br></span></span></div><div><span><span \
style="font-size:14.6666666666667px;font-family:Arial;color:rgb(0,0,0);vertical-align: \
baseline;white-space:pre-wrap;background-color:transparent">Piotr</span></span></div></div><div \
class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 16, 2015 at 9:11 AM, \
David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" \
target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><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><div><br>
<br>
On 15 July 2015 at 23:12, Hal Finkel <<a href="mailto:hfinkel@anl.gov" \
target="_blank">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" \
target="_blank">rafael.espindola@gmail.com</a>><br> >> To: "Hal \
Finkel" <<a href="mailto:hfinkel@anl.gov" \
target="_blank">hfinkel@anl.gov</a>><br> >> Cc: "<a \
href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a> \
Developers" <<a href="mailto:cfe-dev@cs.uiuc.edu" \
target="_blank">cfe-dev@cs.uiuc.edu</a>>, "Richard Smith" <<a \
href="mailto:richard@metafoo.co.uk" target="_blank">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" \
target="_blank">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" \
target="_blank">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" target="_blank">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> </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