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

[Xinliang David Li via llvm-dev]

On Wed, Oct 25, 2017 at 10:19 AM, Hal Finkel <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> 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?
>>
>
>
> 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?

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
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
>
> _______________________________________________
> LLVM Developers mailing listllvm-dev at lists.llvm.orghttp://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/9d18c349/attachment.html>