Turn on the new pass manager by default

[aeubanks]

Summary

This turns on the new pass manager by default for the optimization pipeline in
Clang and ThinLTO in various LLD backends. This also makes uses of `opt
-instcombine` use the new pass manager (unless specifically opted out).

This does not affect the backend target-dependent codegen pipeline.

If this causes regressions, you can opt out of the new pass manager
either via the -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=OFF CMake flag
while building LLVM, or via various compiler flags, e.g.
-flegacy-pass-manager for Clang or -Wl,--lto-legacy-pass-manager for
ELF LLD. Please file bugs for any regressions.

Major differences:

• The inliner works slightly differently
• -O1 does some amount of inlining
• LCSSA and LoopSimplify are run before all loop passes
• Loop unswitching is implemented slightly differently
• A new SpeculateAroundPHIs pass is added to the pipeline

https://lists.llvm.org/pipermail/llvm-dev/2021-January/148098.html

[aeubanks]

rebase

[aeubanks]

I'll submit this tomorrow if there are no objections

[ychen]

LGTM.

[aeubanks]

Actually, I may have to push this back to investigate the failures coming out of the presubmit

[MaskRay]

openmp libarcher tests failed for unrelated reasons. They triggered a clang crash. I noticed the issues in my other patches.

[echristo]

Adding Tom here as release manager so they know.

Lots of discussion over the years on doing this and as far as I know we've gotten all of the items talked about on llvm-dev. LGTM. Thanks for pushing through with this!

[tstellar]

Is this something we want to try to pull into the release/12.x branch?

[aeubanks]

Agreed with Eric, this definitely shouldn't go into 12.x.

[aeubanks]

rebase

[rnk]

In the context of https://bugs.llvm.org/show_bug.cgi?id=49606, I realized that most developers are probably still using the old pass manager. That issue only repros with the new PM, and @jdoerfert was using the legacy PM. I checked my local build dir, and observed this line in it:

ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER:BOOL=FALSE

One way to deal with this would be to deprecate the legacy spelling of ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER and switch to LLVM_ENABLE_NEW_PASS_MANAGER. If we don't do this, we'll have to make a PSA about clearing CMakeCache.txt anyway, so I think it's probably worth it.

[aeubanks]

In D95380#2632044, @rnk wrote:

In the context of https://bugs.llvm.org/show_bug.cgi?id=49606, I realized that most developers are probably still using the old pass manager. That issue only repros with the new PM, and @jdoerfert was using the legacy PM. I checked my local build dir, and observed this line in it:

ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER:BOOL=FALSE

One way to deal with this would be to deprecate the legacy spelling of ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER and switch to LLVM_ENABLE_NEW_PASS_MANAGER. If we don't do this, we'll have to make a PSA about clearing CMakeCache.txt anyway, so I think it's probably worth it.

I'd prefer not to rename the variable, since it was used in a bunch of communication, and updating bots is a pain. A PSA sounds good though.

llvm/CMakeLists.txt

if(WIN32 OR CYGWIN)
   else()
     set(LLVM_ENABLE_PLUGINS_default OFF)
   endif()
 else()
   set(LLVM_ENABLE_PLUGINS_default ${LLVM_ENABLE_PIC})
 endif()
 option(LLVM_ENABLE_PLUGINS "Enable plugin support" ${LLVM_ENABLE_PLUGINS_default})
 
-set(ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER FALSE CACHE BOOL
-  "Enable the experimental new pass manager by default.")
+set(ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER TRUE CACHE BOOL
+  "Enable the new pass manager by default.")
 
 include(HandleLLVMOptions)
 
 find_package(Python3 REQUIRED COMPONENTS Interpreter)
 
 ######
 
 # Configure all of the various header file fragments LLVM uses which depend on