[polly] Remove legacy pass manager hooks

[aeubanks]

Summary

And some options that only throw errors with the new PM.

[aeubanks]

remove legacy PM tests
remove unused function

[Meinersbur]

-enable-new-pm is going to be removed from opt? What is that patch doing that?

polly/test/Support/defaultpipelines.ll

1–2 ↗

(On Diff #470518)

[Meinersbur]

polly/lib/Support/RegisterPasses.cpp

734

b) (POSITION_AFTER_LOOPOPT is not supported by the NPM because there is no extension point). Maybe remove it entirely?

[aeubanks]

address comments

[aeubanks]

In D136621#3885759, @Meinersbur wrote:

-enable-new-pm is going to be removed from opt? What is that patch doing that?

it's explicitly for the legacy PM -> new PM migration, which has basically already happened. on discourse we've talked about how to deal with the option, and we're now trying to remove it

polly/lib/Support/RegisterPasses.cpp

734

done.

that extension point looks like it was specifically for loop passes, but due to the legacy PM design it's possible to add non-loop passes and have it still run like that. so perhaps not worth porting to the new PM

[Meinersbur]

Some other Polly options become inaccessible using any pipeline builder: PollyACC (-polly-target), static expansion (-polly-enable-mse), polyhedral info (-polly-enable-polyhedralinfo), and JSON export (-polly-export).

-polly-target, -polly-enable-mse and -polly-enable-polyhedralinfo are experiments that are effectively unmaintained now and I think should also be removed in this patch (that is, the cl::opt options, I can remove the passes separately at some point unless someone jumps in to update them to the NPM)

I will commit a patch that makes -polly-export usable with the NPM.

polly/lib/Support/RegisterPasses.cpp

734

it's possible to add non-loop passes and have it still run like that

do you mean impossible? I can only add loop passes at that point while Polly uses function passes.

That extension point was added to the legacy pass manager by @grosser explicitly to implement -polly-position=after-loopopt. I am not aware of any other use of it.

In any case, I never used that position and therefore fine with removing it.

[Meinersbur]

MaximalStaticExpansion expansion was actually already ported to the NPM in D125870. I made the NPM pass builder use it in rGb150d34c47ef.

That is, only the flags -polly-target and -polly-enable-polyhedralinfo remain to have no function without the legacy pass manager (other than throwing a fatal error) and should be removed with this patch.

[aeubanks]

remove more options

[Meinersbur]

LGTM

polly/lib/Support/RegisterPasses.cpp

static bool shouldEnablePollyForDiagnostic() {
   // programmatically.
   if (PollyOnlyPrinter || PollyPrinter || PollyOnlyViewer || PollyViewer)
     PollyTrackFailures = true;
 
   return PollyOnlyPrinter || PollyPrinter || PollyOnlyViewer || PollyViewer ||
          ExportJScop;
 }
 
-static void
-registerPollyEarlyAsPossiblePasses(const llvm::PassManagerBuilder &Builder,
-                                   llvm::legacy::PassManagerBase &PM) {
-  if (PassPosition != POSITION_EARLY)
-    return;
-
-  bool EnableForOpt = shouldEnablePollyForOptimization() &&
-                      Builder.OptLevel >= 1 && Builder.SizeLevel == 0;
-  if (!shouldEnablePollyForDiagnostic() && !EnableForOpt)
-    return;
-
-  registerCanonicalicationPasses(PM);
-  registerPollyPasses(PM, EnableForOpt);
-}
-
-static void
-registerPollyLoopOptimizerEndPasses(const llvm::PassManagerBuilder &Builder,
-                                    llvm::legacy::PassManagerBase &PM) {
-  if (PassPosition != POSITION_AFTER_LOOPOPT)
-    return;
-
-  bool EnableForOpt = shouldEnablePollyForOptimization() &&
-                      Builder.OptLevel >= 1 && Builder.SizeLevel == 0;
-  if (!shouldEnablePollyForDiagnostic() && !EnableForOpt)
-    return;
-
-  registerPollyPasses(PM, EnableForOpt);
-  if (EnableForOpt)
-    PM.add(createCodegenCleanupPass());
-}
-
-static void
-registerPollyScalarOptimizerLatePasses(const llvm::PassManagerBuilder &Builder,
-                                       llvm::legacy::PassManagerBase &PM) {
-  if (PassPosition != POSITION_BEFORE_VECTORIZER)
-    return;
-
-  bool EnableForOpt = shouldEnablePollyForOptimization() &&
-                      Builder.OptLevel >= 1 && Builder.SizeLevel == 0;
-  if (!shouldEnablePollyForDiagnostic() && !EnableForOpt)
-    return;
-
-  polly::registerPollyPasses(PM, EnableForOpt);
-  if (EnableForOpt)
-    PM.add(createCodegenCleanupPass());
-}
-
 /// Add the pass sequence required for Polly to the New Pass Manager.
 ///
 /// @param PM           The pass manager itself.
 /// @param Level        The optimization level. Used for the cleanup of Polly's
 ///                     output.
 /// @param EnableForOpt Whether to add Polly IR transformations. If False, only
 ///                     the analysis passes are added, skipping Polly itself.
 ///                     The IR may still be modified.
if (DumpAfter)
     PM.addPass(DumpFunctionPass("-after"));
   if (!DumpAfterFile.empty())
     llvm::report_fatal_error(
         "Option -polly-dump-after-file at -polly-position=late "
         "not supported with NPM",
         false);
 }
 
-/// Register Polly to be available as an optimizer
-///
-///
-/// We can currently run Polly at three different points int the pass manager.
-/// a) very early, b) after the canonicalizing loop transformations and c) right
-/// before the vectorizer.
-///
-/// The default is currently a), to register Polly such that it runs as early as
-/// possible. This has several implications:
-///
-///   1) We need to schedule more canonicalization passes
-///
-///   As nothing is run before Polly, it is necessary to run a set of preparing
-///   transformations before Polly to canonicalize the LLVM-IR and to allow
-///   Polly to detect and understand the code.
-///
-///   2) LICM and LoopIdiom pass have not yet been run
-///
-///   Loop invariant code motion as well as the loop idiom recognition pass make
-///   it more difficult for Polly to transform code. LICM may introduce
-///   additional data dependences that are hard to eliminate and the loop idiom
-///   recognition pass may introduce calls to memset that we currently do not
-///   understand. By running Polly early enough (meaning before these passes) we
-///   avoid difficulties that may be introduced by these passes.
-///
-///   3) We get the full -O3 optimization sequence after Polly
-///
-///   The LLVM-IR that is generated by Polly has been optimized on a high level,
-///   but it may be rather inefficient on the lower/scalar level. By scheduling
-///   Polly before all other passes, we have the full sequence of -O3
-///   optimizations behind us, such that inefficiencies on the low level can
-///   be optimized away.
-///
-/// We are currently evaluating the benefit or running Polly at position b) or
-/// c). b) is likely too early as it interacts with the inliner. c) is nice
-/// as everything is fully inlined and canonicalized, but we need to be able
-/// to handle LICMed code to make it useful.
-static llvm::RegisterStandardPasses RegisterPollyOptimizerEarly(
-    llvm::PassManagerBuilder::EP_ModuleOptimizerEarly,
-    registerPollyEarlyAsPossiblePasses);
-
-static llvm::RegisterStandardPasses
-    RegisterPollyOptimizerLoopEnd(llvm::PassManagerBuilder::EP_LoopOptimizerEnd,
-                                  registerPollyLoopOptimizerEndPasses);
-
-static llvm::RegisterStandardPasses RegisterPollyOptimizerScalarLate(
-    llvm::PassManagerBuilder::EP_VectorizerStart,
-    registerPollyScalarOptimizerLatePasses);
-
 static OwningScopAnalysisManagerFunctionProxy
 createScopAnalyses(FunctionAnalysisManager &FAM,
                    PassInstrumentationCallbacks *PIC) {
   OwningScopAnalysisManagerFunctionProxy Proxy;
 #define SCOP_ANALYSIS(NAME, CREATE_PASS)                                       \
   Proxy.getManager().registerPass([PIC] {                                      \
     (void)PIC;                                                                 \
     return CREATE_PASS;                                                        \
parseTopLevelPipeline(llvm::ModulePassManager &MPM,
   }
 
   FPM.addPass(createFunctionToScopPassAdaptor(std::move(SPM)));
   MPM.addPass(createModuleToFunctionPassAdaptor(std::move(FPM)));
 
   return true;
 }
 
+/// Register Polly to be available as an optimizer
+///
+///
+/// We can currently run Polly at three different points int the pass manager.
+/// a) very early, b) after the canonicalizing loop transformations and c) right
+/// before the vectorizer.
+///
+/// The default is currently a), to register Polly such that it runs as early as
+/// possible. This has several implications:
+///
+///   1) We need to schedule more canonicalization passes
+///
+///   As nothing is run before Polly, it is necessary to run a set of preparing
+///   transformations before Polly to canonicalize the LLVM-IR and to allow
+///   Polly to detect and understand the code.
+///
+///   2) LICM and LoopIdiom pass have not yet been run
+///
+///   Loop invariant code motion as well as the loop idiom recognition pass make
+///   it more difficult for Polly to transform code. LICM may introduce
+///   additional data dependences that are hard to eliminate and the loop idiom
+///   recognition pass may introduce calls to memset that we currently do not
+///   understand. By running Polly early enough (meaning before these passes) we
+///   avoid difficulties that may be introduced by these passes.
+///
+///   3) We get the full -O3 optimization sequence after Polly
+///
+///   The LLVM-IR that is generated by Polly has been optimized on a high level,
+///   but it may be rather inefficient on the lower/scalar level. By scheduling
+///   Polly before all other passes, we have the full sequence of -O3
+///   optimizations behind us, such that inefficiencies on the low level can
+///   be optimized away.
+///
+/// We are currently evaluating the benefit or running Polly at position b) or
+/// c). b) is likely too early as it interacts with the inliner. c) is nice
+/// as everything is fully inlined and canonicalized, but we need to be able
+/// to handle LICMed code to make it useful.
 void registerPollyPasses(PassBuilder &PB) {
   PassInstrumentationCallbacks *PIC = PB.getPassInstrumentationCallbacks();
   PB.registerAnalysisRegistrationCallback([PIC](FunctionAnalysisManager &FAM) {
     registerFunctionAnalyses(FAM, PIC);
   });
   PB.registerPipelineParsingCallback(parseFunctionPipeline);
   PB.registerPipelineParsingCallback(
       [PIC](StringRef Name, FunctionPassManager &FPM,