Question
LLVM New Pass Manager and Legacy Pass Adapter Analysis Caching
Ira Finch
0 reputation · 10 Jun 2026, 18:09 UTC
78K views1
Loading…
0 reputation · 10 Jun 2026, 18:09 UTC
The transition to the New Pass Manager (NPM) in LLVM introduces a functional approach to pass orchestration, utilizing a nested pipeline structure to optimize IR. To maintain compatibility during migration, the PassManagerAdapter allows legacy passes to execute within the NPM framework.
A critical design consideration is the boundary between the NPM's analysis caching mechanism and the legacy manager's linear state. When a legacy pass is wrapped via the adapter, there is uncertainty regarding whether analysis results computed by the legacy pass are transparently available to subsequent NPM passes, or if the adapter triggers a full re-computation of the analysis.
Given the deprecation of the Legacy Pass Manager in recent LLVM versions, understanding the efficiency of this interoperability is essential for maintaining pipeline performance.
PassManagerAdapter synchronize analysis results back into the NPM's cache?35275 reputation · 11 Jun 2026, 02:53 UTC
The PassManagerAdapter (also known as LegacyPassAdapter) does forward analysis queries to the New Pass Manager’s AnalysisManager. When a legacy pass preserves an analysis, the result is cached and can be reused by later NPM passes; when the legacy pass invalidates an analysis, the adapter notifies the NPM, which clears the corresponding cache entry.
llvmAnalysisManager per module that caches analysis results across passes.LegacyPassAdapter implements the PreservedAnalyses interface and translates a legacy pass’s preservation or invalidation into NPM analysis‑manager invalidations.If an NPM analysis pass follows a legacy pass that modified the same IR property, the outcome depends on whether the legacy pass declared that it preserves the analysis:
PreservedAnalyses::none() (or the specific set invalidated); the NPM clears the cached entry, so the subsequent NPM analysis pass computes a fresh result (cache miss).Thus, the adapter does synchronize analysis results back into the NPM cache, but only when the legacy pass explicitly indicates preservation.
# Build or obtain LLVM (≥12 recommended)
opt -passes='print<module>' -debug-pass-manager \
-legacy-pass-adapter=<your‑legacy‑pass> \
-simplifycfg \
<input‑ir> 2>&1 | grep -E 'AnalysisManager: (cached|miss)'
Look for lines such as AnalysisManager: cached result for ... (hit) or AnalysisManager: missed result for ... (miss). Change the legacy pass to return PreservedAnalyses::none() and observe the miss count increase.
To give a definitive recommendation, we need to know whether your legacy pass returns a non‑empty PreservedAnalyses set (i.e., claims to preserve the analysis in question). If it does not, the adapter will trigger invalidation and the NPM analysis will be recomputed.
Use comments to ask for clarification. Post a solution as an answer.
6,830 reputation · 11 Jun 2026, 05:08 UTC
The adapter runs a self-contained Legacy PassManager for the wrapped pipeline, so legacy analyses remain internal to that instance and are not exported into the NPM AnalysisManager.
NPM analyses therefore cannot reuse results computed by legacy passes inside the adapter. On completion the adapter signals that the IR region it operated on was modified, which causes NPM to invalidate its own cached analyses that depend on that region. The legacy results are discarded when the adapter returns.
Behavior is version-sensitive across LLVM releases and the adapter is transitional and deprecated. A practical check is to log compute vs reuse in an NPM analysis placed before and after the adapter and observe recomputation after a modifying legacy pass.