LLVM: llvm::OuterAnalysisManagerProxy< AnalysisManagerT, IRUnitT, ExtraArgTs (original) (raw)

An analysis over an "inner" IR unit that provides access to an analysis manager over a "outer" IR unit. More...

template<typename AnalysisManagerT, typename IRUnitT, typename... ExtraArgTs>
class llvm::OuterAnalysisManagerProxy< AnalysisManagerT, IRUnitT, ExtraArgTs >

An analysis over an "inner" IR unit that provides access to an analysis manager over a "outer" IR unit.

The inner unit must be contained in the outer unit.

For example OuterAnalysisManagerProxy<ModuleAnalysisManager, Function> is an analysis over Functions (the "inner" unit) which provides access to a Module analysis manager. The ModuleAnalysisManager is the "outer" manager being proxied, and Modules are the "outer" IR unit. The inner/outer relationship is valid because each Function is contained in one Module.

This proxy only exposes the const interface of the outer analysis manager, to indicate that you cannot cause an outer analysis to run from within an inner pass. Instead, you must rely on the getCachedResult API. This is due to keeping potential future concurrency in mind. To give an example, running a module analysis before any function passes may give a different result than running it in a function pass. Both may be valid, but it would produce non-deterministic results. GlobalsAA is a good analysis example, because the cached information has the mod/ref info for all memory for each function at the time the analysis was computed. The information is still valid after a function transformation, but it may be different if recomputed after that transform. GlobalsAA is never invalidated. This proxy doesn't manage invalidation in any way – that is handled by the recursive return path of each layer of the pass manager. A consequence of this is the outer analyses may be stale. We invalidate the outer analyses only when we're done running passes over the inner IR units.

Definition at line 713 of file PassManager.h.