[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:       Nico Weber <thakis () chromium ! org>
Date:       2015-07-16 19:52:46
Message-ID: CAMGbLiHZGUQgy_W2yGO+PXSkESyV9ayBzw0CggJ0UW88dioiuQ () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Wed, Jul 15, 2015 at 10:11 PM, 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).
>

Out of interest, is there data to suggest that this type of optimization
will happen often in practice?


>
> 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
>

[Attachment #5 (text/html)]

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 15, 2015 \
at 10:11 PM, Hal Finkel <span dir="ltr">&lt;<a href="mailto:hfinkel@anl.gov" \
target="_blank">hfinkel@anl.gov</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Hi everyone,<br> <br>
C++11 added features that allow for certain parts of the class hierarchy to be \
closed, specifically the &#39;final&#39; 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:<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-&gt;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 &#39;dispatch&#39; \
into &#39;opportunity&#39; but we don&#39;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).<br></blockquote><div><br></div><div>Out of \
interest, is there data to suggest that this type of optimization will happen often \
in practice?</div><div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
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 \
&#39;opportunity&#39; (and then teach the optimizer to use that information), but \
I&#39;m not at all sure that&#39;s the best solution. Thoughts?<br> <br>
Thanks again,<br>
Hal<br>
<span class="HOEnZb"><font color="#888888"><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> \
</font></span></blockquote></div><br></div></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]