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

[Renato Golin via llvm-dev]

It was bound to have the final teething issues, but I'm glad we're finally
pushing this through.

Good work and thank you everyone that worked on it for all these years!

On Thu, 4 Feb 2021 at 00:59, 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/46236c1e/attachment.html>