2013-11-14 10:55:14 +00:00
|
|
|
//===- PassManager.h - Pass management infrastructure -----------*- C++ -*-===//
|
2013-11-09 13:09:08 +00:00
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
/// \file
|
|
|
|
///
|
|
|
|
/// This header defines various interfaces for pass management in LLVM. There
|
|
|
|
/// is no "pass" interface in LLVM per se. Instead, an instance of any class
|
|
|
|
/// which supports a method to 'run' it over a unit of IR can be used as
|
|
|
|
/// a pass. A pass manager is generally a tool to collect a sequence of passes
|
|
|
|
/// which run over a particular IR construct, and run each of them in sequence
|
|
|
|
/// over each such construct in the containing IR construct. As there is no
|
|
|
|
/// containing IR construct for a Module, a manager for passes over modules
|
|
|
|
/// forms the base case which runs its managed passes in sequence over the
|
|
|
|
/// single module provided.
|
|
|
|
///
|
|
|
|
/// The core IR library provides managers for running passes over
|
|
|
|
/// modules and functions.
|
|
|
|
///
|
|
|
|
/// * FunctionPassManager can run over a Module, runs each pass over
|
|
|
|
/// a Function.
|
|
|
|
/// * ModulePassManager must be directly run, runs each pass over the Module.
|
|
|
|
///
|
2013-11-13 01:51:36 +00:00
|
|
|
/// Note that the implementations of the pass managers use concept-based
|
|
|
|
/// polymorphism as outlined in the "Value Semantics and Concept-based
|
|
|
|
/// Polymorphism" talk (or its abbreviated sibling "Inheritance Is The Base
|
|
|
|
/// Class of Evil") by Sean Parent:
|
|
|
|
/// * http://github.com/sean-parent/sean-parent.github.com/wiki/Papers-and-Presentations
|
2013-11-13 02:49:38 +00:00
|
|
|
/// * http://www.youtube.com/watch?v=_BpMYeUFXv8
|
2013-11-13 01:51:36 +00:00
|
|
|
/// * http://channel9.msdn.com/Events/GoingNative/2013/Inheritance-Is-The-Base-Class-of-Evil
|
|
|
|
///
|
2013-11-09 13:09:08 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2014-01-11 10:59:00 +00:00
|
|
|
#ifndef LLVM_IR_PASS_MANAGER_H
|
|
|
|
#define LLVM_IR_PASS_MANAGER_H
|
|
|
|
|
2013-11-13 01:12:08 +00:00
|
|
|
#include "llvm/ADT/DenseMap.h"
|
2013-11-20 11:31:50 +00:00
|
|
|
#include "llvm/ADT/SmallPtrSet.h"
|
2013-11-09 13:09:08 +00:00
|
|
|
#include "llvm/ADT/polymorphic_ptr.h"
|
2013-11-13 01:12:08 +00:00
|
|
|
#include "llvm/IR/Function.h"
|
2013-11-09 13:09:08 +00:00
|
|
|
#include "llvm/IR/Module.h"
|
2014-01-07 11:48:04 +00:00
|
|
|
#include "llvm/Support/type_traits.h"
|
2013-11-13 01:12:08 +00:00
|
|
|
#include <list>
|
2013-11-09 13:09:08 +00:00
|
|
|
#include <vector>
|
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
|
|
|
|
class Module;
|
|
|
|
class Function;
|
|
|
|
|
2013-11-20 11:31:50 +00:00
|
|
|
/// \brief An abstract set of preserved analyses following a transformation pass
|
|
|
|
/// run.
|
|
|
|
///
|
|
|
|
/// When a transformation pass is run, it can return a set of analyses whose
|
|
|
|
/// results were preserved by that transformation. The default set is "none",
|
|
|
|
/// and preserving analyses must be done explicitly.
|
|
|
|
///
|
|
|
|
/// There is also an explicit all state which can be used (for example) when
|
|
|
|
/// the IR is not mutated at all.
|
|
|
|
class PreservedAnalyses {
|
|
|
|
public:
|
|
|
|
/// \brief Convenience factory function for the empty preserved set.
|
|
|
|
static PreservedAnalyses none() { return PreservedAnalyses(); }
|
|
|
|
|
|
|
|
/// \brief Construct a special preserved set that preserves all passes.
|
|
|
|
static PreservedAnalyses all() {
|
|
|
|
PreservedAnalyses PA;
|
|
|
|
PA.PreservedPassIDs.insert((void *)AllPassesID);
|
|
|
|
return PA;
|
|
|
|
}
|
|
|
|
|
|
|
|
PreservedAnalyses &operator=(PreservedAnalyses Arg) {
|
|
|
|
swap(Arg);
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
void swap(PreservedAnalyses &Arg) {
|
|
|
|
PreservedPassIDs.swap(Arg.PreservedPassIDs);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Mark a particular pass as preserved, adding it to the set.
|
|
|
|
template <typename PassT> void preserve() {
|
|
|
|
if (!areAllPreserved())
|
|
|
|
PreservedPassIDs.insert(PassT::ID());
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Intersect this set with another in place.
|
|
|
|
///
|
|
|
|
/// This is a mutating operation on this preserved set, removing all
|
|
|
|
/// preserved passes which are not also preserved in the argument.
|
|
|
|
void intersect(const PreservedAnalyses &Arg) {
|
|
|
|
if (Arg.areAllPreserved())
|
|
|
|
return;
|
|
|
|
if (areAllPreserved()) {
|
|
|
|
PreservedPassIDs = Arg.PreservedPassIDs;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
for (SmallPtrSet<void *, 2>::const_iterator I = PreservedPassIDs.begin(),
|
|
|
|
E = PreservedPassIDs.end();
|
|
|
|
I != E; ++I)
|
|
|
|
if (!Arg.PreservedPassIDs.count(*I))
|
|
|
|
PreservedPassIDs.erase(*I);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Intersect this set with a temporary other set in place.
|
|
|
|
///
|
|
|
|
/// This is a mutating operation on this preserved set, removing all
|
|
|
|
/// preserved passes which are not also preserved in the argument.
|
|
|
|
void intersect(PreservedAnalyses &&Arg) {
|
|
|
|
if (Arg.areAllPreserved())
|
|
|
|
return;
|
|
|
|
if (areAllPreserved()) {
|
|
|
|
PreservedPassIDs = std::move(Arg.PreservedPassIDs);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
for (SmallPtrSet<void *, 2>::const_iterator I = PreservedPassIDs.begin(),
|
|
|
|
E = PreservedPassIDs.end();
|
|
|
|
I != E; ++I)
|
|
|
|
if (!Arg.PreservedPassIDs.count(*I))
|
|
|
|
PreservedPassIDs.erase(*I);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Query whether a pass is marked as preserved by this set.
|
|
|
|
template <typename PassT> bool preserved() const {
|
|
|
|
return preserved(PassT::ID());
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Query whether an abstract pass ID is marked as preserved by this
|
|
|
|
/// set.
|
|
|
|
bool preserved(void *PassID) const {
|
|
|
|
return PreservedPassIDs.count((void *)AllPassesID) ||
|
|
|
|
PreservedPassIDs.count(PassID);
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
// Note that this must not be -1 or -2 as those are already used by the
|
|
|
|
// SmallPtrSet.
|
|
|
|
static const uintptr_t AllPassesID = (intptr_t)-3;
|
|
|
|
|
|
|
|
bool areAllPreserved() const { return PreservedPassIDs.count((void *)AllPassesID); }
|
|
|
|
|
|
|
|
SmallPtrSet<void *, 2> PreservedPassIDs;
|
|
|
|
};
|
|
|
|
|
|
|
|
inline void swap(PreservedAnalyses &LHS, PreservedAnalyses &RHS) {
|
|
|
|
LHS.swap(RHS);
|
|
|
|
}
|
|
|
|
|
2013-11-09 13:09:08 +00:00
|
|
|
/// \brief Implementation details of the pass manager interfaces.
|
|
|
|
namespace detail {
|
|
|
|
|
|
|
|
/// \brief Template for the abstract base class used to dispatch
|
|
|
|
/// polymorphically over pass objects.
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
template <typename IRUnitT, typename AnalysisManagerT> struct PassConcept {
|
2013-11-09 13:09:08 +00:00
|
|
|
// Boiler plate necessary for the container of derived classes.
|
|
|
|
virtual ~PassConcept() {}
|
|
|
|
virtual PassConcept *clone() = 0;
|
|
|
|
|
|
|
|
/// \brief The polymorphic API which runs the pass over a given IR entity.
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
///
|
|
|
|
/// Note that actual pass object can omit the analysis manager argument if
|
|
|
|
/// desired. Also that the analysis manager may be null if there is no
|
|
|
|
/// analysis manager in the pass pipeline.
|
|
|
|
virtual PreservedAnalyses run(IRUnitT IR, AnalysisManagerT *AM) = 0;
|
2014-01-11 11:52:05 +00:00
|
|
|
|
|
|
|
/// \brief Polymorphic method to access the name of a pass.
|
|
|
|
virtual StringRef name() = 0;
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/// \brief SFINAE metafunction for computing whether \c PassT has a run method
|
|
|
|
/// accepting an \c AnalysisManagerT.
|
2013-11-22 12:11:02 +00:00
|
|
|
template <typename IRUnitT, typename AnalysisManagerT, typename PassT,
|
|
|
|
typename ResultT>
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
class PassRunAcceptsAnalysisManager {
|
|
|
|
typedef char SmallType;
|
|
|
|
struct BigType { char a, b; };
|
|
|
|
|
2013-11-22 12:11:02 +00:00
|
|
|
template <typename T, ResultT (T::*)(IRUnitT, AnalysisManagerT *)>
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
struct Checker;
|
|
|
|
|
|
|
|
template <typename T> static SmallType f(Checker<T, &T::run> *);
|
|
|
|
template <typename T> static BigType f(...);
|
|
|
|
|
|
|
|
public:
|
|
|
|
enum { Value = sizeof(f<PassT>(0)) == sizeof(SmallType) };
|
2013-11-09 13:09:08 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/// \brief A template wrapper used to implement the polymorphic API.
|
|
|
|
///
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
/// Can be instantiated for any object which provides a \c run method accepting
|
|
|
|
/// an \c IRUnitT. It requires the pass to be a copyable object. When the
|
|
|
|
/// \c run method also accepts an \c AnalysisManagerT*, we pass it along.
|
2013-11-22 11:55:38 +00:00
|
|
|
template <typename IRUnitT, typename AnalysisManagerT, typename PassT,
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
bool AcceptsAnalysisManager = PassRunAcceptsAnalysisManager<
|
2013-11-22 12:11:02 +00:00
|
|
|
IRUnitT, AnalysisManagerT, PassT, PreservedAnalyses>::Value>
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
struct PassModel;
|
|
|
|
|
|
|
|
/// \brief Specialization of \c PassModel for passes that accept an analyis
|
|
|
|
/// manager.
|
2013-11-22 11:55:38 +00:00
|
|
|
template <typename IRUnitT, typename AnalysisManagerT, typename PassT>
|
|
|
|
struct PassModel<IRUnitT, AnalysisManagerT, PassT,
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
true> : PassConcept<IRUnitT, AnalysisManagerT> {
|
2014-03-02 04:08:41 +00:00
|
|
|
PassModel(PassT Pass) : Pass(std::move(Pass)) {}
|
2014-03-08 08:27:28 +00:00
|
|
|
PassModel *clone() override { return new PassModel(Pass); }
|
|
|
|
PreservedAnalyses run(IRUnitT IR, AnalysisManagerT *AM) override {
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
return Pass.run(IR, AM);
|
|
|
|
}
|
2014-03-08 08:27:28 +00:00
|
|
|
StringRef name() override { return PassT::name(); }
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
PassT Pass;
|
|
|
|
};
|
|
|
|
|
|
|
|
/// \brief Specialization of \c PassModel for passes that accept an analyis
|
|
|
|
/// manager.
|
2013-11-22 11:55:38 +00:00
|
|
|
template <typename IRUnitT, typename AnalysisManagerT, typename PassT>
|
|
|
|
struct PassModel<IRUnitT, AnalysisManagerT, PassT,
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
false> : PassConcept<IRUnitT, AnalysisManagerT> {
|
2014-03-02 04:08:41 +00:00
|
|
|
PassModel(PassT Pass) : Pass(std::move(Pass)) {}
|
2014-03-08 08:27:28 +00:00
|
|
|
PassModel *clone() override { return new PassModel(Pass); }
|
|
|
|
PreservedAnalyses run(IRUnitT IR, AnalysisManagerT *AM) override {
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
return Pass.run(IR);
|
|
|
|
}
|
2014-03-08 08:27:28 +00:00
|
|
|
StringRef name() override { return PassT::name(); }
|
2013-11-09 13:09:08 +00:00
|
|
|
PassT Pass;
|
|
|
|
};
|
|
|
|
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
/// \brief Abstract concept of an analysis result.
|
|
|
|
///
|
|
|
|
/// This concept is parameterized over the IR unit that this result pertains
|
|
|
|
/// to.
|
|
|
|
template <typename IRUnitT> struct AnalysisResultConcept {
|
|
|
|
virtual ~AnalysisResultConcept() {}
|
|
|
|
virtual AnalysisResultConcept *clone() = 0;
|
|
|
|
|
|
|
|
/// \brief Method to try and mark a result as invalid.
|
|
|
|
///
|
2013-11-21 10:53:05 +00:00
|
|
|
/// When the outer analysis manager detects a change in some underlying
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
/// unit of the IR, it will call this method on all of the results cached.
|
|
|
|
///
|
2013-11-21 10:53:05 +00:00
|
|
|
/// This method also receives a set of preserved analyses which can be used
|
|
|
|
/// to avoid invalidation because the pass which changed the underlying IR
|
|
|
|
/// took care to update or preserve the analysis result in some way.
|
|
|
|
///
|
|
|
|
/// \returns true if the result is indeed invalid (the default).
|
2013-11-22 11:34:43 +00:00
|
|
|
virtual bool invalidate(IRUnitT IR, const PreservedAnalyses &PA) = 0;
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
};
|
|
|
|
|
2013-11-22 00:48:49 +00:00
|
|
|
/// \brief SFINAE metafunction for computing whether \c ResultT provides an
|
|
|
|
/// \c invalidate member function.
|
|
|
|
template <typename IRUnitT, typename ResultT> class ResultHasInvalidateMethod {
|
|
|
|
typedef char SmallType;
|
|
|
|
struct BigType { char a, b; };
|
|
|
|
|
2013-11-22 11:34:43 +00:00
|
|
|
template <typename T, bool (T::*)(IRUnitT, const PreservedAnalyses &)>
|
2013-11-22 00:48:49 +00:00
|
|
|
struct Checker;
|
|
|
|
|
|
|
|
template <typename T> static SmallType f(Checker<T, &T::invalidate> *);
|
|
|
|
template <typename T> static BigType f(...);
|
|
|
|
|
|
|
|
public:
|
|
|
|
enum { Value = sizeof(f<ResultT>(0)) == sizeof(SmallType) };
|
|
|
|
};
|
|
|
|
|
2013-11-21 09:10:21 +00:00
|
|
|
/// \brief Wrapper to model the analysis result concept.
|
|
|
|
///
|
|
|
|
/// By default, this will implement the invalidate method with a trivial
|
|
|
|
/// implementation so that the actual analysis result doesn't need to provide
|
|
|
|
/// an invalidation handler. It is only selected when the invalidation handler
|
|
|
|
/// is not part of the ResultT's interface.
|
2013-11-21 10:53:05 +00:00
|
|
|
template <typename IRUnitT, typename PassT, typename ResultT,
|
2013-11-22 00:48:49 +00:00
|
|
|
bool HasInvalidateHandler =
|
|
|
|
ResultHasInvalidateMethod<IRUnitT, ResultT>::Value>
|
|
|
|
struct AnalysisResultModel;
|
|
|
|
|
|
|
|
/// \brief Specialization of \c AnalysisResultModel which provides the default
|
|
|
|
/// invalidate functionality.
|
|
|
|
template <typename IRUnitT, typename PassT, typename ResultT>
|
|
|
|
struct AnalysisResultModel<IRUnitT, PassT, ResultT,
|
|
|
|
false> : AnalysisResultConcept<IRUnitT> {
|
2014-03-02 04:08:41 +00:00
|
|
|
AnalysisResultModel(ResultT Result) : Result(std::move(Result)) {}
|
2014-03-05 07:30:04 +00:00
|
|
|
AnalysisResultModel *clone() override {
|
2013-11-21 09:10:21 +00:00
|
|
|
return new AnalysisResultModel(Result);
|
|
|
|
}
|
|
|
|
|
2013-11-21 11:04:53 +00:00
|
|
|
/// \brief The model bases invalidation solely on being in the preserved set.
|
2013-11-21 09:10:21 +00:00
|
|
|
//
|
|
|
|
// FIXME: We should actually use two different concepts for analysis results
|
|
|
|
// rather than two different models, and avoid the indirect function call for
|
|
|
|
// ones that use the trivial behavior.
|
2014-03-05 07:30:04 +00:00
|
|
|
bool invalidate(IRUnitT, const PreservedAnalyses &PA) override {
|
2013-11-21 10:53:05 +00:00
|
|
|
return !PA.preserved(PassT::ID());
|
|
|
|
}
|
2013-11-21 09:10:21 +00:00
|
|
|
|
|
|
|
ResultT Result;
|
|
|
|
};
|
|
|
|
|
2013-11-22 00:48:49 +00:00
|
|
|
/// \brief Specialization of \c AnalysisResultModel which delegates invalidate
|
|
|
|
/// handling to \c ResultT.
|
2013-11-21 10:53:05 +00:00
|
|
|
template <typename IRUnitT, typename PassT, typename ResultT>
|
|
|
|
struct AnalysisResultModel<IRUnitT, PassT, ResultT,
|
|
|
|
true> : AnalysisResultConcept<IRUnitT> {
|
2014-03-02 04:08:41 +00:00
|
|
|
AnalysisResultModel(ResultT Result) : Result(std::move(Result)) {}
|
2014-03-08 08:27:28 +00:00
|
|
|
AnalysisResultModel *clone() override {
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
return new AnalysisResultModel(Result);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief The model delegates to the \c ResultT method.
|
2014-03-08 08:27:28 +00:00
|
|
|
bool invalidate(IRUnitT IR, const PreservedAnalyses &PA) override {
|
2013-11-21 10:53:05 +00:00
|
|
|
return Result.invalidate(IR, PA);
|
|
|
|
}
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
|
|
|
|
ResultT Result;
|
|
|
|
};
|
|
|
|
|
|
|
|
/// \brief Abstract concept of an analysis pass.
|
|
|
|
///
|
|
|
|
/// This concept is parameterized over the IR unit that it can run over and
|
|
|
|
/// produce an analysis result.
|
2013-11-22 12:11:02 +00:00
|
|
|
template <typename IRUnitT, typename AnalysisManagerT>
|
|
|
|
struct AnalysisPassConcept {
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
virtual ~AnalysisPassConcept() {}
|
|
|
|
virtual AnalysisPassConcept *clone() = 0;
|
|
|
|
|
|
|
|
/// \brief Method to run this analysis over a unit of IR.
|
|
|
|
/// \returns The analysis result object to be queried by users, the caller
|
|
|
|
/// takes ownership.
|
2013-11-22 12:11:02 +00:00
|
|
|
virtual AnalysisResultConcept<IRUnitT> *run(IRUnitT IR,
|
|
|
|
AnalysisManagerT *AM) = 0;
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/// \brief Wrapper to model the analysis pass concept.
|
|
|
|
///
|
|
|
|
/// Can wrap any type which implements a suitable \c run method. The method
|
|
|
|
/// must accept the IRUnitT as an argument and produce an object which can be
|
|
|
|
/// wrapped in a \c AnalysisResultModel.
|
2013-11-22 12:11:02 +00:00
|
|
|
template <typename IRUnitT, typename AnalysisManagerT, typename PassT,
|
|
|
|
bool AcceptsAnalysisManager = PassRunAcceptsAnalysisManager<
|
|
|
|
IRUnitT, AnalysisManagerT, PassT,
|
2013-11-22 12:26:40 +00:00
|
|
|
typename PassT::Result>::Value> struct AnalysisPassModel;
|
2013-11-22 12:11:02 +00:00
|
|
|
|
|
|
|
/// \brief Specialization of \c AnalysisPassModel which passes an
|
|
|
|
/// \c AnalysisManager to PassT's run method.
|
|
|
|
template <typename IRUnitT, typename AnalysisManagerT, typename PassT>
|
|
|
|
struct AnalysisPassModel<IRUnitT, AnalysisManagerT, PassT,
|
|
|
|
true> : AnalysisPassConcept<IRUnitT,
|
|
|
|
AnalysisManagerT> {
|
2014-03-02 04:08:41 +00:00
|
|
|
AnalysisPassModel(PassT Pass) : Pass(std::move(Pass)) {}
|
2013-11-22 12:11:02 +00:00
|
|
|
virtual AnalysisPassModel *clone() { return new AnalysisPassModel(Pass); }
|
|
|
|
|
|
|
|
// FIXME: Replace PassT::Result with type traits when we use C++11.
|
|
|
|
typedef AnalysisResultModel<IRUnitT, PassT, typename PassT::Result>
|
|
|
|
ResultModelT;
|
|
|
|
|
|
|
|
/// \brief The model delegates to the \c PassT::run method.
|
|
|
|
///
|
|
|
|
/// The return is wrapped in an \c AnalysisResultModel.
|
|
|
|
virtual ResultModelT *run(IRUnitT IR, AnalysisManagerT *AM) {
|
|
|
|
return new ResultModelT(Pass.run(IR, AM));
|
|
|
|
}
|
|
|
|
|
|
|
|
PassT Pass;
|
|
|
|
};
|
|
|
|
|
|
|
|
/// \brief Specialization of \c AnalysisPassModel which does not pass an
|
|
|
|
/// \c AnalysisManager to PassT's run method.
|
|
|
|
template <typename IRUnitT, typename AnalysisManagerT, typename PassT>
|
|
|
|
struct AnalysisPassModel<IRUnitT, AnalysisManagerT, PassT,
|
|
|
|
false> : AnalysisPassConcept<IRUnitT,
|
|
|
|
AnalysisManagerT> {
|
2014-03-02 04:08:41 +00:00
|
|
|
AnalysisPassModel(PassT Pass) : Pass(std::move(Pass)) {}
|
2014-03-08 08:27:28 +00:00
|
|
|
AnalysisPassModel *clone() override { return new AnalysisPassModel(Pass); }
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
|
|
|
|
// FIXME: Replace PassT::Result with type traits when we use C++11.
|
2013-11-22 00:48:49 +00:00
|
|
|
typedef AnalysisResultModel<IRUnitT, PassT, typename PassT::Result>
|
|
|
|
ResultModelT;
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
|
|
|
|
/// \brief The model delegates to the \c PassT::run method.
|
|
|
|
///
|
|
|
|
/// The return is wrapped in an \c AnalysisResultModel.
|
2014-03-08 08:27:28 +00:00
|
|
|
ResultModelT *run(IRUnitT IR, AnalysisManagerT *) override {
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
return new ResultModelT(Pass.run(IR));
|
|
|
|
}
|
|
|
|
|
|
|
|
PassT Pass;
|
|
|
|
};
|
|
|
|
|
2013-11-09 13:09:08 +00:00
|
|
|
}
|
|
|
|
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
class ModuleAnalysisManager;
|
2013-11-13 01:12:08 +00:00
|
|
|
|
2013-11-09 13:09:08 +00:00
|
|
|
class ModulePassManager {
|
|
|
|
public:
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
explicit ModulePassManager() {}
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
|
|
|
|
/// \brief Run all of the module passes in this module pass manager over
|
|
|
|
/// a module.
|
|
|
|
///
|
|
|
|
/// This method should only be called for a single module as there is the
|
|
|
|
/// expectation that the lifetime of a pass is bounded to that of a module.
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
PreservedAnalyses run(Module *M, ModuleAnalysisManager *AM = 0);
|
2013-11-09 13:09:08 +00:00
|
|
|
|
|
|
|
template <typename ModulePassT> void addPass(ModulePassT Pass) {
|
2014-03-02 04:08:41 +00:00
|
|
|
Passes.push_back(new ModulePassModel<ModulePassT>(std::move(Pass)));
|
2013-11-09 13:09:08 +00:00
|
|
|
}
|
|
|
|
|
2014-01-11 11:52:05 +00:00
|
|
|
static StringRef name() { return "ModulePassManager"; }
|
|
|
|
|
2013-11-09 13:09:08 +00:00
|
|
|
private:
|
|
|
|
// Pull in the concept type and model template specialized for modules.
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
typedef detail::PassConcept<Module *, ModuleAnalysisManager> ModulePassConcept;
|
2013-11-09 13:09:08 +00:00
|
|
|
template <typename PassT>
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
struct ModulePassModel
|
2013-11-22 11:55:38 +00:00
|
|
|
: detail::PassModel<Module *, ModuleAnalysisManager, PassT> {
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
ModulePassModel(PassT Pass)
|
2013-11-22 11:55:38 +00:00
|
|
|
: detail::PassModel<Module *, ModuleAnalysisManager, PassT>(Pass) {}
|
2013-11-09 13:09:08 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
std::vector<polymorphic_ptr<ModulePassConcept> > Passes;
|
|
|
|
};
|
|
|
|
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
class FunctionAnalysisManager;
|
|
|
|
|
2013-11-09 13:09:08 +00:00
|
|
|
class FunctionPassManager {
|
|
|
|
public:
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
explicit FunctionPassManager() {}
|
2013-11-13 01:12:08 +00:00
|
|
|
|
2013-11-09 13:09:08 +00:00
|
|
|
template <typename FunctionPassT> void addPass(FunctionPassT Pass) {
|
2014-03-02 04:08:41 +00:00
|
|
|
Passes.push_back(new FunctionPassModel<FunctionPassT>(std::move(Pass)));
|
2013-11-09 13:09:08 +00:00
|
|
|
}
|
|
|
|
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
PreservedAnalyses run(Function *F, FunctionAnalysisManager *AM = 0);
|
2013-11-09 13:09:08 +00:00
|
|
|
|
2014-01-11 11:52:05 +00:00
|
|
|
static StringRef name() { return "FunctionPassManager"; }
|
|
|
|
|
2013-11-09 13:09:08 +00:00
|
|
|
private:
|
|
|
|
// Pull in the concept type and model template specialized for functions.
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
typedef detail::PassConcept<Function *, FunctionAnalysisManager>
|
|
|
|
FunctionPassConcept;
|
2013-11-09 13:09:08 +00:00
|
|
|
template <typename PassT>
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
struct FunctionPassModel
|
2013-11-22 11:55:38 +00:00
|
|
|
: detail::PassModel<Function *, FunctionAnalysisManager, PassT> {
|
2013-11-09 13:09:08 +00:00
|
|
|
FunctionPassModel(PassT Pass)
|
2013-11-22 11:55:38 +00:00
|
|
|
: detail::PassModel<Function *, FunctionAnalysisManager, PassT>(Pass) {}
|
2013-11-09 13:09:08 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
std::vector<polymorphic_ptr<FunctionPassConcept> > Passes;
|
|
|
|
};
|
|
|
|
|
2013-11-26 11:24:37 +00:00
|
|
|
namespace detail {
|
|
|
|
|
|
|
|
/// \brief A CRTP base used to implement analysis managers.
|
|
|
|
///
|
|
|
|
/// This class template serves as the boiler plate of an analysis manager. Any
|
|
|
|
/// analysis manager can be implemented on top of this base class. Any
|
|
|
|
/// implementation will be required to provide specific hooks:
|
|
|
|
///
|
|
|
|
/// - getResultImpl
|
|
|
|
/// - getCachedResultImpl
|
|
|
|
/// - invalidateImpl
|
|
|
|
///
|
|
|
|
/// The details of the call pattern are within.
|
|
|
|
template <typename DerivedT, typename IRUnitT>
|
|
|
|
class AnalysisManagerBase {
|
|
|
|
DerivedT *derived_this() { return static_cast<DerivedT *>(this); }
|
|
|
|
const DerivedT *derived_this() const { return static_cast<const DerivedT *>(this); }
|
|
|
|
|
|
|
|
protected:
|
|
|
|
typedef detail::AnalysisResultConcept<IRUnitT> ResultConceptT;
|
|
|
|
typedef detail::AnalysisPassConcept<IRUnitT, DerivedT> PassConceptT;
|
2013-11-13 01:12:08 +00:00
|
|
|
|
2013-11-26 11:24:37 +00:00
|
|
|
// FIXME: Provide template aliases for the models when we're using C++11 in
|
|
|
|
// a mode supporting them.
|
|
|
|
|
|
|
|
public:
|
2013-11-13 01:12:08 +00:00
|
|
|
/// \brief Get the result of an analysis pass for this module.
|
|
|
|
///
|
|
|
|
/// If there is not a valid cached result in the manager already, this will
|
|
|
|
/// re-run the analysis to produce a valid result.
|
2014-02-05 21:41:42 +00:00
|
|
|
template <typename PassT> typename PassT::Result &getResult(IRUnitT IR) {
|
2013-11-26 11:24:37 +00:00
|
|
|
assert(AnalysisPasses.count(PassT::ID()) &&
|
2013-11-17 03:18:05 +00:00
|
|
|
"This analysis pass was not registered prior to being queried");
|
|
|
|
|
2014-02-05 21:41:42 +00:00
|
|
|
ResultConceptT &ResultConcept =
|
2013-11-26 11:24:37 +00:00
|
|
|
derived_this()->getResultImpl(PassT::ID(), IR);
|
|
|
|
typedef detail::AnalysisResultModel<IRUnitT, PassT, typename PassT::Result>
|
2013-11-22 00:48:49 +00:00
|
|
|
ResultModelT;
|
2014-02-05 21:41:42 +00:00
|
|
|
return static_cast<ResultModelT &>(ResultConcept).Result;
|
2013-11-13 01:12:08 +00:00
|
|
|
}
|
|
|
|
|
2013-11-23 00:38:42 +00:00
|
|
|
/// \brief Get the cached result of an analysis pass for this module.
|
|
|
|
///
|
|
|
|
/// This method never runs the analysis.
|
|
|
|
///
|
|
|
|
/// \returns null if there is no cached result.
|
|
|
|
template <typename PassT>
|
2014-02-05 21:41:42 +00:00
|
|
|
typename PassT::Result *getCachedResult(IRUnitT IR) const {
|
2013-11-26 11:24:37 +00:00
|
|
|
assert(AnalysisPasses.count(PassT::ID()) &&
|
2013-11-23 00:38:42 +00:00
|
|
|
"This analysis pass was not registered prior to being queried");
|
|
|
|
|
2014-02-05 21:41:42 +00:00
|
|
|
ResultConceptT *ResultConcept =
|
2013-11-26 11:24:37 +00:00
|
|
|
derived_this()->getCachedResultImpl(PassT::ID(), IR);
|
2013-11-23 00:38:42 +00:00
|
|
|
if (!ResultConcept)
|
|
|
|
return 0;
|
|
|
|
|
2013-11-26 11:24:37 +00:00
|
|
|
typedef detail::AnalysisResultModel<IRUnitT, PassT, typename PassT::Result>
|
2013-11-23 00:38:42 +00:00
|
|
|
ResultModelT;
|
2014-02-05 21:41:42 +00:00
|
|
|
return &static_cast<ResultModelT *>(ResultConcept)->Result;
|
2013-11-23 00:38:42 +00:00
|
|
|
}
|
|
|
|
|
2013-11-13 01:12:08 +00:00
|
|
|
/// \brief Register an analysis pass with the manager.
|
|
|
|
///
|
2013-11-26 11:24:37 +00:00
|
|
|
/// This provides an initialized and set-up analysis pass to the analysis
|
|
|
|
/// manager. Whomever is setting up analysis passes must use this to populate
|
2013-11-13 01:12:08 +00:00
|
|
|
/// the manager with all of the analysis passes available.
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
template <typename PassT> void registerPass(PassT Pass) {
|
2013-11-26 11:24:37 +00:00
|
|
|
assert(!AnalysisPasses.count(PassT::ID()) &&
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
"Registered the same analysis pass twice!");
|
2013-11-26 11:24:37 +00:00
|
|
|
typedef detail::AnalysisPassModel<IRUnitT, DerivedT, PassT> PassModelT;
|
2014-03-02 04:08:41 +00:00
|
|
|
AnalysisPasses[PassT::ID()] = new PassModelT(std::move(Pass));
|
2013-11-13 01:12:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Invalidate a specific analysis pass for an IR module.
|
|
|
|
///
|
|
|
|
/// Note that the analysis result can disregard invalidation.
|
|
|
|
template <typename PassT> void invalidate(Module *M) {
|
2013-11-26 11:24:37 +00:00
|
|
|
assert(AnalysisPasses.count(PassT::ID()) &&
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
"This analysis pass was not registered prior to being invalidated");
|
2013-11-26 11:24:37 +00:00
|
|
|
derived_this()->invalidateImpl(PassT::ID(), M);
|
2013-11-13 01:12:08 +00:00
|
|
|
}
|
|
|
|
|
2013-11-26 11:24:37 +00:00
|
|
|
/// \brief Invalidate analyses cached for an IR unit.
|
2013-11-13 01:12:08 +00:00
|
|
|
///
|
2013-11-26 12:00:58 +00:00
|
|
|
/// Walk through all of the analyses pertaining to this unit of IR and
|
|
|
|
/// invalidate them unless they are preserved by the PreservedAnalyses set.
|
2013-11-26 11:24:37 +00:00
|
|
|
void invalidate(IRUnitT IR, const PreservedAnalyses &PA) {
|
|
|
|
derived_this()->invalidateImpl(IR, PA);
|
|
|
|
}
|
|
|
|
|
|
|
|
protected:
|
|
|
|
/// \brief Lookup a registered analysis pass.
|
|
|
|
PassConceptT &lookupPass(void *PassID) {
|
|
|
|
typename AnalysisPassMapT::iterator PI = AnalysisPasses.find(PassID);
|
|
|
|
assert(PI != AnalysisPasses.end() &&
|
|
|
|
"Analysis passes must be registered prior to being queried!");
|
|
|
|
return *PI->second;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Lookup a registered analysis pass.
|
|
|
|
const PassConceptT &lookupPass(void *PassID) const {
|
|
|
|
typename AnalysisPassMapT::const_iterator PI = AnalysisPasses.find(PassID);
|
|
|
|
assert(PI != AnalysisPasses.end() &&
|
|
|
|
"Analysis passes must be registered prior to being queried!");
|
|
|
|
return *PI->second;
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
/// \brief Map type from module analysis pass ID to pass concept pointer.
|
|
|
|
typedef DenseMap<void *, polymorphic_ptr<PassConceptT> > AnalysisPassMapT;
|
|
|
|
|
|
|
|
/// \brief Collection of module analysis passes, indexed by ID.
|
|
|
|
AnalysisPassMapT AnalysisPasses;
|
|
|
|
};
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief A module analysis pass manager with lazy running and caching of
|
|
|
|
/// results.
|
|
|
|
class ModuleAnalysisManager
|
|
|
|
: public detail::AnalysisManagerBase<ModuleAnalysisManager, Module *> {
|
|
|
|
friend class detail::AnalysisManagerBase<ModuleAnalysisManager, Module *>;
|
|
|
|
typedef detail::AnalysisManagerBase<ModuleAnalysisManager, Module *> BaseT;
|
2013-11-26 11:31:06 +00:00
|
|
|
typedef BaseT::ResultConceptT ResultConceptT;
|
|
|
|
typedef BaseT::PassConceptT PassConceptT;
|
2013-11-26 11:24:37 +00:00
|
|
|
|
|
|
|
public:
|
|
|
|
// Public methods provided by the base class.
|
2013-11-13 01:12:08 +00:00
|
|
|
|
|
|
|
private:
|
|
|
|
/// \brief Get a module pass result, running the pass if necessary.
|
2014-02-05 21:41:42 +00:00
|
|
|
ResultConceptT &getResultImpl(void *PassID, Module *M);
|
2013-11-13 01:12:08 +00:00
|
|
|
|
2013-11-23 00:38:42 +00:00
|
|
|
/// \brief Get a cached module pass result or return null.
|
2014-02-05 21:41:42 +00:00
|
|
|
ResultConceptT *getCachedResultImpl(void *PassID, Module *M) const;
|
2013-11-23 00:38:42 +00:00
|
|
|
|
2013-11-13 01:12:08 +00:00
|
|
|
/// \brief Invalidate a module pass result.
|
|
|
|
void invalidateImpl(void *PassID, Module *M);
|
|
|
|
|
2013-11-26 11:24:37 +00:00
|
|
|
/// \brief Invalidate results across a module.
|
|
|
|
void invalidateImpl(Module *M, const PreservedAnalyses &PA);
|
2013-11-13 01:12:08 +00:00
|
|
|
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
/// \brief Map type from module analysis pass ID to pass result concept pointer.
|
|
|
|
typedef DenseMap<void *,
|
2013-11-22 11:34:43 +00:00
|
|
|
polymorphic_ptr<detail::AnalysisResultConcept<Module *> > >
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
ModuleAnalysisResultMapT;
|
|
|
|
|
|
|
|
/// \brief Cache of computed module analysis results for this module.
|
|
|
|
ModuleAnalysisResultMapT ModuleAnalysisResults;
|
|
|
|
};
|
2013-11-13 01:12:08 +00:00
|
|
|
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
/// \brief A function analysis manager to coordinate and cache analyses run over
|
|
|
|
/// a module.
|
2013-11-26 11:24:37 +00:00
|
|
|
class FunctionAnalysisManager
|
|
|
|
: public detail::AnalysisManagerBase<FunctionAnalysisManager, Function *> {
|
|
|
|
friend class detail::AnalysisManagerBase<FunctionAnalysisManager, Function *>;
|
|
|
|
typedef detail::AnalysisManagerBase<FunctionAnalysisManager, Function *> BaseT;
|
2013-11-26 11:31:06 +00:00
|
|
|
typedef BaseT::ResultConceptT ResultConceptT;
|
|
|
|
typedef BaseT::PassConceptT PassConceptT;
|
2013-11-23 00:38:42 +00:00
|
|
|
|
2013-11-26 11:24:37 +00:00
|
|
|
public:
|
|
|
|
// Most public APIs are inherited from the CRTP base class.
|
2013-11-13 01:12:08 +00:00
|
|
|
|
2013-11-21 02:11:31 +00:00
|
|
|
/// \brief Returns true if the analysis manager has an empty results cache.
|
|
|
|
bool empty() const;
|
|
|
|
|
|
|
|
/// \brief Clear the function analysis result cache.
|
|
|
|
///
|
|
|
|
/// This routine allows cleaning up when the set of functions itself has
|
|
|
|
/// potentially changed, and thus we can't even look up a a result and
|
|
|
|
/// invalidate it directly. Notably, this does *not* call invalidate
|
|
|
|
/// functions as there is nothing to be done for them.
|
|
|
|
void clear();
|
|
|
|
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
private:
|
|
|
|
/// \brief Get a function pass result, running the pass if necessary.
|
2014-02-05 21:41:42 +00:00
|
|
|
ResultConceptT &getResultImpl(void *PassID, Function *F);
|
2013-11-13 01:12:08 +00:00
|
|
|
|
2013-11-23 00:38:42 +00:00
|
|
|
/// \brief Get a cached function pass result or return null.
|
2014-02-05 21:41:42 +00:00
|
|
|
ResultConceptT *getCachedResultImpl(void *PassID, Function *F) const;
|
2013-11-23 00:38:42 +00:00
|
|
|
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
/// \brief Invalidate a function pass result.
|
|
|
|
void invalidateImpl(void *PassID, Function *F);
|
2013-11-13 01:12:08 +00:00
|
|
|
|
2013-11-26 11:24:37 +00:00
|
|
|
/// \brief Invalidate the results for a function..
|
|
|
|
void invalidateImpl(Function *F, const PreservedAnalyses &PA);
|
2013-11-13 01:12:08 +00:00
|
|
|
|
|
|
|
/// \brief List of function analysis pass IDs and associated concept pointers.
|
|
|
|
///
|
|
|
|
/// Requires iterators to be valid across appending new entries and arbitrary
|
|
|
|
/// erases. Provides both the pass ID and concept pointer such that it is
|
|
|
|
/// half of a bijection and provides storage for the actual result concept.
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
typedef std::list<std::pair<
|
2013-11-22 11:34:43 +00:00
|
|
|
void *, polymorphic_ptr<detail::AnalysisResultConcept<Function *> > > >
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
FunctionAnalysisResultListT;
|
2013-11-13 01:12:08 +00:00
|
|
|
|
|
|
|
/// \brief Map type from function pointer to our custom list type.
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
typedef DenseMap<Function *, FunctionAnalysisResultListT>
|
|
|
|
FunctionAnalysisResultListMapT;
|
2013-11-13 01:12:08 +00:00
|
|
|
|
|
|
|
/// \brief Map from function to a list of function analysis results.
|
|
|
|
///
|
|
|
|
/// Provides linear time removal of all analysis results for a function and
|
|
|
|
/// the ultimate storage for a particular cached analysis result.
|
|
|
|
FunctionAnalysisResultListMapT FunctionAnalysisResultLists;
|
|
|
|
|
|
|
|
/// \brief Map type from a pair of analysis ID and function pointer to an
|
|
|
|
/// iterator into a particular result list.
|
|
|
|
typedef DenseMap<std::pair<void *, Function *>,
|
|
|
|
FunctionAnalysisResultListT::iterator>
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195189 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-20 04:01:38 +00:00
|
|
|
FunctionAnalysisResultMapT;
|
2013-11-13 01:12:08 +00:00
|
|
|
|
|
|
|
/// \brief Map from an analysis ID and function to a particular cached
|
|
|
|
/// analysis result.
|
|
|
|
FunctionAnalysisResultMapT FunctionAnalysisResults;
|
|
|
|
};
|
|
|
|
|
2013-11-21 02:11:31 +00:00
|
|
|
/// \brief A module analysis which acts as a proxy for a function analysis
|
|
|
|
/// manager.
|
|
|
|
///
|
|
|
|
/// This primarily proxies invalidation information from the module analysis
|
|
|
|
/// manager and module pass manager to a function analysis manager. You should
|
|
|
|
/// never use a function analysis manager from within (transitively) a module
|
|
|
|
/// pass manager unless your parent module pass has received a proxy result
|
|
|
|
/// object for it.
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
class FunctionAnalysisManagerModuleProxy {
|
2013-11-21 02:11:31 +00:00
|
|
|
public:
|
|
|
|
class Result;
|
|
|
|
|
|
|
|
static void *ID() { return (void *)&PassID; }
|
|
|
|
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
FunctionAnalysisManagerModuleProxy(FunctionAnalysisManager &FAM) : FAM(FAM) {}
|
2013-11-21 02:11:31 +00:00
|
|
|
|
|
|
|
/// \brief Run the analysis pass and create our proxy result object.
|
|
|
|
///
|
|
|
|
/// This doesn't do any interesting work, it is primarily used to insert our
|
|
|
|
/// proxy result object into the module analysis cache so that we can proxy
|
|
|
|
/// invalidation to the function analysis manager.
|
|
|
|
///
|
|
|
|
/// In debug builds, it will also assert that the analysis manager is empty
|
|
|
|
/// as no queries should arrive at the function analysis manager prior to
|
|
|
|
/// this analysis being requested.
|
|
|
|
Result run(Module *M);
|
|
|
|
|
|
|
|
private:
|
|
|
|
static char PassID;
|
|
|
|
|
|
|
|
FunctionAnalysisManager &FAM;
|
|
|
|
};
|
|
|
|
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
/// \brief The result proxy object for the
|
|
|
|
/// \c FunctionAnalysisManagerModuleProxy.
|
2013-11-21 02:11:31 +00:00
|
|
|
///
|
|
|
|
/// See its documentation for more information.
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
class FunctionAnalysisManagerModuleProxy::Result {
|
2013-11-21 02:11:31 +00:00
|
|
|
public:
|
|
|
|
Result(FunctionAnalysisManager &FAM) : FAM(FAM) {}
|
|
|
|
~Result();
|
|
|
|
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
/// \brief Accessor for the \c FunctionAnalysisManager.
|
2014-02-05 21:41:42 +00:00
|
|
|
FunctionAnalysisManager &getManager() { return FAM; }
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
|
2013-11-21 02:11:31 +00:00
|
|
|
/// \brief Handler for invalidation of the module.
|
2013-11-21 10:53:05 +00:00
|
|
|
///
|
|
|
|
/// If this analysis itself is preserved, then we assume that the set of \c
|
|
|
|
/// Function objects in the \c Module hasn't changed and thus we don't need
|
|
|
|
/// to invalidate *all* cached data associated with a \c Function* in the \c
|
|
|
|
/// FunctionAnalysisManager.
|
|
|
|
///
|
|
|
|
/// Regardless of whether this analysis is marked as preserved, all of the
|
|
|
|
/// analyses in the \c FunctionAnalysisManager are potentially invalidated
|
|
|
|
/// based on the set of preserved analyses.
|
|
|
|
bool invalidate(Module *M, const PreservedAnalyses &PA);
|
2013-11-21 02:11:31 +00:00
|
|
|
|
|
|
|
private:
|
|
|
|
FunctionAnalysisManager &FAM;
|
|
|
|
};
|
|
|
|
|
2013-11-23 01:25:07 +00:00
|
|
|
/// \brief A function analysis which acts as a proxy for a module analysis
|
|
|
|
/// manager.
|
|
|
|
///
|
|
|
|
/// This primarily provides an accessor to a parent module analysis manager to
|
|
|
|
/// function passes. Only the const interface of the module analysis manager is
|
|
|
|
/// provided to indicate that once inside of a function analysis pass you
|
|
|
|
/// cannot request a module analysis to actually run. Instead, the user must
|
|
|
|
/// rely on the \c getCachedResult API.
|
|
|
|
///
|
|
|
|
/// This proxy *doesn't* manage the invalidation in any way. That is handled by
|
|
|
|
/// the recursive return path of each layer of the pass manager and the
|
|
|
|
/// returned PreservedAnalysis set.
|
|
|
|
class ModuleAnalysisManagerFunctionProxy {
|
|
|
|
public:
|
|
|
|
/// \brief Result proxy object for \c ModuleAnalysisManagerFunctionProxy.
|
|
|
|
class Result {
|
|
|
|
public:
|
|
|
|
Result(const ModuleAnalysisManager &MAM) : MAM(MAM) {}
|
|
|
|
|
|
|
|
const ModuleAnalysisManager &getManager() const { return MAM; }
|
|
|
|
|
|
|
|
/// \brief Handle invalidation by ignoring it, this pass is immutable.
|
|
|
|
bool invalidate(Function *) { return false; }
|
|
|
|
|
|
|
|
private:
|
|
|
|
const ModuleAnalysisManager &MAM;
|
|
|
|
};
|
|
|
|
|
|
|
|
static void *ID() { return (void *)&PassID; }
|
|
|
|
|
|
|
|
ModuleAnalysisManagerFunctionProxy(const ModuleAnalysisManager &MAM)
|
|
|
|
: MAM(MAM) {}
|
|
|
|
|
|
|
|
/// \brief Run the analysis pass and create our proxy result object.
|
|
|
|
/// Nothing to see here, it just forwards the \c MAM reference into the
|
|
|
|
/// result.
|
|
|
|
Result run(Function *) { return Result(MAM); }
|
|
|
|
|
|
|
|
private:
|
|
|
|
static char PassID;
|
|
|
|
|
|
|
|
const ModuleAnalysisManager &MAM;
|
|
|
|
};
|
|
|
|
|
2013-11-21 02:11:31 +00:00
|
|
|
/// \brief Trivial adaptor that maps from a module to its functions.
|
|
|
|
///
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
/// Designed to allow composition of a FunctionPass(Manager) and
|
|
|
|
/// a ModulePassManager. Note that if this pass is constructed with a pointer
|
|
|
|
/// to a \c ModuleAnalysisManager it will run the
|
|
|
|
/// \c FunctionAnalysisManagerModuleProxy analysis prior to running the function
|
|
|
|
/// pass over the module to enable a \c FunctionAnalysisManager to be used
|
|
|
|
/// within this run safely.
|
2013-11-21 02:11:31 +00:00
|
|
|
template <typename FunctionPassT>
|
|
|
|
class ModuleToFunctionPassAdaptor {
|
|
|
|
public:
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
explicit ModuleToFunctionPassAdaptor(FunctionPassT Pass)
|
2014-03-02 04:08:41 +00:00
|
|
|
: Pass(std::move(Pass)) {}
|
2013-11-21 02:11:31 +00:00
|
|
|
|
|
|
|
/// \brief Runs the function pass across every function in the module.
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
PreservedAnalyses run(Module *M, ModuleAnalysisManager *AM) {
|
|
|
|
FunctionAnalysisManager *FAM = 0;
|
|
|
|
if (AM)
|
|
|
|
// Setup the function analysis manager from its proxy.
|
|
|
|
FAM = &AM->getResult<FunctionAnalysisManagerModuleProxy>(M).getManager();
|
2013-11-21 02:11:31 +00:00
|
|
|
|
|
|
|
PreservedAnalyses PA = PreservedAnalyses::all();
|
|
|
|
for (Module::iterator I = M->begin(), E = M->end(); I != E; ++I) {
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
PreservedAnalyses PassPA = Pass.run(I, FAM);
|
2013-11-22 23:38:07 +00:00
|
|
|
|
|
|
|
// 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.
|
|
|
|
if (FAM)
|
|
|
|
FAM->invalidate(I, PassPA);
|
|
|
|
|
|
|
|
// Then intersect the preserved set so that invalidation of module
|
|
|
|
// analyses will eventually occur when the module pass completes.
|
2014-03-02 04:08:41 +00:00
|
|
|
PA.intersect(std::move(PassPA));
|
2013-11-21 02:11:31 +00:00
|
|
|
}
|
2013-11-21 11:04:53 +00:00
|
|
|
|
2013-11-22 23:38:07 +00:00
|
|
|
// By definition we preserve the proxy. This precludes *any* invalidation
|
|
|
|
// of function analyses by the proxy, but that's OK because we've taken
|
|
|
|
// care to invalidate analyses in the function analysis manager
|
|
|
|
// incrementally above.
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
PA.preserve<FunctionAnalysisManagerModuleProxy>();
|
2013-11-21 02:11:31 +00:00
|
|
|
return PA;
|
|
|
|
}
|
|
|
|
|
2014-01-11 11:52:05 +00:00
|
|
|
static StringRef name() { return "ModuleToFunctionPassAdaptor"; }
|
|
|
|
|
2013-11-21 02:11:31 +00:00
|
|
|
private:
|
|
|
|
FunctionPassT Pass;
|
|
|
|
};
|
|
|
|
|
|
|
|
/// \brief A function to deduce a function pass type and wrap it in the
|
|
|
|
/// templated adaptor.
|
|
|
|
template <typename FunctionPassT>
|
|
|
|
ModuleToFunctionPassAdaptor<FunctionPassT>
|
[PM] Switch analysis managers to be threaded through the run methods
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195400 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 00:43:29 +00:00
|
|
|
createModuleToFunctionPassAdaptor(FunctionPassT Pass) {
|
2014-03-02 04:08:41 +00:00
|
|
|
return ModuleToFunctionPassAdaptor<FunctionPassT>(std::move(Pass));
|
2013-11-21 02:11:31 +00:00
|
|
|
}
|
|
|
|
|
2013-11-09 13:09:08 +00:00
|
|
|
}
|
2014-01-11 10:59:00 +00:00
|
|
|
|
|
|
|
#endif
|