<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Chandler/All,</p>
    <p>We've just started testing the new pass manager this week and we
      ran into a 548x slowdown (i.e., 6.28s to 3443.83s) for one of the
      files from SPEC2017/blender.  The issue arises only in debug
      builds due to the numerous calls to RefSCC::verify() and
      SCC::verify() in the LazyCallGraph implementation.  Would it make
      sense to start predicating these calls with the EXPENSIVE_CHECKS
      macro, rather than NDEBUG?</p>
    <p> Chad<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 10/18/2017 2:50 AM, Chandler Carruth
      via llvm-dev wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAGCO0Kh2FXY4D9WSLTmdHvOi8i-=fb-+i=6V6iv8LzzMV3NL6g@mail.gmail.com">
      <div dir="ltr">Greetings everyone!
        <div><br>
        </div>
        <div>The new pass manager is getting extremely close to the
          point where I'm not aware of any significant outstanding work
          needed, and I'd like to see what else would be needed to
          enable it by default. Here are the current functionality I'm
          aware of outstanding:</div>
        <div><br>
        </div>
        <div>1) Does not do non-trivial loop unswitching. Majority of
          this is in <a href="https://reviews.llvm.org/D34200"
            moz-do-not-send="true">https://reviews.llvm.org/D34200</a> but
          will need one or two small follow-ups.</div>
        <div><br>
        </div>
        <div>2) Currently, sanitizers don't work correctly with it.
          Thanks to the work of others, the missing infrastructure has
          been added and I'll send a patch to wire this up this week.</div>
        <div><br>
        </div>
        <div>3) Missing support for 'optnone'. I've been working on
          this, but the existing testing wasn't as thorough as I wanted,
          so it is going slowly. I've got about 1/4 of this implemented
          and should have patches this week or next.</div>
        <div><br>
        </div>
        <div>4) Missing opt-bisect (or similar) facility. This looks
          pretty trivial to add, but I've not even started. If anyone is
          interested in it, go for it. We might even be able to do
          something simpler using the generic debug counters and get
          equivalent functionality.</div>
        <div><br>
        </div>
        <div>... that's it?</div>
        <div><br>
        </div>
        <div>Optimization quality / run-time performance:</div>
        <div>- We've been using it at Google extensively and are very
          happy with the optimization quality. Benchmarks look *very*
          good here.</div>
        <div>- More data from other users would be important.</div>
        <div>- You can try it out with `-fexperimental-new-pass-manager`
          to Clang</div>
        <div><br>
        </div>
        <div>Compile-time performance:</div>
        <div>- Sometimes *much* better due to cached analyses.</div>
        <div>- Sometimes worse, typically due to more / different
          inlining in turn running main pipeline (GVN + InstCombine)
          more times or over more code.</div>
        <div>- Overall somewhat a wash, but the increased compile times
          typically due to the optimizer "trying" harder, so not too
          concerning on our end.</div>
        <div>- Again, more feedback from other users good:
          `-fexperimental-new-pass-manager` to Clang</div>
        <div><br>
        </div>
        <div>Once the four missing things land, I'll also happily work
          on collecting some of the basics on the test-suite and CTMark.
          But I suspect more "in the wild" data would really be useful
          here given the significance of the change.</div>
        <div><br>
        </div>
        <div>Thoughts? What else (beyond the four items above and
          feedback on run-time and compile-time) would folks like to
          see?</div>
        <div><br>
        </div>
        <div>Once this happens, I'll also be preparing some batch,
          mechanical updates to the test suite to primarily use the new
          pass manager. Also there is lots of documentation updates that
          will be needed here.</div>
        <div><br>
        </div>
        <div>-Chandler</div>
        <div><br>
        </div>
        <div>PS: I'll be sending a note to cfe-dev as a "heads up" about
          this discussion as in some ways, the default flip is mostly a
          Clang default flip. But hopefully our doc updates will trigger
          this being "perceived" as the default for other frontends, and
          I'll try to reach out to other major frontends as well (Swift
          and Rust are on my radar, and I've already started talking
          with Philip Reames about their Falcon JIT).</div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>