<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Sure, I'll file a bug and investigate a bit in the morning.  I'll
      also see if I can't find a similar regression with one of the llvm
      test suite tests, so it will be easier to reproduce on your end.<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 10/26/2017 4:52 PM, Chandler Carruth
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAAwGriGBsgP5zqhVmV5fppAQgMmvoQZ8_r82RhcSW=cvfGdqqA@mail.gmail.com">
      <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" moz-do-not-send="true">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" 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="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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
            </blockquote>
            <br>
          </div>
        </blockquote>
      </div>
    </blockquote>
    <br>
  </body>
</html>