[prev in list] [next in list] [prev in thread] [next in thread]
List: llvm-dev
Subject: Re: [LLVMdev] Clang devirtualization proposal
From: Piotr Padlewski <prazek () google ! com>
Date: 2015-08-01 16:08:07
Message-ID: CABUQfFpy6_2qdE0QNXGH_dL+UyifXRWsnkowYCR+k_2KS4WSJg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
oh I see. Yep, my mistake.
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)
>
> Philip
>
>
>
[Attachment #5 (text/html)]
<div dir="ltr">oh I see. Yep, my mistake.</div><div class="gmail_extra"><br><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="">
<br>
<br>
<div>On 07/31/2015 04:05 PM, Piotr Padlewski
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<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)<span class="HOEnZb"><font color="#888888"><br>
<br>
Philip<br>
<br>
<br>
</font></span></div>
</blockquote></div><br></div>
_______________________________________________
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic