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

Wed Oct 25 10:42:26 PDT 2017

On 10/25/2017 12:21 PM, Xinliang David Li wrote:
>
>
> On Wed, Oct 25, 2017 at 10:19 AM, Hal Finkel <hfinkel at anl.gov 
> <mailto:hfinkel at anl.gov>> wrote:
>
>
>     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?
>
>
> 1) PGO users benefit from the PM change the most
> 2) I suppose incremental changes are always better and causes fewer 
> churns?

I'm somewhat nervous about having the PGO builds differ so much from the 
non-PGO builds. My thought is that: (Significant) regressions in 
execution performance or compile time need to be fixed regardless. Maybe 
there's some flexibility on code-size regressions (e.g., such that we 
could delay the transition for -Oz if necessary)?

  -Hal

>
> David
>
>      -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 <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>
>
>     -- 
>     Hal Finkel
>     Lead, Compiler Technology and Programming Languages
>     Leadership Computing Facility
>     Argonne National Laboratory
>
-- 
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/d911c205/attachment.html>