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