Skip to content

Commit 4e171c9

Browse files
committed
[NFC][NewPM] Add clarification on analysis manager proxies
Explain why you can only get a cached analysis result, not compute one on the fly. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D84259
1 parent 7a33eaf commit 4e171c9

File tree

1 file changed

+10
-1
lines changed

1 file changed

+10
-1
lines changed

llvm/include/llvm/IR/PassManager.h

Lines changed: 10 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1061,7 +1061,16 @@ extern template class InnerAnalysisManagerProxy<FunctionAnalysisManager,
10611061
///
10621062
/// This proxy only exposes the const interface of the outer analysis manager,
10631063
/// to indicate that you cannot cause an outer analysis to run from within an
1064-
/// inner pass. Instead, you must rely on the \c getCachedResult API.
1064+
/// inner pass. Instead, you must rely on the \c getCachedResult API. This is
1065+
/// due to keeping potential future concurrency in mind. To give an example,
1066+
/// running a module analysis before any function passes may give a different
1067+
/// result than running it in a function pass. Both may be valid, but it would
1068+
/// produce non-deterministic results. GlobalsAA is a good analysis example,
1069+
/// because the cached information has the mod/ref info for all memory for each
1070+
/// function at the time the analysis was computed. The information is still
1071+
/// valid after a function transformation, but it may be *different* if
1072+
/// recomputed after that transform. GlobalsAA is never invalidated.
1073+
10651074
///
10661075
/// This proxy doesn't manage invalidation in any way -- that is handled by the
10671076
/// recursive return path of each layer of the pass manager. A consequence of

0 commit comments

Comments
 (0)