[prev in list] [next in list] [prev in thread] [next in thread]
List: cfe-dev
Subject: Re: [cfe-dev] [LLVMdev] Clang devirtualization proposal
From: Reid Kleckner <rnk () google ! com>
Date: 2015-08-01 1:04:07
Message-ID: CACs=tyLdqwOLziNMpJGp614O2sBG+4Sirmwkx21z4Y4krtESDQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Fri, Jul 31, 2015 at 5:03 PM, Philip Reames <listmail@philipreames.com>
wrote:
> On 07/31/2015 04:05 PM, Piotr Padlewski wrote:
>
> On Fri, Jul 31, 2015 at 3:53 PM, Philip Reames <listmail@philipreames.com>
> wrote:
>>
>> Quoting from the google doc: "If we don't know definition of some
>> function, we assume that it will not call @llvm.invariant.group.barrier().
>> "
>> This part really really bugs me. We generally try to assume minimal
>> knowledge of external functions (i.e. they can do anything) and this
>> assumption would invert that. Is there a way we can rephrase the proposal
>> which avoids the need for this? I'm not quite clear what this assumption
>> buys us.
>>
>> This is because without it the optimization will be useless. For example:
> A* a = new A;
> a->foo(); //outline virtual
> a->foo();
>
> If we will assume that foo calls @llvm.invariant.barrier, then we will not
> be able to optimize the second call.
>
> Why not? If foo calls @llvm.invariant.group.barrier, then it would have
> to produce a new SSA value to accomplish anything which might effect the
> second call. Given the call is on "a", not some return value from foo or a
> global variable, we know that any SSA value created inside foo isn't
> relevant. We should end up a with two loads of the vtable using the same
> SSA value and the same invariant.group metadata. The later can be
> forwarded from the former without issue right?
>
> %a = ...;
> %vtable1 = load %a + Y !invariant.group !0
> %foo1 = load %vtable1 + X, !invariant.group !1
> call %foo1(%a)
> %vtable2 = load %a + Y !invariant.group !0 <-- Per state rules, this value
> forwards from previous vtable load
> %foo2 = load %vtable2 + X, !invariant.group !1
> call %foo2(%a)
>
Right, you got the intention of the design. The foo call can placement new
into %a if it wants to, but it better put things back the way they were
before we return, because %a isn't changing.
We probably missed that sentence when reviewing the proposal. :)
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jul 31, 2015 \
at 5:03 PM, Philip Reames <span dir="ltr"><<a \
href="mailto:listmail@philipreames.com" \
target="_blank">listmail@philipreames.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class=""><div>On 07/31/2015 04:05 PM, \
Piotr Padlewski wrote:</div><blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Fri, Jul 31, 2015 at 3:53 PM,
Philip Reames <span dir="ltr"><<a \
href="mailto:listmail@philipreames.com" \
target="_blank">listmail@philipreames.com</a>></span> wrote:
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"> <div bgcolor="#FFFFFF" text="#000000"> Quoting from \
the google doc: <span \
style="font-size:14.666666666666666px;font-family:Arial;color:#000000;background-color \
:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">"If
we don't know definition of some function, we assume
that it will not call \
@llvm.invariant.group.barrier().</span>"<br> This part really really bugs me. \
We generally try to assume minimal knowledge of external functions (i.e.
they can do anything) and this assumption would invert
that. Is there a way we can rephrase the proposal which
avoids the need for this? I'm not quite clear what this
assumption buys us.<br>
<br>
</div>
</blockquote>
<div>This is because without it the optimization will be
useless. For example:</div>
<div>A* a = new A;</div>
<div>a->foo(); //outline virtual</div>
<div>a->foo();</div>
<div><br>
</div>
<div>If we will assume that foo calls
@llvm.invariant.barrier, then we will not be able to
optimize the second call. <br>
</div>
</div>
</div>
</div>
</blockquote></span>
Why not? If foo calls @llvm.invariant.group.barrier, then it would
have to produce a new SSA value to accomplish anything which might
effect the second call. Given the call is on "a", not some return
value from foo or a global variable, we know that any SSA value
created inside foo isn't relevant. We should end up a with two
loads of the vtable using the same SSA value and the same
invariant.group metadata. The later can be forwarded from the
former without issue right?<br>
<br>
%a = ...;<br>
%vtable1 = load %a + Y !invariant.group !0<br>
%foo1 = load %vtable1 + X, !invariant.group !1<br>
call %foo1(%a)<br>
%vtable2 = load %a + Y !invariant.group !0 <-- Per state rules,
this value forwards from previous vtable load<br>
%foo2 = load %vtable2 + X, !invariant.group !1<br>
call %foo2(%a)</div></blockquote><div><br></div><div>Right, you got the intention \
of the design. The foo call can placement new into %a if it wants to, but it better \
put things back the way they were before we return, because %a isn't \
changing.</div><div><br></div><div>We probably missed that sentence when reviewing \
the proposal. :) </div></div></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