'Re: [cfe-dev] [LLVMdev] Clang devirtualization proposal'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfe-dev
Subject:    Re: [cfe-dev] [LLVMdev] Clang devirtualization proposal
From:       Philip Reames <listmail () philipreames ! com>
Date:       2015-08-01 0:03:14
Message-ID: 55BC0CC2.1070805 () philipreames ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

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

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div class="moz-cite-prefix">On 07/31/2015 04:05 PM, Piotr Padlewski
      wrote:<br>
    </div>
    <blockquote
cite="mid:CABUQfFpPaDVZZVCtMS3n6y5_d2htPgzP+xsHHjyvWBz7MQeijw@mail.gmail.com"
      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">&lt;<a moz-do-not-send="true"
                href="mailto:listmail@philipreames.com" \
target="_blank">listmail@philipreames.com</a>&gt;</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-&gt;foo(); //outline virtual</div>
            <div>a-&gt;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>
    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 &lt;-- Per state rules,
    this value forwards from previous vtable load<br>
    %foo2 = load %vtable2 + X, !invariant.group !1<br>
    call %foo2(%a)<br>
    <br>
    Philip<br>
    <br>
    <br>
  </body>
</html>

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