<div dir="ltr">I just tried putting a relatively recent version of our merge branch (r316139 + our local changes) through a small subset of the PS4 testing with <span style="font-size:12.8px">-fexperimental-new-pass-</span><wbr style="font-size:12.8px"><span style="font-size:12.8px">manager enabled. In general, most tests passed :). There are a few failures I'd need to look at in more detail though. The most glaring are all our tests related to generating coverage info:</span><div><span style="font-size:12.8px"><br></span></div><div><div><span style="font-size:12.8px">$ cat 1.cpp</span></div><div><span style="font-size:12.8px">void foo(){}</span></div><div><span style="font-size:12.8px">$ ./build/bin/clang -c -fprofile-instr-generate -fcoverage-mapping 1.cpp</span></div><div><span style="font-size:12.8px">$ ./build/bin/clang -c -fprofile-instr-generate -fcoverage-mapping 1.cpp -fexperimental-new-pass-manager</span></div><div><span style="font-size:12.8px">instrprof failed to lower an increment</span></div><div><span style="font-size:12.8px">UNREACHABLE executed at /home/greg/public_git/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:5893!</span></div><div style="font-size:12.8px"><br></div></div><div><span style="font-size:12.8px">which I'm assuming is the same thing as was reported in <a href="https://bugs.llvm.org/show_bug.cgi?id=33773">https://bugs.llvm.org/show_bug.cgi?id=33773</a> . This would definitely be a prerequisite for us to consider flipping the default. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">There are a few tests looking for specific codegen that are seeing something different. At a glance, it looks like the output from clang's -O2 looks roughly similar in some small examples with and without the new PM, but clang's -O1 is producing very different output. Whether this is an issue, I can't say for sure (I've not tried benchmarking the -O1s against each other yet). Is this expected?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I've also got an example of a specific file that shows quite a large compile time increase with the new PM:</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Old PM:</span></div><div><div><span style="font-size:12.8px"> ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---</span></div><div><span style="font-size:12.8px"> 15.8125 ( 96.0%) 0.2969 ( 95.0%) 16.1094 ( 96.0%) 16.1059 ( 96.1%) Code Generation Time</span></div><div><span style="font-size:12.8px"> 0.6563 ( 4.0%) 0.0156 ( 5.0%) 0.6719 ( 4.0%) 0.6609 ( 3.9%) LLVM IR Generation Time</span></div><div><span style="font-size:12.8px"> 16.4688 (100.0%) 0.3125 (100.0%) 16.7813 (100.0%) 16.7668 (100.0%) Total</span></div></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">New PM:</span></div><div><div><span style="font-size:12.8px"> ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name ---</span></div><div><span style="font-size:12.8px"> 67.0781 ( 99.1%) 0.3438 ( 95.7%) 67.4219 ( 99.0%) 67.4543 ( 99.0%) Code Generation Time</span></div><div><span style="font-size:12.8px"> 0.6406 ( 0.9%) 0.0156 ( 4.3%) 0.6563 ( 1.0%) 0.6644 ( 1.0%) LLVM IR Generation Time</span></div><div><span style="font-size:12.8px"> 67.7188 (100.0%) 0.3594 (100.0%) 68.0781 (100.0%) 68.1187 (100.0%) Total</span></div></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">It's not an example I can easily share (and also not one I'm easily able to verify in its present state on a branch without our local changes to make sure they're not responsible somehow), but if it's of interest I can see whether I can reduce it to something shareable and raise a bug.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">If I get a chance, I'll try putting this through some PS4 game codebases to see how build time and run time performance compare there, but I'm one of the few manning the fort while most of the rest of the team is out having a nice time at the Developers' Meeting this week, so I may not get that chance for a bit.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Cheers,</span></div><div><span style="font-size:12.8px">-Greg</span></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 18 October 2017 at 07:50, Chandler Carruth via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.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">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/<wbr>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-<wbr>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-<wbr>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><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Chandler</div></font></span><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>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>