llvm dev - Dec 2020 - [RFC] Expanding the scope of ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER

The ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER CMake flag currently only affects
Clang. It should probably also change all other uses of pass managers where
possible.

There are a couple of uses inside LLD for LTO which already have new/legacy
PM flags and should probably look at ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER
to determine the default. Some
<https://github.com/llvm/llvm-project/blob/1314a4938fba865412598b7227cb4657d59cd8bc/lld/wasm/Driver.cpp#L382>
examples
<https://github.com/llvm/llvm-project/blob/1314a4938fba865412598b7227cb4657d59cd8bc/llvm/include/llvm/LTO/Config.h#L53>
.

Also at some point in the future when check-llvm has been fixed to work
with opt's -enable-new-pm flag by default, that should also be dependent
upon ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER.

Any objections?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201201/bcb92d3f/attachment.html>

https://reviews.llvm.org/D92433 for an example of changing LTO pass manager
defaults (not ready to submit yet, need to fix a couple things first)

On Tue, Dec 1, 2020 at 12:34 PM Arthur Eubanks <aeubanks at google.com>
wrote:
> The ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER CMake flag currently only affects
> Clang. It should probably also change all other uses of pass managers where
> possible.
>
> There are a couple of uses inside LLD for LTO which already have
> new/legacy PM flags and should probably look at
> ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER to determine the default. Some
>
<https://github.com/llvm/llvm-project/blob/1314a4938fba865412598b7227cb4657d59cd8bc/lld/wasm/Driver.cpp#L382>
> examples
>
<https://github.com/llvm/llvm-project/blob/1314a4938fba865412598b7227cb4657d59cd8bc/llvm/include/llvm/LTO/Config.h#L53>
> .
>
> Also at some point in the future when check-llvm has been fixed to work
> with opt's -enable-new-pm flag by default, that should also be
dependent
> upon ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER.
>
> Any objections?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201201/ac1a6bce/attachment.html>

I strongly disagree with this proposal.  As in, please do not land 
patches which implement this proposal.  If anything, we should remove 
the build time config flag entirely.

The new manager is mature and has been in wide use for a long time now.  
Moving it to a conditional compilation item is a major regression in 
implied maturity and completely unwarranted.  If anything, we should 
just flip the dang flag and make people using the old pass manager 
support it.  (Most downstream groups I know of are running NPM.)

Philip

On 12/1/20 12:34 PM, Arthur Eubanks via llvm-dev wrote:
> The ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER CMake flag currently only 
> affects Clang. It should probably also change all other uses of pass 
> managers where possible.
>
> There are a couple of uses inside LLD for LTO which already have 
> new/legacy PM flags and should probably look at 
> ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER to determine the default. Some 
>
<https://github.com/llvm/llvm-project/blob/1314a4938fba865412598b7227cb4657d59cd8bc/lld/wasm/Driver.cpp#L382>
> examples 
>
<https://github.com/llvm/llvm-project/blob/1314a4938fba865412598b7227cb4657d59cd8bc/llvm/include/llvm/LTO/Config.h#L53>.
>
> Also at some point in the future when check-llvm has been fixed to 
> work with opt's -enable-new-pm flag by default, that should also be 
> dependent upon ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER.
>
> Any objections?
>
> _______________________________________________
> 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/20201204/680cf4bd/attachment.html>