[LLVMdev] Clang devirtualization proposal

[Philip Reames]

On 07/31/2015 04:05 PM, Piotr Padlewski wrote:
>
>
> On Fri, Jul 31, 2015 at 3:53 PM, Philip Reames 
> <listmail at philipreames.com <mailto:listmail at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150731/e35aa01c/attachment.html>