[NewPM] Add PipelineTuningOption to eagerly invalidate analyses

[aeubanks]

Summary

This trades off more compile time for less peak memory usage. Right now
it invalidates all function analyses after a module->function or
cgscc->function adaptor.

https://llvm-compile-time-tracker.com/compare.php?from=1fb24fe85a19ae71b00875ff6c96ef1831dcf7e3&to=cb28ddb063c87f0d5df89812ab2de9a69dd276db&stat=instructions
https://llvm-compile-time-tracker.com/compare.php?from=1fb24fe85a19ae71b00875ff6c96ef1831dcf7e3&to=cb28ddb063c87f0d5df89812ab2de9a69dd276db&stat=max-rss

For now this is just experimental.

See comments on why this may affect optimizations.

[aeubanks]

update

[asbirlea]

Can you also include the direct link to the memory comparison in the description?
(https://llvm-compile-time-tracker.com/compare.php?from=1fb24fe85a19ae71b00875ff6c96ef1831dcf7e3&to=f1604149f211f2fa2f5609ccdebb96491e961b7f&stat=max-rss)

[nikic]

llvm/include/llvm/Passes/PassBuilder.h

80 ↗

(On Diff #380459)

I think this could be more precise about what "invalidate more analyses" means. From the implementation, my understanding is that analyses will be invalidated after a function pass manager finishes processing a function.

Makes me wonder if we shouldn't be handling this in the Function to CGSCC/Module pass manager adaptors.

[nikic]

llvm/tools/opt/NewPMDriver.cpp

155 ↗

(On Diff #380459)

Can we please move this option from opt into LLVM? I'd like it to be testable via -mllvm equivalents without explicit frontend support.

[aeubanks]

make this affect all cgscc/module->function adaptors
just to simplify this change, now the flag isn't in PTO, it's just a global cl flag

[nikic]

LG

[nikic]

Here are the results for this change with rust's compile-time tracking infrastructure:

Compile-time: https://perf.rust-lang.org/compare.html?start=5dab47dcd8267b8769421b46532414ec36d625e3&end=cfe9eecdf01985dff182ce388fe843987d1da888 (disable the filtering to see fairly consistent minor impact)
Max-rss: https://perf.rust-lang.org/compare.html?start=5dab47dcd8267b8769421b46532414ec36d625e3&end=cfe9eecdf01985dff182ce388fe843987d1da888&stat=max-rss

This looks like a pretty good tradeoff to me.

[aeubanks]

In D111575#3072134, @nikic wrote:

Here are the results for this change with rust's compile-time tracking infrastructure:

Compile-time: https://perf.rust-lang.org/compare.html?start=5dab47dcd8267b8769421b46532414ec36d625e3&end=cfe9eecdf01985dff182ce388fe843987d1da888 (disable the filtering to see fairly consistent minor impact)
Max-rss: https://perf.rust-lang.org/compare.html?start=5dab47dcd8267b8769421b46532414ec36d625e3&end=cfe9eecdf01985dff182ce388fe843987d1da888&stat=max-rss

This looks like a pretty good tradeoff to me.

interesting, it doesn't match the Clang numbers

llvm/lib/Analysis/CGSCCPassManager.cpp

 
 #define DEBUG_TYPE "cgscc"
 
 using namespace llvm;
 
 // Explicit template instantiations and specialization definitions for core
 // template typedefs.
 namespace llvm {
+extern cl::opt<bool> EagerlyInvalidateAnalyses;
 
 static cl::opt<bool> AbortOnMaxDevirtIterationsReached(
     "abort-on-max-devirt-iterations-reached",
     cl::desc("Abort when the max iterations for devirtualization CGSCC repeat "
              "pass is reached"));
 
 // Explicit instantiations for the core proxy templates.
 template class AllAnalysesOn<LazyCallGraph::SCC>;
PreservedAnalyses PassPA;
       PassPA = Pass->run(F, FAM);
     }
 
     PI.runAfterPass<Function>(*Pass, F, PassPA);
 
     // We know that the function pass couldn't have invalidated any other
     // function's analyses (that's the contract of a function pass), so
     // directly handle the function analysis manager's invalidation here.
-    FAM.invalidate(F, PassPA);
+    FAM.invalidate(F, EagerlyInvalidateAnalyses ? PreservedAnalyses::none()
+                                                : PassPA);
 
     // Then intersect the preserved set so that invalidation of module
     // analyses will eventually occur when the module pass completes.
     PA.intersect(std::move(PassPA));
 
     // If the call graph hasn't been preserved, update it based on this
     // function pass. This may also update the current SCC to point to
     // a smaller, more refined SCC.

llvm/lib/IR/PassManager.cpp

 //===- PassManager.cpp - Infrastructure for managing & running IR passes --===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #include "llvm/IR/PassManager.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/IR/LLVMContext.h"
 #include "llvm/IR/PassManagerImpl.h"
+#include "llvm/Support/CommandLine.h"
 
 using namespace llvm;
 
+namespace llvm {
+// Experimental option to eagerly invalidate more analyses. This has the
+// potential to decrease max memory usage in exchange for more compile time.
+// This may affect codegen due to either passes using analyses only when
+// cached, or invalidating and recalculating an analysis that was
+// stale/imprecise but still valid. Currently this invalidates all function
+// analyses after a module->function or cgscc->function adaptor.
+// TODO: make this a PipelineTuningOption.
+cl::opt<bool> EagerlyInvalidateAnalyses(
+    "eagerly-invalidate-analyses", cl::init(false), cl::Hidden,
+    cl::desc("Eagerly invalidate more analyses in default pipelines"));
+
 // Explicit template instantiations and specialization defininitions for core
 // template typedefs.
-namespace llvm {
 template class AllAnalysesOn<Module>;
 template class AllAnalysesOn<Function>;
 template class PassManager<Module>;
 template class PassManager<Function>;
 template class AnalysisManager<Module>;
 template class AnalysisManager<Function>;
 template class InnerAnalysisManagerProxy<FunctionAnalysisManager, Module>;
 template class OuterAnalysisManagerProxy<ModuleAnalysisManager, Function>;
PreservedAnalyses PassPA;
       PassPA = Pass->run(F, FAM);
     }
 
     PI.runAfterPass(*Pass, F, PassPA);
 
     // We know that the function pass couldn't have invalidated any other
     // function's analyses (that's the contract of a function pass), so
     // directly handle the function analysis manager's invalidation here.
-    FAM.invalidate(F, PassPA);
+    FAM.invalidate(F, EagerlyInvalidateAnalyses ? PreservedAnalyses::none()
+                                                : PassPA);
 
     // Then intersect the preserved set so that invalidation of module
     // analyses will eventually occur when the module pass completes.
     PA.intersect(std::move(PassPA));
   }
 
   // The FunctionAnalysisManagerModuleProxy is preserved because (we assume)
   // the function passes we ran didn't add or remove any functions.

llvm/test/Other/new-pm-eager-invalidate.ll

+; RUN: opt -disable-verify -debug-pass-manager -passes='function(require<no-op-function>)' -disable-output -eagerly-invalidate-analyses %s 2>&1 | FileCheck %s
+; RUN: opt -disable-verify -debug-pass-manager -passes='cgscc(function(require<no-op-function>))' -disable-output -eagerly-invalidate-analyses %s 2>&1 | FileCheck %s
+
+; CHECK: Invalidating analysis: NoOpFunctionAnalysis
+
+define void @foo() {
+  unreachable
+}