New Pass Manager: PreservedAnalyses and Analysis Cache Invalidation

How to verify that an analysis is re‑run

To determine whether a specific analysis is being recomputed after a custom pass (instead of being served from the NPM cache), you can add observable side‑effects to the analysis’ run method and then inspect the pass‑manager diagnostics.

Confirmed facts

• LLVM provides the LLVM_DEBUG macro guarded by a DEBUG_TYPE string; when the binary is built with assertions and debug support, each invocation of the analysis’ run method prints a message.
• The flag -debug-pass-manager (or -mllvm -debug-pass-manager when using clang) causes the New Pass Manager to emit a line for every analysis invalidation or preservation decision, including the analysis name.
• Combining -debug-pass-manager with -debug-only=passmanager limits the output to pass‑manager events, making it easy to grep for the analysis of interest.
• For a quantitative check, you can expose a static counter (or an option‑registered integer) that is incremented in the analysis’ run method; after a pipeline run the counter value tells you how many times the analysis was actually executed.

Likely explanation / steps to verify

1. Ensure your LLVM toolchain is built with assertions (-DLLVM_ENABLE_ASSERTIONS=ON) and debug support; otherwise the debug prints will be omitted.
2. In the analysis source, add a debug statement, e.g.:

   #include "llvm/Support/Debug.h"
   #define DEBUG_TYPE "my-analysis"
   
   AnalysisResult MyAnalysis::run(Module &M, ModuleAnalysisManager &AM) {
     LLVM_DEBUG(dbgs() << "[MyAnalysis] running on " << M.getName() << "\n");
     // … existing analysis logic …
     return Result;
   }
   

3. Re‑build the analysis (and any custom pass that uses it) with the same LLVM build.
4. Run your target with the NPM pipeline and enable the pass‑manager trace:

   clang -O2 -mllvm -debug-pass-manager -mllvm -debug-only=passmanager input.c -o output
   

5. Observe the console output. Each line containing "[MyAnalysis] running" indicates a genuine re‑execution. If the message appears only once despite multiple IR‑modifying passes, the analysis is being cached and incorrectly preserved.
6. Optionally, add a static counter:

   static unsigned MyAnalysisInvocations = 0;
   LLVM_DEBUG(dbgs() << "[MyAnalysis] invocation #" << ++MyAnalysisInvocations << "\n");
   

   After the run, print or expose MyAnalysisInvocations and compare it to the expected number of invalidations (e.g., one per modifying pass).

If you are not using an assertions‑enabled LLVM build, let me know so I can suggest an alternative verification method (e.g., using a custom pass plugin that registers a callback).