[llvm-dev] RFC: Switching to the new pass manager by default

[Chad Rosier via llvm-dev]

Chandler/All,

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?

  Chad


On 10/18/2017 2:50 AM, Chandler Carruth via llvm-dev wrote:
> Greetings everyone!
>
> 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:
>
> 1) Does not do non-trivial loop unswitching. Majority of this is in 
> https://reviews.llvm.org/D34200 but will need one or two small follow-ups.
>
> 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.
>
> 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.
>
> 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.
>
> ... that's it?
>
> Optimization quality / run-time performance:
> - We've been using it at Google extensively and are very happy with 
> the optimization quality. Benchmarks look *very* good here.
> - More data from other users would be important.
> - You can try it out with `-fexperimental-new-pass-manager` to Clang
>
> Compile-time performance:
> - Sometimes *much* better due to cached analyses.
> - Sometimes worse, typically due to more / different inlining in turn 
> running main pipeline (GVN + InstCombine) more times or over more code.
> - Overall somewhat a wash, but the increased compile times typically 
> due to the optimizer "trying" harder, so not too concerning on our end.
> - Again, more feedback from other users good: 
> `-fexperimental-new-pass-manager` to Clang
>
> 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.
>
> Thoughts? What else (beyond the four items above and feedback on 
> run-time and compile-time) would folks like to see?
>
> 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.
>
> -Chandler
>
> 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).
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171026/fedb78f6/attachment.html>