2013-11-14 11:55:14 +01:00
|
|
|
//===- PassManager.h - Pass management infrastructure -----------*- C++ -*-===//
|
2013-11-09 14:09:08 +01: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 02:51:36 +01: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 03:49:38 +01:00
|
|
|
/// * http://www.youtube.com/watch?v=_BpMYeUFXv8
|
2013-11-13 02:51:36 +01:00
|
|
|
/// * http://channel9.msdn.com/Events/GoingNative/2013/Inheritance-Is-The-Base-Class-of-Evil
|
|
|
|
///
|
2013-11-09 14:09:08 +01:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2013-11-13 02:12:08 +01:00
|
|
|
#include "llvm/ADT/DenseMap.h"
|
2013-11-20 12:31:50 +01:00
|
|
|
#include "llvm/ADT/SmallPtrSet.h"
|
2013-11-09 14:09:08 +01:00
|
|
|
#include "llvm/ADT/polymorphic_ptr.h"
|
2013-11-13 02:12:08 +01:00
|
|
|
#include "llvm/Support/type_traits.h"
|
|
|
|
#include "llvm/IR/Function.h"
|
2013-11-09 14:09:08 +01:00
|
|
|
#include "llvm/IR/Module.h"
|
2013-11-13 02:12:08 +01:00
|
|
|
#include <list>
|
2013-11-09 14:09:08 +01:00
|
|
|
#include <vector>
|
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
|
|
|
|
class Module;
|
|
|
|
class Function;
|
|
|
|
|
2013-11-20 12:31:50 +01: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);
|
|
|
|
}
|
|
|
|
|
|
|
|
#if LLVM_HAS_RVALUE_REFERENCES
|
|
|
|
/// \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);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/// \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 14:09:08 +01: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.
|
|
|
|
template <typename T> struct PassConcept {
|
|
|
|
// 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.
|
2013-11-20 12:31:50 +01:00
|
|
|
virtual PreservedAnalyses run(T Arg) = 0;
|
2013-11-09 14:09:08 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
/// \brief A template wrapper used to implement the polymorphic API.
|
|
|
|
///
|
|
|
|
/// Can be instantiated for any object which provides a \c run method
|
|
|
|
/// accepting a \c T. It requires the pass to be a copyable
|
|
|
|
/// object.
|
|
|
|
template <typename T, typename PassT> struct PassModel : PassConcept<T> {
|
|
|
|
PassModel(PassT Pass) : Pass(llvm_move(Pass)) {}
|
|
|
|
virtual PassModel *clone() { return new PassModel(Pass); }
|
2013-11-20 12:31:50 +01:00
|
|
|
virtual PreservedAnalyses run(T Arg) { return Pass.run(Arg); }
|
2013-11-09 14:09:08 +01: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.
llvm-svn: 195189
2013-11-20 05:01:38 +01: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.
|
|
|
|
///
|
|
|
|
/// When the outer \c AnalysisManager detects a change in some underlying
|
|
|
|
/// unit of the IR, it will call this method on all of the results cached.
|
|
|
|
///
|
|
|
|
/// \returns true if the result should indeed be invalidated (the default).
|
|
|
|
virtual bool invalidate(IRUnitT *IR) = 0;
|
|
|
|
};
|
|
|
|
|
|
|
|
/// \brief Wrapper to model the analysis result concept.
|
|
|
|
///
|
|
|
|
/// Can wrap any type which implements a suitable invalidate member and model
|
|
|
|
/// the AnalysisResultConcept for the AnalysisManager.
|
|
|
|
template <typename IRUnitT, typename ResultT>
|
|
|
|
struct AnalysisResultModel : AnalysisResultConcept<IRUnitT> {
|
|
|
|
AnalysisResultModel(ResultT Result) : Result(llvm_move(Result)) {}
|
|
|
|
virtual AnalysisResultModel *clone() {
|
|
|
|
return new AnalysisResultModel(Result);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief The model delegates to the \c ResultT method.
|
|
|
|
virtual bool invalidate(IRUnitT *IR) { return Result.invalidate(IR); }
|
|
|
|
|
|
|
|
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.
|
|
|
|
template <typename IRUnitT> struct AnalysisPassConcept {
|
|
|
|
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.
|
|
|
|
virtual AnalysisResultConcept<IRUnitT> *run(IRUnitT *IR) = 0;
|
|
|
|
};
|
|
|
|
|
|
|
|
/// \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.
|
|
|
|
template <typename PassT>
|
|
|
|
struct AnalysisPassModel : AnalysisPassConcept<typename PassT::IRUnitT> {
|
|
|
|
AnalysisPassModel(PassT Pass) : Pass(llvm_move(Pass)) {}
|
|
|
|
virtual AnalysisPassModel *clone() { return new AnalysisPassModel(Pass); }
|
|
|
|
|
|
|
|
// FIXME: Replace PassT::IRUnitT with type traits when we use C++11.
|
|
|
|
typedef typename PassT::IRUnitT IRUnitT;
|
|
|
|
|
|
|
|
// FIXME: Replace PassT::Result with type traits when we use C++11.
|
|
|
|
typedef AnalysisResultModel<IRUnitT, 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) {
|
|
|
|
return new ResultModelT(Pass.run(IR));
|
|
|
|
}
|
|
|
|
|
|
|
|
PassT Pass;
|
|
|
|
};
|
|
|
|
|
2013-11-09 14:09:08 +01: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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
class ModuleAnalysisManager;
|
2013-11-13 02:12:08 +01:00
|
|
|
|
2013-11-09 14:09:08 +01:00
|
|
|
class ModulePassManager {
|
|
|
|
public:
|
[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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
explicit ModulePassManager(ModuleAnalysisManager *AM = 0) : AM(AM) {}
|
|
|
|
|
|
|
|
/// \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.
|
2013-11-20 12:31:50 +01:00
|
|
|
PreservedAnalyses run(Module *M);
|
2013-11-09 14:09:08 +01:00
|
|
|
|
|
|
|
template <typename ModulePassT> void addPass(ModulePassT Pass) {
|
|
|
|
Passes.push_back(new ModulePassModel<ModulePassT>(llvm_move(Pass)));
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
// Pull in the concept type and model template specialized for modules.
|
|
|
|
typedef detail::PassConcept<Module *> ModulePassConcept;
|
|
|
|
template <typename PassT>
|
|
|
|
struct ModulePassModel : detail::PassModel<Module *, PassT> {
|
|
|
|
ModulePassModel(PassT Pass) : detail::PassModel<Module *, 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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
ModuleAnalysisManager *AM;
|
2013-11-09 14:09:08 +01: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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
class FunctionAnalysisManager;
|
|
|
|
|
2013-11-09 14:09:08 +01:00
|
|
|
class FunctionPassManager {
|
|
|
|
public:
|
[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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
explicit FunctionPassManager(FunctionAnalysisManager *AM = 0) : AM(AM) {}
|
2013-11-13 02:12:08 +01:00
|
|
|
|
2013-11-09 14:09:08 +01:00
|
|
|
template <typename FunctionPassT> void addPass(FunctionPassT Pass) {
|
|
|
|
Passes.push_back(new FunctionPassModel<FunctionPassT>(llvm_move(Pass)));
|
|
|
|
}
|
|
|
|
|
2013-11-20 12:31:50 +01:00
|
|
|
PreservedAnalyses run(Function *F);
|
2013-11-09 14:09:08 +01:00
|
|
|
|
|
|
|
private:
|
|
|
|
// Pull in the concept type and model template specialized for functions.
|
|
|
|
typedef detail::PassConcept<Function *> FunctionPassConcept;
|
|
|
|
template <typename PassT>
|
|
|
|
struct FunctionPassModel : detail::PassModel<Function *, PassT> {
|
|
|
|
FunctionPassModel(PassT Pass)
|
|
|
|
: detail::PassModel<Function *, 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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
FunctionAnalysisManager *AM;
|
2013-11-09 14:09:08 +01:00
|
|
|
std::vector<polymorphic_ptr<FunctionPassConcept> > Passes;
|
|
|
|
};
|
|
|
|
|
2013-11-20 05:39:16 +01:00
|
|
|
/// \brief Trivial adaptor that maps from a module to its functions.
|
|
|
|
///
|
|
|
|
/// Designed to allow composition of a FunctionPass(Manager) and a
|
|
|
|
/// ModulePassManager.
|
|
|
|
template <typename FunctionPassT>
|
|
|
|
class ModuleToFunctionPassAdaptor {
|
|
|
|
public:
|
|
|
|
explicit ModuleToFunctionPassAdaptor(FunctionPassT Pass)
|
|
|
|
: Pass(llvm_move(Pass)) {}
|
|
|
|
|
|
|
|
/// \brief Runs the function pass across every function in the module.
|
2013-11-20 12:31:50 +01:00
|
|
|
PreservedAnalyses run(Module *M) {
|
|
|
|
PreservedAnalyses PA = PreservedAnalyses::all();
|
|
|
|
for (Module::iterator I = M->begin(), E = M->end(); I != E; ++I) {
|
|
|
|
PreservedAnalyses PassPA = Pass.run(I);
|
|
|
|
PA.intersect(llvm_move(PassPA));
|
|
|
|
}
|
|
|
|
return PA;
|
2013-11-20 05:39:16 +01: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>
|
|
|
|
createModuleToFunctionPassAdaptor(FunctionPassT Pass) {
|
|
|
|
return ModuleToFunctionPassAdaptor<FunctionPassT>(llvm_move(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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
/// \brief A module analysis pass manager with lazy running and caching of
|
|
|
|
/// results.
|
|
|
|
class ModuleAnalysisManager {
|
2013-11-13 02:12:08 +01:00
|
|
|
public:
|
[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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
ModuleAnalysisManager() {}
|
2013-11-13 02:12:08 +01: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.
|
[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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
template <typename PassT> const typename PassT::Result &getResult(Module *M) {
|
|
|
|
LLVM_STATIC_ASSERT((is_same<typename PassT::IRUnitT, Module>::value),
|
|
|
|
"The analysis pass must be over a Module.");
|
2013-11-17 04:18:05 +01:00
|
|
|
assert(ModuleAnalysisPasses.count(PassT::ID()) &&
|
|
|
|
"This analysis pass was not registered prior to being queried");
|
|
|
|
|
[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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
const detail::AnalysisResultConcept<Module> &ResultConcept =
|
2013-11-13 02:12:08 +01:00
|
|
|
getResultImpl(PassT::ID(), M);
|
[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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
typedef detail::AnalysisResultModel<Module, typename PassT::Result>
|
|
|
|
ResultModelT;
|
2013-11-13 02:12:08 +01:00
|
|
|
return static_cast<const ResultModelT &>(ResultConcept).Result;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Register an analysis pass with the manager.
|
|
|
|
///
|
|
|
|
/// This provides an initialized and set-up analysis pass to the
|
|
|
|
/// analysis
|
|
|
|
/// manager. Whomever is setting up analysis passes must use this to
|
|
|
|
/// populate
|
|
|
|
/// 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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
template <typename PassT> void registerPass(PassT Pass) {
|
|
|
|
LLVM_STATIC_ASSERT((is_same<typename PassT::IRUnitT, Module>::value),
|
|
|
|
"The analysis pass must be over a Module.");
|
|
|
|
assert(!ModuleAnalysisPasses.count(PassT::ID()) &&
|
|
|
|
"Registered the same analysis pass twice!");
|
|
|
|
ModuleAnalysisPasses[PassT::ID()] =
|
|
|
|
new detail::AnalysisPassModel<PassT>(llvm_move(Pass));
|
2013-11-13 02:12:08 +01: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) {
|
[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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
LLVM_STATIC_ASSERT((is_same<typename PassT::IRUnitT, Module>::value),
|
|
|
|
"The analysis pass must be over a Module.");
|
|
|
|
assert(ModuleAnalysisPasses.count(PassT::ID()) &&
|
|
|
|
"This analysis pass was not registered prior to being invalidated");
|
2013-11-13 02:12:08 +01:00
|
|
|
invalidateImpl(PassT::ID(), M);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Invalidate analyses cached for an IR Module.
|
|
|
|
///
|
2013-11-20 12:31:50 +01:00
|
|
|
/// Walk through all of the analyses pertaining to this module and invalidate
|
|
|
|
/// them unless they are preserved by the PreservedAnalyses set.
|
|
|
|
void invalidate(Module *M, const PreservedAnalyses &PA);
|
2013-11-13 02:12:08 +01:00
|
|
|
|
|
|
|
private:
|
|
|
|
/// \brief Get a module pass result, running the pass if necessary.
|
[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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
const detail::AnalysisResultConcept<Module> &getResultImpl(void *PassID,
|
|
|
|
Module *M);
|
2013-11-13 02:12:08 +01:00
|
|
|
|
|
|
|
/// \brief Invalidate a module pass result.
|
|
|
|
void invalidateImpl(void *PassID, Module *M);
|
|
|
|
|
[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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
/// \brief Map type from module analysis pass ID to pass concept pointer.
|
|
|
|
typedef DenseMap<void *,
|
|
|
|
polymorphic_ptr<detail::AnalysisPassConcept<Module> > >
|
|
|
|
ModuleAnalysisPassMapT;
|
|
|
|
|
|
|
|
/// \brief Collection of module analysis passes, indexed by ID.
|
|
|
|
ModuleAnalysisPassMapT ModuleAnalysisPasses;
|
2013-11-13 02:12:08 +01: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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
/// \brief Map type from module analysis pass ID to pass result concept pointer.
|
|
|
|
typedef DenseMap<void *,
|
|
|
|
polymorphic_ptr<detail::AnalysisResultConcept<Module> > >
|
|
|
|
ModuleAnalysisResultMapT;
|
|
|
|
|
|
|
|
/// \brief Cache of computed module analysis results for this module.
|
|
|
|
ModuleAnalysisResultMapT ModuleAnalysisResults;
|
|
|
|
};
|
2013-11-13 02:12:08 +01: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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
/// \brief A function analysis manager to coordinate and cache analyses run over
|
|
|
|
/// a module.
|
|
|
|
class FunctionAnalysisManager {
|
|
|
|
public:
|
|
|
|
FunctionAnalysisManager() {}
|
|
|
|
|
|
|
|
/// \brief Get the result of an analysis pass for a function.
|
|
|
|
///
|
|
|
|
/// If there is not a valid cached result in the manager already, this will
|
|
|
|
/// re-run the analysis to produce a valid result.
|
2013-11-13 02:12:08 +01:00
|
|
|
template <typename PassT>
|
[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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
const typename PassT::Result &getResult(Function *F) {
|
|
|
|
LLVM_STATIC_ASSERT((is_same<typename PassT::IRUnitT, Function>::value),
|
|
|
|
"The analysis pass must be over a Function.");
|
|
|
|
assert(FunctionAnalysisPasses.count(PassT::ID()) &&
|
|
|
|
"This analysis pass was not registered prior to being queried");
|
|
|
|
|
|
|
|
const detail::AnalysisResultConcept<Function> &ResultConcept =
|
|
|
|
getResultImpl(PassT::ID(), F);
|
|
|
|
typedef detail::AnalysisResultModel<Function, typename PassT::Result>
|
|
|
|
ResultModelT;
|
|
|
|
return static_cast<const ResultModelT &>(ResultConcept).Result;
|
2013-11-13 02:12:08 +01: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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
/// \brief Register an analysis pass with the manager.
|
|
|
|
///
|
|
|
|
/// This provides an initialized and set-up analysis pass to the
|
|
|
|
/// analysis
|
|
|
|
/// manager. Whomever is setting up analysis passes must use this to
|
|
|
|
/// populate
|
|
|
|
/// the manager with all of the analysis passes available.
|
|
|
|
template <typename PassT> void registerPass(PassT Pass) {
|
|
|
|
LLVM_STATIC_ASSERT((is_same<typename PassT::IRUnitT, Function>::value),
|
|
|
|
"The analysis pass must be over a Function.");
|
2013-11-13 02:12:08 +01:00
|
|
|
assert(!FunctionAnalysisPasses.count(PassT::ID()) &&
|
|
|
|
"Registered the same analysis pass twice!");
|
|
|
|
FunctionAnalysisPasses[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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
new detail::AnalysisPassModel<PassT>(llvm_move(Pass));
|
2013-11-13 02:12:08 +01: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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
/// \brief Invalidate a specific analysis pass for an IR module.
|
|
|
|
///
|
|
|
|
/// Note that the analysis result can disregard invalidation.
|
|
|
|
template <typename PassT> void invalidate(Function *F) {
|
|
|
|
LLVM_STATIC_ASSERT((is_same<typename PassT::IRUnitT, Function>::value),
|
|
|
|
"The analysis pass must be over a Function.");
|
|
|
|
assert(FunctionAnalysisPasses.count(PassT::ID()) &&
|
|
|
|
"This analysis pass was not registered prior to being invalidated");
|
|
|
|
invalidateImpl(PassT::ID(), F);
|
|
|
|
}
|
2013-11-13 02:12:08 +01: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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
/// \brief Invalidate analyses cached for an IR Function.
|
|
|
|
///
|
2013-11-20 12:31:50 +01:00
|
|
|
/// Walk through all of the analyses cache for this IR function and
|
|
|
|
/// invalidate them unless they are preserved by the provided
|
|
|
|
/// PreservedAnalyses set.
|
|
|
|
void invalidate(Function *F, const PreservedAnalyses &PA);
|
2013-11-13 02:12:08 +01: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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
private:
|
|
|
|
/// \brief Get a function pass result, running the pass if necessary.
|
|
|
|
const detail::AnalysisResultConcept<Function> &getResultImpl(void *PassID,
|
|
|
|
Function *F);
|
2013-11-13 02:12:08 +01: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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
/// \brief Invalidate a function pass result.
|
|
|
|
void invalidateImpl(void *PassID, Function *F);
|
2013-11-13 02:12:08 +01:00
|
|
|
|
|
|
|
/// \brief Map type from function analysis pass ID to pass concept pointer.
|
[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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
typedef DenseMap<void *,
|
|
|
|
polymorphic_ptr<detail::AnalysisPassConcept<Function> > >
|
|
|
|
FunctionAnalysisPassMapT;
|
2013-11-13 02:12:08 +01:00
|
|
|
|
|
|
|
/// \brief Collection of function analysis passes, indexed by ID.
|
|
|
|
FunctionAnalysisPassMapT FunctionAnalysisPasses;
|
|
|
|
|
|
|
|
/// \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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
typedef std::list<std::pair<
|
|
|
|
void *, polymorphic_ptr<detail::AnalysisResultConcept<Function> > > >
|
|
|
|
FunctionAnalysisResultListT;
|
2013-11-13 02:12:08 +01: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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
typedef DenseMap<Function *, FunctionAnalysisResultListT>
|
|
|
|
FunctionAnalysisResultListMapT;
|
2013-11-13 02:12:08 +01: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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
FunctionAnalysisResultMapT;
|
2013-11-13 02:12:08 +01:00
|
|
|
|
|
|
|
/// \brief Map from an analysis ID and function to a particular cached
|
|
|
|
/// analysis result.
|
|
|
|
FunctionAnalysisResultMapT FunctionAnalysisResults;
|
|
|
|
};
|
|
|
|
|
2013-11-09 14:09:08 +01:00
|
|
|
}
|