[llvm-dev] RFC: Switching to the new pass manager by default
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Wed Oct 25 10:19:04 PDT 2017
On 10/25/2017 12:16 PM, Xinliang David Li via llvm-dev wrote:
>
>
> On Tue, Oct 17, 2017 at 11:50 PM, Chandler Carruth via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> 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
> <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?
>
>
>
> Missing support of 'print-after-all' or 'print-after-passX' is
> another major usability loss.
>
> Regarding the default switch, maybe do it in two steps:
>
> 1) Switch the default for PGO build first
> 2) Switch the default for all modes.
Why?
-Hal
>
> David
>
>
>
> 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 <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171025/51b96431/attachment-0001.html>
More information about the llvm-dev
mailing list