[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: Nathan Wilson <nwilson20 () gmail ! com>
Date: 2015-07-17 2:23:20
Message-ID: CAMDJ-qZ-FQkNkj-+uGfXT2xzJUt4DrPpsB-YVkZX-DJUwvg4gA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Thu, Jul 16, 2015 at 2:52 PM, Nico Weber <thakis@chromium.org> wrote:
> 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?
>
To follow up on Hal's response, one company I know of having about 20 C++
developers have been using C++11 for the past couple of years and have
upgraded the compiler being used in the past 10 months for optimization
purposes. The 'final' keyword was used a lot and requested to be used in
code reviews in anticipation of getting this optimization for free when
upgrading compiler versions. A bit of a small sample size, but some other
financial companies I know of like people who have knowledge of C++11/14
and optimizations like this that follow.
>
>
>>
>> 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
>>
>
>
> _______________________________________________
> 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"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul \
16, 2015 at 2:52 PM, Nico Weber <span dir="ltr"><<a \
href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</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"><div class="gmail_extra"><div \
class="gmail_quote"><span class="">On Wed, Jul 15, 2015 at 10:11 PM, Hal Finkel <span \
dir="ltr"><<a href="mailto:hfinkel@anl.gov" \
target="_blank">hfinkel@anl.gov</a>></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 '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:<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 '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).<br></blockquote><div><br></div></span><div>Out \
of interest, is there data to suggest that this type of optimization will happen \
often in practice?</div></div></div></div></blockquote><div><br></div><div>To follow \
up on Hal's response, one company I know of having about 20 C++ developers have \
been using C++11 for the past couple of years and have upgraded the compiler being \
used in the past 10 months for optimization purposes. The 'final' keyword was \
used a lot and requested to be used in code reviews in anticipation of getting this \
optimization for free when upgrading compiler versions. A bit of a small sample size, \
but some other financial companies I know of like people who have knowledge of \
C++11/14 and optimizations like this that follow.</div><div> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div \
class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""> <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 \
'opportunity' (and then teach the optimizer to use that information), but \
I'm not at all sure that's the best solution. Thoughts?<br> <br>
Thanks again,<br>
Hal<br>
</span><span><font color="#888888"><span class=""><br>
--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
_______________________________________________<br>
cfe-dev mailing list<br>
</span><span class=""><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> \
</span></font></span></blockquote></div><br></div></div> \
<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></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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic