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