<div dir="ltr">On this file, we get<div><br></div><div>  11.0074 (83.0%)   0.1181 ( 49.5%)  11.1255 ( 82.6%)  11.1804 (82.7%)  Total   Global Value Numbering<br></div><div><br></div><div><br></div><div>I have files where GVN is 26-30 seconds, but memory ssa + gvn is still "6-7 seconds"</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 25, 2015 at 10:03 AM, 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">
    <div>Just for the perspective, how does this
      compare with our current GVN times without Memory SSA?<div><div class="h5"><br>
      <br>
      On 02/25/2015 09:49 AM, Daniel Berlin wrote:<br>
    </div></div></div>
    <blockquote type="cite"><div><div class="h5">
      <div dir="ltr">So, to circle back on timings:<br>
        On my very very large file with lots of functions i use to test
        GVN timings, 
        <div>doing the clobber checks at build time gives:<br>
          <br>
        </div>
        <div>
          <div>   3.9350 ( 46.4%)   0.0564 ( 36.2%)   3.9915 ( 46.2%)  
            4.0004 ( 46.2%)  Global Value Numbering</div>
          <div>   2.4518 ( 28.9%)   0.0276 ( 17.7%)   2.4795 ( 28.7%)  
            2.4841 ( 28.7%)  Memory SSA</div>
        </div>
        <div><br>
        </div>
        <div>
          <div>   3.8392 ( 46.2%)   0.0620 ( 37.8%)   3.9012 ( 46.0%)  
            3.9410 ( 46.1%)  Global Value Numbering</div>
          <div>   2.4047 ( 28.9%)   0.0319 ( 19.4%)   2.4366 ( 28.8%)  
            2.4532 ( 28.7%)  Memory SSA</div>
        </div>
        <div>
          <div><br>
          </div>
          <div>   3.9762 ( 46.4%)   0.0699 ( 38.7%)   4.0461 ( 46.3%)  
            4.1086 ( 46.4%)  Global Value Numbering</div>
          <div>   2.4720 ( 28.9%)   0.0354 ( 19.6%)   2.5074 ( 28.7%)  
            2.5295 ( 28.6%)  Memory SSA</div>
        </div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div>(As a side note, old GVN took 12 seconds, so yay!)</div>
        <div><br>
        </div>
        <div>Doing it lazily gives:</div>
        <div><br>
        </div>
        <div>
          <div>  5.4972 ( 60.2%)   0.0795 ( 44.3%)   5.5767 ( 59.9%)  
            5.6230 ( 60.0%)  Global Value Numbering</div>
          <div>   1.5262 ( 16.7%)   0.0261 ( 14.5%)   1.5523 ( 16.7%)  
            1.5618 ( 16.7%)  Memory SSA</div>
          <div><br>
          </div>
          <div>
            <div> 5.4386 ( 60.1%)   0.0744 ( 43.1%)   5.5131 ( 59.8%)  
              5.5430 ( 59.8%)  Global Value Numbering</div>
            <div>   1.5087 ( 16.7%)   0.0251 ( 14.5%)   1.5338 ( 16.6%)
                1.5413 ( 16.6%)  Memory SSA</div>
          </div>
          <div>
            <div>   </div>
            <div>   5.4627 ( 59.9%)   0.0865 ( 44.3%)   5.5492 ( 59.5%)
                5.6065 ( 59.5%)  Global Value Numbering</div>
            <div>   1.5382 ( 16.9%)   0.0296 ( 15.2%)   1.5678 ( 16.8%)
                1.5861 ( 16.8%)  Memory SSA</div>
          </div>
          <div><br>
          </div>
          <div><br>
          </div>
          <div>So, it definitely makes MemorySSA about 50-60% slower to
            build.</div>
          <div>However, overall, for GVN, which looks at all loads, it
            is combined-time 10-15% faster to do it at build time</div>
          <div>(6.2-6.5 seconds vs 6.9-7.0 seconds)<br>
          </div>
          <div><br>
          </div>
        </div>
        <div>So i think it should at least be an option when building
          memoryssa (though i admit to not knowing if there is an easy
          way for passes to give options to analysis passes.  If it keep
          it a utility, of course, it's easy)<br>
        </div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div>Thoughts welcome.</div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div>To put these pass times in perspective, something simple
          like dominator tree construction on this file takes:<br>
             0.6060 (  6.6%)   0.0189 (  9.7%)   0.6249 (  6.7%)  
          0.6323 (  6.7%)  Dominator Tree Construction<br>
        </div>
        <div><br>
        </div>
        <div>So uh, 1.5 seconds to do memoryssa is not that bad :)</div>
        <div><br>
        </div>
        <div><br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Wed, Feb 25, 2015 at 8:44 AM, Daniel
          Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div dir="ltr"><br>
              <div class="gmail_extra"><br>
                <div class="gmail_quote"><span>On Wed, Feb 25,
                    2015 at 12:07 AM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>></span>
                    wrote:<br>
                    <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>>
                        So, there is technically no guarantee that you
                        will get an access that<br>
                        > dominates you.<br>
                        <br>
                      </span>I'm unable to come up with a situation
                      where we'd start off with<br>
                      memory-def dominating memory-uses and
                      getMemoryClobberingAccess (as it<br>
                      is implemented currently) would return a
                      non-dominating memory access.<br>
                      Do you have an example where this would happen?<br>
                    </blockquote>
                    <div><br>
                    </div>
                  </span>
                  <div>As currently implemented, you are correct, it
                    will not.</div>
                  <div>But I have not finished integration into GVN yet.</div>
                  <div><br>
                  </div>
                  <div>Currently, GVN *wants* to know the clobber in all
                    cases so it can see if it can pull the store value
                    out if possible.</div>
                  <div><br>
                  </div>
                  <div>So i am likely to  have to change it (or build a
                    new API) to track and give the clobber if it's a
                    branch above a phi node.</div>
                  <div><br>
                  </div>
                  <div>I can certainly build a new API for this, or i
                    could just make doing what you suggest something it
                    does internally while building.</div>
                  <div><br>
                  </div>
                  <div>But otherwise, my main use case is GVN, and i'm a
                    bit wary of building an API for the rest (because i
                    have no idea what others want :P)</div>
                  <span>
                    <div><br>
                    </div>
                    <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
                        > This is a harder question.  If you do it to
                        every use, you may end up<br>
                        > spending a bunch of time doing that.<br>
                        > You are essentially trading build time for
                        query  time.<br>
                        > If the optimization pass only asks about
                        certain loads, it may not be a good<br>
                        > tradeoff.<br>
                        <br>
                      </span>Makes sense, thanks!<br>
                      <br>
                      A related question is if LLVM should cache the
                      result of<br>
                      `getClobberingMemoryAccess` in the MemoryAccess it
                      computed the result<br>
                      for (and the other MemoryAccess' it had to look
                      at, transitively).<br>
                      That seems like a good idea irrespective of how
                      many memory ops were<br>
                      queried.<br>
                    </blockquote>
                    <div><br>
                    </div>
                  </span>
                  <div> Yes, i think doing this makes sense, it'll save
                    densemap lookups.</div>
                  <div><br>
                  </div>
                  <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                    <span><font color="#888888"><br>
                        -- Sanjoy<br>
                      </font></span></blockquote>
                </div>
                <br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><pre>_______________________________________________
llvm-commits mailing list
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a>
</pre>
    </blockquote>
    <br>
  </div>

</blockquote></div><br></div>