[llvm-dev] [RFC] Changing the default pass manager for the optimization pipeline

[Eric Christopher via llvm-dev]

Congratulations! Thanks for all of your work here! :)

-eric

On Wed, Feb 3, 2021 at 7:59 PM Arthur Eubanks via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> This has been submitted as https://reviews.llvm.org/D95380. Please file
> bugs for any regressions.
>
> On Tue, Feb 2, 2021 at 12:25 PM Arthur Eubanks <aeubanks at google.com>
> wrote:
>
>> There are a couple of failures that I hadn't noticed showing up in the
>> presubmit, as well as some internally reported performance regressions due
>> to NPM-related changes, so this will likely get pushed back.
>>
>> On Wed, Jan 27, 2021 at 9:03 AM Philip Reames <listmail at philipreames.com>
>> wrote:
>>
>>> +1 to the strategy and timeline.  This has been a long time in the works
>>> and I'm thrilled to see us approaching this major milestone.
>>>
>>> minor comment inline below
>>>
>>> Philip
>>> On 1/26/21 9:17 AM, Arthur Eubanks via llvm-dev wrote:
>>>
>>> Hi all,
>>>
>>> We've been fixing the various remaining issues in order to turn on the
>>> new pass manager for the optimization pipeline, and it's about time to turn
>>> it on. (Thanks to everyone who has helped with testing and fixing the new
>>> pass manager!)
>>>
>>> https://reviews.llvm.org/D95380 is the change that would happen, which
>>> sets the CMake flag -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=ON by default.
>>> This affects anything that uses the LLVM_ENABLE_NEW_PASS_MANAGER macro,
>>> which includes opt's handling of the `opt -instcombine` syntax, clang, and
>>> ThinLTO in lld drivers. This does not affect the backend target-specific
>>> codegen pipeline since that's mostly not been ported to use the new PM
>>> infrastructure yet.
>>>
>>> Here <https://bugs.llvm.org/show_bug.cgi?id=46649> is the umbrella bug
>>> for turning on the new PM with blockers. The main one is loop
>>> unswitching on divergent loop conditions is unsafe
>>> <https://bugs.llvm.org/show_bug.cgi?id=48819>, which is being looked
>>> into. There's also the LLVM C API and bugpoint that still use the legacy
>>> PM, which can be ported later on and only block the removal of the legacy
>>> PM. The C API can be worked through (we may need to introduce replacements
>>> to the legacy pass manager APIs), but bugpoint will be tricky since it has
>>> so many legacy PM-specific hacks and we may need to trim it down if we want
>>> it to work with the new PM. Anyway, I don't think any of the remaining
>>> blockers are large enough to block the switch (but comments welcome).
>>>
>>> I see no problem with having these two remain on the legacy pass manager
>>> for the moment.  I do think we should expose a new C API for the NewPM and
>>> not try to shove the new one into the same API as the old one, but that's a
>>> weakly held opinion and easily discussed later.
>>>
>>>
>>> I'd like to turn on the new PM by default soonish, after the 12.x
>>> branch. Perhaps roughly a week from now barring any major newly discovered
>>> regressions?
>>>
>>> As for potential issues only uncovered after the switch, if there is a
>>> large issue I will roll it back, but for smaller issues I'd rather ask
>>> users to pin to the legacy PM while we fix the issues, either via the CMake
>>> flag -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=OFF, or the corresponding
>>> compiler flags, like -flegacy-pass-manager for clang.
>>>
>>> Any concerns/comments?
>>>
>>> _______________________________________________
>>> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20210204/5f7fed82/attachment-0001.html>