<div dir="ltr">I thought most of the extremely superlinear asserts were already behind EXPENSIVE_CHECKS, but we can add this one if you have a test case. Could you file a bug w/ a test case? I'd also be happy to try and just make the verify a bit less egregious. But I don't have that version of SPEC....</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 26, 2017 at 1:16 PM Chad Rosier <<a href="mailto:mcrosier@codeaurora.org">mcrosier@codeaurora.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <p>Sorry, by debug build I actually meant asserts enabled.  Thus,
      this issue can show up in either a debug or release build, if
      asserts are enabled.<br>
    </p></div><div text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="m_6790368233637729496moz-cite-prefix">On 10/26/2017 4:05 PM, Chad Rosier via
      llvm-dev wrote:<br>
    </div>
    <blockquote type="cite">
      
      <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="m_6790368233637729496moz-cite-prefix">On 10/18/2017 2:50 AM, Chandler
        Carruth via llvm-dev wrote:<br>
      </div>
      <blockquote type="cite">
        <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" target="_blank">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="m_6790368233637729496mimeAttachmentHeader"></fieldset>
        <br>
        <pre>_______________________________________________
LLVM Developers mailing list
<a class="m_6790368233637729496moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="m_6790368233637729496moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
      </blockquote>
      <br>
      <br>
      <fieldset class="m_6790368233637729496mimeAttachmentHeader"></fieldset>
      <br>
      <pre>_______________________________________________
LLVM Developers mailing list
<a class="m_6790368233637729496moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="m_6790368233637729496moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
    </blockquote>
    <br>
  </div></blockquote></div>