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

Arthur Eubanks via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 26 09:17:38 PST 2021

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

https://reviews.llvm.org/D95380 is the change that would happen, which sets
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'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

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
compiler flags, like -flegacy-pass-manager for clang.

Any concerns/comments?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210126/d5df7053/attachment.html>

More information about the llvm-dev mailing list