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

Wed Oct 25 11:34:58 PDT 2017

On Wed, Oct 25, 2017 at 10:42 AM, Hal Finkel <hfinkel at anl.gov> wrote:

>
> 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> 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?
>
>
> 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)?
>
>
Is that another reason (Oz) we want to do the transition selectively
first?  For PGO, the size and compile time regression is usually not the
main concerns, so it is the candidate basically with no roadblocks for
adopting.

David

>  -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
>>> 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
>>
>> --
> 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/33325922/attachment.html>