Pin -loop-reduce to legacy PM

[aeubanks]

Summary

LSR currently only runs in the codegen pass manager.
There are a couple issues with LSR and the NPM.

1. Lots of tests assume that LCSSA isn't run before LSR. This breaks a

bunch of tests' expected output. This is fixable with some time put in.

2. LSR doesn't preserve LCSSA. See

llvm/test/Analysis/MemorySSA/update-remove-deadblocks.ll. LSR's use of
SCEVExpander is the only use of SCEVExpander where the PreserveLCSSA option is
off. Turning it on causes some code sinking out of loops to fail due to
SCEVExpander's inability to handle the newly created trivial PHI nodes in the
broken critical edge (I was looking at
llvm/test/Transforms/LoopStrengthReduce/X86/2011-11-29-postincphi.ll).
I also tried simply just calling formLCSSA() at the end of LSR, but the extra
PHI nodes cause regressions in codegen tests.

We'll delay figuring these issues out until later.

This causes the number of check-llvm failures with -enable-new-pm true
by default to go from 60 to 29.

[rnk]

I'm in favor of this, but I'd like to get a second opinion from the other reviewers.

[asbirlea]

Discussed this offline, and proposed this solution to make progress and resolve the failing tests.
This does need exploring further though as:

1. the behavior of current LSR will no longer be tested in the new pass manager, due to LCSSA being run as a canonicalization pass.
2. adding it to a loop pass manager in the npm will be problematic, because it doesn't preserve LCSSA.

[aeubanks]

Currently LSR is not tested with the NPM in any circumstance.
There are no tests with -passes=loop-reduce, and LSR is only used in the codegen pass manager, so even with -DEXPERIMENTAL_NEW_PASS_MANAGER=ON, it's never in a NPM context.

[asbirlea]

In D92796#2440988, @aeubanks wrote:

Currently LSR is not tested with the NPM in any circumstance.
There are no tests with -passes=loop-reduce, and LSR is only used in the codegen pass manager, so even with -DEXPERIMENTAL_NEW_PASS_MANAGER=ON, it's never in a NPM context.

Exactly! But it's ported. So someone could add it to a pipeline anytime and chaos would ensue, that's what I meant :-). There may be out-of-tree usages or tests that are broken.

[aeubanks]

In D92796#2441005, @asbirlea wrote:

In D92796#2440988, @aeubanks wrote:

Currently LSR is not tested with the NPM in any circumstance.
There are no tests with -passes=loop-reduce, and LSR is only used in the codegen pass manager, so even with -DEXPERIMENTAL_NEW_PASS_MANAGER=ON, it's never in a NPM context.

Exactly! But it's ported. So someone could add it to a pipeline anytime and chaos would ensue, that's what I meant :-). There may be out-of-tree usages or tests that are broken.

Oh I see. Weird that it's ported but there are no tests for it.

[aeubanks]

Never mind I lied, there's one test ivchain.ll (plus an optnone test)

llvm/tools/opt/opt.cpp

std::vector<StringRef> PassNameExact = {
       "codegenprepare",       "interleaved-load-combine",
       "unreachableblockelim", "scalarize-masked-mem-intrin",
       "verify-safepoint-ir",  "divergence",
       "infer-address-spaces", "atomic-expand",
       "hardware-loops",       "type-promotion",
       "mve-tail-predication", "interleaved-access",
       "global-merge",         "pre-isel-intrinsic-lowering",
       "expand-reductions",    "indirectbr-expand",
-      "generic-to-nvvm",      "expandmemcmp"};
+      "generic-to-nvvm",      "expandmemcmp",
+      "loop-reduce"};
   for (const auto &P : PassNamePrefix)
     if (Pass.startswith(P))
       return true;
   for (const auto &P : PassNameContain)
     if (Pass.contains(P))
       return true;
   for (const auto &P : PassNameExact)
     if (Pass == P)