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-08-13 16:26:38 +00:00
|
|
|
#ifndef LLVM_IR_PASSMANAGER_H
|
|
|
|
#define LLVM_IR_PASSMANAGER_H
|
2014-01-11 10:59:00 +00:00
|
|
|
|
2013-11-13 01:12:08 +00:00
|
|
|
#include "llvm/ADT/DenseMap.h"
|
2014-03-09 11:49:53 +00:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2013-11-20 11:31:50 +00:00
|
|
|
#include "llvm/ADT/SmallPtrSet.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"
|
2015-01-02 23:25:16 +00:00
|
|
|
#include "llvm/IR/PassManagerInternal.h"
|
2015-01-13 02:51:47 +00:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
|
|
|
#include "llvm/Support/Debug.h"
|
2015-03-23 18:23:08 +00:00
|
|
|
#include "llvm/Support/raw_ostream.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>
|
2014-03-09 11:49:53 +00:00
|
|
|
#include <memory>
|
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:
|
2014-03-10 00:50:56 +00:00
|
|
|
// We have to explicitly define all the special member functions because MSVC
|
|
|
|
// refuses to generate them.
|
2014-03-10 00:35:47 +00:00
|
|
|
PreservedAnalyses() {}
|
|
|
|
PreservedAnalyses(const PreservedAnalyses &Arg)
|
|
|
|
: PreservedPassIDs(Arg.PreservedPassIDs) {}
|
|
|
|
PreservedAnalyses(PreservedAnalyses &&Arg)
|
2014-03-10 01:32:25 +00:00
|
|
|
: PreservedPassIDs(std::move(Arg.PreservedPassIDs)) {}
|
2014-03-13 10:42:18 +00:00
|
|
|
friend void swap(PreservedAnalyses &LHS, PreservedAnalyses &RHS) {
|
|
|
|
using std::swap;
|
|
|
|
swap(LHS.PreservedPassIDs, RHS.PreservedPassIDs);
|
|
|
|
}
|
2014-03-10 00:35:47 +00:00
|
|
|
PreservedAnalyses &operator=(PreservedAnalyses RHS) {
|
2014-03-13 10:42:18 +00:00
|
|
|
swap(*this, RHS);
|
2014-03-10 00:35:47 +00:00
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
2013-11-20 11:31:50 +00:00
|
|
|
/// \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;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Mark a particular pass as preserved, adding it to the set.
|
[PM] Fix a pretty nasty bug where the new pass manager would invalidate
passes too many time.
I think this is actually the issue that someone raised with me at the
developer's meeting and in an email, but that we never really got to the
bottom of. Having all the testing utilities made it much easier to dig
down and uncover the core issue.
When a pass manager is running many passes over a single function, we
need it to invalidate the analyses between each run so that they can be
re-computed as needed. We also need to track the intersection of
preserved higher-level analyses across all the passes that we run (for
example, if there is one module analysis which all the function analyses
preserve, we want to track that and propagate it). Unfortunately, this
interacted poorly with any enclosing pass adaptor between two IR units.
It would see the intersection of preserved analyses, and need to
invalidate any other analyses, but some of the un-preserved analyses
might have already been invalidated *and recomputed*! We would fail to
propagate the fact that the analysis had already been invalidated.
The solution to this struck me as really strange at first, but the more
I thought about it, the more natural it seemed. After a nice discussion
with Duncan about it on IRC, it seemed even nicer. The idea is that
invalidating an analysis *causes* it to be preserved! Preserving the
lack of result is trivial. If it is recomputed, great. Until something
*else* invalidates it again, we're good.
The consequence of this is that the invalidate methods on the analysis
manager which operate over many passes now consume their
PreservedAnalyses object, update it to "preserve" every analysis pass to
which it delivers an invalidation (regardless of whether the pass
chooses to be removed, or handles the invalidation itself by updating
itself). Then we return this augmented set from the invalidate routine,
letting the pass manager take the result and use the intersection of
*that* across each pass run to compute the final preserved set. This
accounts for all the places where the early invalidation of an analysis
has already "preserved" it for a future run.
I've beefed up the testing and adjusted the assertions to show that we
no longer repeatedly invalidate or compute the analyses across nested
pass managers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225333 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-07 01:58:35 +00:00
|
|
|
template <typename PassT> void preserve() { preserve(PassT::ID()); }
|
|
|
|
|
|
|
|
/// \brief Mark an abstract PassID as preserved, adding it to the set.
|
|
|
|
void preserve(void *PassID) {
|
2013-11-20 11:31:50 +00:00
|
|
|
if (!areAllPreserved())
|
[PM] Fix a pretty nasty bug where the new pass manager would invalidate
passes too many time.
I think this is actually the issue that someone raised with me at the
developer's meeting and in an email, but that we never really got to the
bottom of. Having all the testing utilities made it much easier to dig
down and uncover the core issue.
When a pass manager is running many passes over a single function, we
need it to invalidate the analyses between each run so that they can be
re-computed as needed. We also need to track the intersection of
preserved higher-level analyses across all the passes that we run (for
example, if there is one module analysis which all the function analyses
preserve, we want to track that and propagate it). Unfortunately, this
interacted poorly with any enclosing pass adaptor between two IR units.
It would see the intersection of preserved analyses, and need to
invalidate any other analyses, but some of the un-preserved analyses
might have already been invalidated *and recomputed*! We would fail to
propagate the fact that the analysis had already been invalidated.
The solution to this struck me as really strange at first, but the more
I thought about it, the more natural it seemed. After a nice discussion
with Duncan about it on IRC, it seemed even nicer. The idea is that
invalidating an analysis *causes* it to be preserved! Preserving the
lack of result is trivial. If it is recomputed, great. Until something
*else* invalidates it again, we're good.
The consequence of this is that the invalidate methods on the analysis
manager which operate over many passes now consume their
PreservedAnalyses object, update it to "preserve" every analysis pass to
which it delivers an invalidation (regardless of whether the pass
chooses to be removed, or handles the invalidation itself by updating
itself). Then we return this augmented set from the invalidate routine,
letting the pass manager take the result and use the intersection of
*that* across each pass run to compute the final preserved set. This
accounts for all the places where the early invalidation of an analysis
has already "preserved" it for a future run.
I've beefed up the testing and adjusted the assertions to show that we
no longer repeatedly invalidate or compute the analyses across nested
pass managers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225333 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-07 01:58:35 +00:00
|
|
|
PreservedPassIDs.insert(PassID);
|
2013-11-20 11:31:50 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/// \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;
|
|
|
|
}
|
2014-08-24 23:23:06 +00:00
|
|
|
for (void *P : PreservedPassIDs)
|
|
|
|
if (!Arg.PreservedPassIDs.count(P))
|
|
|
|
PreservedPassIDs.erase(P);
|
2013-11-20 11:31:50 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/// \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;
|
|
|
|
}
|
2014-08-24 23:23:06 +00:00
|
|
|
for (void *P : PreservedPassIDs)
|
|
|
|
if (!Arg.PreservedPassIDs.count(P))
|
|
|
|
PreservedPassIDs.erase(P);
|
2013-11-20 11:31:50 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/// \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);
|
|
|
|
}
|
|
|
|
|
2015-01-05 12:32:11 +00:00
|
|
|
/// \brief Test whether all passes are preserved.
|
|
|
|
///
|
|
|
|
/// This is used primarily to optimize for the case of no changes which will
|
|
|
|
/// common in many scenarios.
|
|
|
|
bool areAllPreserved() const {
|
|
|
|
return PreservedPassIDs.count((void *)AllPassesID);
|
|
|
|
}
|
|
|
|
|
2013-11-20 11:31:50 +00:00
|
|
|
private:
|
|
|
|
// Note that this must not be -1 or -2 as those are already used by the
|
|
|
|
// SmallPtrSet.
|
2014-03-10 01:42:03 +00:00
|
|
|
static const uintptr_t AllPassesID = (intptr_t)(-3);
|
2013-11-20 11:31:50 +00:00
|
|
|
|
|
|
|
SmallPtrSet<void *, 2> PreservedPassIDs;
|
|
|
|
};
|
|
|
|
|
2015-01-13 21:30:27 +00:00
|
|
|
// Forward declare the analysis manager template.
|
2015-01-13 02:51:47 +00:00
|
|
|
template <typename IRUnitT> class AnalysisManager;
|
2013-11-13 01:12:08 +00:00
|
|
|
|
2015-01-13 11:13:56 +00:00
|
|
|
/// \brief Manages a sequence of passes over units of IR.
|
2015-01-02 23:34:39 +00:00
|
|
|
///
|
2015-01-13 11:13:56 +00:00
|
|
|
/// A pass manager contains a sequence of passes to run over units of IR. It is
|
|
|
|
/// itself a valid pass over that unit of IR, and when over some given IR will
|
|
|
|
/// run each pass in sequence. This is the primary and most basic building
|
|
|
|
/// block of a pass pipeline.
|
2015-01-02 23:34:39 +00:00
|
|
|
///
|
2015-01-13 11:13:56 +00:00
|
|
|
/// If it is run with an \c AnalysisManager<IRUnitT> argument, it will propagate
|
2015-01-02 23:34:39 +00:00
|
|
|
/// that analysis manager to each pass it runs, as well as calling the analysis
|
|
|
|
/// manager's invalidation routine with the PreservedAnalyses of each pass it
|
|
|
|
/// runs.
|
2015-01-13 11:13:56 +00:00
|
|
|
template <typename IRUnitT> class PassManager {
|
2013-11-09 13:09:08 +00:00
|
|
|
public:
|
2015-01-13 22:42:38 +00:00
|
|
|
/// \brief Construct a pass manager.
|
|
|
|
///
|
|
|
|
/// It can be passed a flag to get debug logging as the passes are run.
|
|
|
|
PassManager(bool DebugLogging = false) : DebugLogging(DebugLogging) {}
|
2014-03-10 00:35:47 +00:00
|
|
|
// We have to explicitly define all the special member functions because MSVC
|
2014-03-10 00:50:56 +00:00
|
|
|
// refuses to generate them.
|
2015-01-13 22:42:38 +00:00
|
|
|
PassManager(PassManager &&Arg)
|
|
|
|
: Passes(std::move(Arg.Passes)),
|
|
|
|
DebugLogging(std::move(Arg.DebugLogging)) {}
|
2015-01-13 11:13:56 +00:00
|
|
|
PassManager &operator=(PassManager &&RHS) {
|
2014-03-10 00:35:47 +00:00
|
|
|
Passes = std::move(RHS.Passes);
|
2015-01-13 22:42:38 +00:00
|
|
|
DebugLogging = std::move(RHS.DebugLogging);
|
2014-03-10 00:35:47 +00:00
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
2015-01-13 11:13:56 +00:00
|
|
|
/// \brief Run all of the passes in this manager over the IR.
|
|
|
|
PreservedAnalyses run(IRUnitT &IR, AnalysisManager<IRUnitT> *AM = nullptr) {
|
|
|
|
PreservedAnalyses PA = PreservedAnalyses::all();
|
2013-11-09 13:09:08 +00:00
|
|
|
|
2015-01-13 22:42:38 +00:00
|
|
|
if (DebugLogging)
|
2015-01-13 11:13:56 +00:00
|
|
|
dbgs() << "Starting pass manager run.\n";
|
2013-11-09 13:09:08 +00:00
|
|
|
|
2015-01-13 11:13:56 +00:00
|
|
|
for (unsigned Idx = 0, Size = Passes.size(); Idx != Size; ++Idx) {
|
2015-01-13 22:42:38 +00:00
|
|
|
if (DebugLogging)
|
2015-01-13 11:13:56 +00:00
|
|
|
dbgs() << "Running pass: " << Passes[Idx]->name() << "\n";
|
|
|
|
|
|
|
|
PreservedAnalyses PassPA = Passes[Idx]->run(IR, AM);
|
|
|
|
|
|
|
|
// If we have an active analysis manager at this level we want to ensure
|
|
|
|
// we update it as each pass runs and potentially invalidates analyses.
|
|
|
|
// We also update the preserved set of analyses based on what analyses we
|
|
|
|
// have already handled the invalidation for here and don't need to
|
|
|
|
// invalidate when finished.
|
|
|
|
if (AM)
|
|
|
|
PassPA = AM->invalidate(IR, std::move(PassPA));
|
|
|
|
|
|
|
|
// Finally, we intersect the final preserved analyses to compute the
|
|
|
|
// aggregate preserved set for this pass manager.
|
|
|
|
PA.intersect(std::move(PassPA));
|
|
|
|
|
|
|
|
// FIXME: Historically, the pass managers all called the LLVM context's
|
|
|
|
// yield function here. We don't have a generic way to acquire the
|
|
|
|
// context and it isn't yet clear what the right pattern is for yielding
|
|
|
|
// in the new pass manager so it is currently omitted.
|
|
|
|
//IR.getContext().yield();
|
|
|
|
}
|
2014-03-10 00:35:47 +00:00
|
|
|
|
2015-01-13 22:42:38 +00:00
|
|
|
if (DebugLogging)
|
2015-01-13 11:13:56 +00:00
|
|
|
dbgs() << "Finished pass manager run.\n";
|
2013-11-09 13:09:08 +00:00
|
|
|
|
2015-01-13 11:13:56 +00:00
|
|
|
return PA;
|
2014-03-10 00:35:47 +00:00
|
|
|
}
|
|
|
|
|
2015-01-13 11:13:56 +00:00
|
|
|
template <typename PassT> void addPass(PassT Pass) {
|
2015-01-13 11:36:43 +00:00
|
|
|
typedef detail::PassModel<IRUnitT, PassT> PassModelT;
|
|
|
|
Passes.emplace_back(new PassModelT(std::move(Pass)));
|
2013-11-09 13:09:08 +00:00
|
|
|
}
|
|
|
|
|
2015-01-13 11:13:56 +00:00
|
|
|
static StringRef name() { return "PassManager"; }
|
2014-01-11 11:52:05 +00:00
|
|
|
|
2013-11-09 13:09:08 +00:00
|
|
|
private:
|
2015-01-13 11:36:43 +00:00
|
|
|
typedef detail::PassConcept<IRUnitT> PassConceptT;
|
2013-11-09 13:09:08 +00:00
|
|
|
|
2015-02-15 22:54:22 +00:00
|
|
|
PassManager(const PassManager &) = delete;
|
|
|
|
PassManager &operator=(const PassManager &) = delete;
|
2014-03-10 00:35:47 +00:00
|
|
|
|
2015-01-13 11:36:43 +00:00
|
|
|
std::vector<std::unique_ptr<PassConceptT>> Passes;
|
2015-01-13 22:42:38 +00:00
|
|
|
|
|
|
|
/// \brief Flag indicating whether we should do debug logging.
|
|
|
|
bool DebugLogging;
|
2013-11-09 13:09:08 +00:00
|
|
|
};
|
|
|
|
|
2015-01-13 11:13:56 +00:00
|
|
|
/// \brief Convenience typedef for a pass manager over modules.
|
|
|
|
typedef PassManager<Module> ModulePassManager;
|
|
|
|
|
|
|
|
/// \brief Convenience typedef for a pass manager over functions.
|
|
|
|
typedef PassManager<Function> FunctionPassManager;
|
|
|
|
|
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.
|
2015-01-13 02:51:47 +00:00
|
|
|
///
|
|
|
|
/// Note that there is also a generic analysis manager template which implements
|
|
|
|
/// the above required functions along with common datastructures used for
|
|
|
|
/// managing analyses. This base class is factored so that if you need to
|
|
|
|
/// customize the handling of a specific IR unit, you can do so without
|
|
|
|
/// replicating *all* of the boilerplate.
|
2014-03-10 01:42:03 +00:00
|
|
|
template <typename DerivedT, typename IRUnitT> class AnalysisManagerBase {
|
2013-11-26 11:24:37 +00:00
|
|
|
DerivedT *derived_this() { return static_cast<DerivedT *>(this); }
|
2014-03-10 01:42:03 +00:00
|
|
|
const DerivedT *derived_this() const {
|
|
|
|
return static_cast<const DerivedT *>(this);
|
|
|
|
}
|
2013-11-26 11:24:37 +00:00
|
|
|
|
2015-02-15 22:54:22 +00:00
|
|
|
AnalysisManagerBase(const AnalysisManagerBase &) = delete;
|
2014-03-10 00:35:47 +00:00
|
|
|
AnalysisManagerBase &
|
2015-02-15 22:54:22 +00:00
|
|
|
operator=(const AnalysisManagerBase &) = delete;
|
2014-03-10 00:35:47 +00:00
|
|
|
|
2013-11-26 11:24:37 +00:00
|
|
|
protected:
|
|
|
|
typedef detail::AnalysisResultConcept<IRUnitT> ResultConceptT;
|
2015-01-13 11:31:43 +00:00
|
|
|
typedef detail::AnalysisPassConcept<IRUnitT> 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.
|
|
|
|
|
2014-03-10 00:50:56 +00:00
|
|
|
// We have to explicitly define all the special member functions because MSVC
|
|
|
|
// refuses to generate them.
|
2014-03-10 00:35:47 +00:00
|
|
|
AnalysisManagerBase() {}
|
|
|
|
AnalysisManagerBase(AnalysisManagerBase &&Arg)
|
|
|
|
: AnalysisPasses(std::move(Arg.AnalysisPasses)) {}
|
|
|
|
AnalysisManagerBase &operator=(AnalysisManagerBase &&RHS) {
|
|
|
|
AnalysisPasses = std::move(RHS.AnalysisPasses);
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
2013-11-26 11:24:37 +00:00
|
|
|
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.
|
[PM] Sink the reference vs. value decision for IR units out of the
templated interface.
So far, every single IR unit I can come up with has address-identity.
That is, when two units of IR are both active in LLVM, their addresses
will be distinct of the IR is distinct. This is clearly true for
Modules, Functions, BasicBlocks, and Instructions. It turns out that the
only practical way to make the CGSCC stuff work the way we want is to
make it true for SCCs as well. I expect this pattern to continue.
When first designing the pass manager code, I kept this dimension of
freedom in the type parameters, essentially allowing for a wrapper-type
whose address did not form identity. But that really no longer makes
sense and is making the code more complex or subtle for no gain. If we
ever have an actual use case for this, we can figure out what makes
sense then and there. It will be better because then we will have the
actual example in hand.
While the simplifications afforded in this patch are fairly small
(mostly sinking the '&' out of many type parameters onto a few
interfaces), it would have become much more pronounced with subsequent
changes. I have a sequence of changes that will completely remove the
code duplication that currently exists between all of the pass managers
and analysis managers. =] Should make things much cleaner and avoid bug
fixing N times for the N pass managers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225723 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-12 22:53:31 +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>
|
[PM] Sink the reference vs. value decision for IR units out of the
templated interface.
So far, every single IR unit I can come up with has address-identity.
That is, when two units of IR are both active in LLVM, their addresses
will be distinct of the IR is distinct. This is clearly true for
Modules, Functions, BasicBlocks, and Instructions. It turns out that the
only practical way to make the CGSCC stuff work the way we want is to
make it true for SCCs as well. I expect this pattern to continue.
When first designing the pass manager code, I kept this dimension of
freedom in the type parameters, essentially allowing for a wrapper-type
whose address did not form identity. But that really no longer makes
sense and is making the code more complex or subtle for no gain. If we
ever have an actual use case for this, we can figure out what makes
sense then and there. It will be better because then we will have the
actual example in hand.
While the simplifications afforded in this patch are fairly small
(mostly sinking the '&' out of many type parameters onto a few
interfaces), it would have become much more pronounced with subsequent
changes. I have a sequence of changes that will completely remove the
code duplication that currently exists between all of the pass managers
and analysis managers. =] Should make things much cleaner and avoid bug
fixing N times for the N pass managers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225723 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-12 22:53:31 +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)
|
2014-04-24 06:44:33 +00:00
|
|
|
return nullptr;
|
2013-11-23 00:38:42 +00:00
|
|
|
|
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!");
|
2015-01-13 11:31:43 +00:00
|
|
|
typedef detail::AnalysisPassModel<IRUnitT, PassT> PassModelT;
|
2014-03-09 11:49:53 +00:00
|
|
|
AnalysisPasses[PassT::ID()].reset(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.
|
[PM] Sink the reference vs. value decision for IR units out of the
templated interface.
So far, every single IR unit I can come up with has address-identity.
That is, when two units of IR are both active in LLVM, their addresses
will be distinct of the IR is distinct. This is clearly true for
Modules, Functions, BasicBlocks, and Instructions. It turns out that the
only practical way to make the CGSCC stuff work the way we want is to
make it true for SCCs as well. I expect this pattern to continue.
When first designing the pass manager code, I kept this dimension of
freedom in the type parameters, essentially allowing for a wrapper-type
whose address did not form identity. But that really no longer makes
sense and is making the code more complex or subtle for no gain. If we
ever have an actual use case for this, we can figure out what makes
sense then and there. It will be better because then we will have the
actual example in hand.
While the simplifications afforded in this patch are fairly small
(mostly sinking the '&' out of many type parameters onto a few
interfaces), it would have become much more pronounced with subsequent
changes. I have a sequence of changes that will completely remove the
code duplication that currently exists between all of the pass managers
and analysis managers. =] Should make things much cleaner and avoid bug
fixing N times for the N pass managers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225723 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-12 22:53:31 +00:00
|
|
|
template <typename PassT> void invalidate(IRUnitT &IR) {
|
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");
|
2015-01-06 04:49:44 +00:00
|
|
|
derived_this()->invalidateImpl(PassT::ID(), IR);
|
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.
|
[PM] Fix a pretty nasty bug where the new pass manager would invalidate
passes too many time.
I think this is actually the issue that someone raised with me at the
developer's meeting and in an email, but that we never really got to the
bottom of. Having all the testing utilities made it much easier to dig
down and uncover the core issue.
When a pass manager is running many passes over a single function, we
need it to invalidate the analyses between each run so that they can be
re-computed as needed. We also need to track the intersection of
preserved higher-level analyses across all the passes that we run (for
example, if there is one module analysis which all the function analyses
preserve, we want to track that and propagate it). Unfortunately, this
interacted poorly with any enclosing pass adaptor between two IR units.
It would see the intersection of preserved analyses, and need to
invalidate any other analyses, but some of the un-preserved analyses
might have already been invalidated *and recomputed*! We would fail to
propagate the fact that the analysis had already been invalidated.
The solution to this struck me as really strange at first, but the more
I thought about it, the more natural it seemed. After a nice discussion
with Duncan about it on IRC, it seemed even nicer. The idea is that
invalidating an analysis *causes* it to be preserved! Preserving the
lack of result is trivial. If it is recomputed, great. Until something
*else* invalidates it again, we're good.
The consequence of this is that the invalidate methods on the analysis
manager which operate over many passes now consume their
PreservedAnalyses object, update it to "preserve" every analysis pass to
which it delivers an invalidation (regardless of whether the pass
chooses to be removed, or handles the invalidation itself by updating
itself). Then we return this augmented set from the invalidate routine,
letting the pass manager take the result and use the intersection of
*that* across each pass run to compute the final preserved set. This
accounts for all the places where the early invalidation of an analysis
has already "preserved" it for a future run.
I've beefed up the testing and adjusted the assertions to show that we
no longer repeatedly invalidate or compute the analyses across nested
pass managers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225333 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-07 01:58:35 +00:00
|
|
|
/// We accept the PreservedAnalyses set by value and update it with each
|
|
|
|
/// analyis pass which has been successfully invalidated and thus can be
|
|
|
|
/// preserved going forward. The updated set is returned.
|
[PM] Sink the reference vs. value decision for IR units out of the
templated interface.
So far, every single IR unit I can come up with has address-identity.
That is, when two units of IR are both active in LLVM, their addresses
will be distinct of the IR is distinct. This is clearly true for
Modules, Functions, BasicBlocks, and Instructions. It turns out that the
only practical way to make the CGSCC stuff work the way we want is to
make it true for SCCs as well. I expect this pattern to continue.
When first designing the pass manager code, I kept this dimension of
freedom in the type parameters, essentially allowing for a wrapper-type
whose address did not form identity. But that really no longer makes
sense and is making the code more complex or subtle for no gain. If we
ever have an actual use case for this, we can figure out what makes
sense then and there. It will be better because then we will have the
actual example in hand.
While the simplifications afforded in this patch are fairly small
(mostly sinking the '&' out of many type parameters onto a few
interfaces), it would have become much more pronounced with subsequent
changes. I have a sequence of changes that will completely remove the
code duplication that currently exists between all of the pass managers
and analysis managers. =] Should make things much cleaner and avoid bug
fixing N times for the N pass managers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225723 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-12 22:53:31 +00:00
|
|
|
PreservedAnalyses invalidate(IRUnitT &IR, PreservedAnalyses PA) {
|
[PM] Fix a pretty nasty bug where the new pass manager would invalidate
passes too many time.
I think this is actually the issue that someone raised with me at the
developer's meeting and in an email, but that we never really got to the
bottom of. Having all the testing utilities made it much easier to dig
down and uncover the core issue.
When a pass manager is running many passes over a single function, we
need it to invalidate the analyses between each run so that they can be
re-computed as needed. We also need to track the intersection of
preserved higher-level analyses across all the passes that we run (for
example, if there is one module analysis which all the function analyses
preserve, we want to track that and propagate it). Unfortunately, this
interacted poorly with any enclosing pass adaptor between two IR units.
It would see the intersection of preserved analyses, and need to
invalidate any other analyses, but some of the un-preserved analyses
might have already been invalidated *and recomputed*! We would fail to
propagate the fact that the analysis had already been invalidated.
The solution to this struck me as really strange at first, but the more
I thought about it, the more natural it seemed. After a nice discussion
with Duncan about it on IRC, it seemed even nicer. The idea is that
invalidating an analysis *causes* it to be preserved! Preserving the
lack of result is trivial. If it is recomputed, great. Until something
*else* invalidates it again, we're good.
The consequence of this is that the invalidate methods on the analysis
manager which operate over many passes now consume their
PreservedAnalyses object, update it to "preserve" every analysis pass to
which it delivers an invalidation (regardless of whether the pass
chooses to be removed, or handles the invalidation itself by updating
itself). Then we return this augmented set from the invalidate routine,
letting the pass manager take the result and use the intersection of
*that* across each pass run to compute the final preserved set. This
accounts for all the places where the early invalidation of an analysis
has already "preserved" it for a future run.
I've beefed up the testing and adjusted the assertions to show that we
no longer repeatedly invalidate or compute the analyses across nested
pass managers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225333 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-07 01:58:35 +00:00
|
|
|
return derived_this()->invalidateImpl(IR, std::move(PA));
|
2013-11-26 11:24:37 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
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.
|
2014-03-09 11:49:53 +00:00
|
|
|
typedef DenseMap<void *, std::unique_ptr<PassConceptT>> AnalysisPassMapT;
|
2013-11-26 11:24:37 +00:00
|
|
|
|
|
|
|
/// \brief Collection of module analysis passes, indexed by ID.
|
|
|
|
AnalysisPassMapT AnalysisPasses;
|
|
|
|
};
|
|
|
|
|
2014-03-10 01:42:03 +00:00
|
|
|
} // End namespace detail
|
2013-11-26 11:24:37 +00:00
|
|
|
|
2015-01-13 02:51:47 +00:00
|
|
|
/// \brief A generic analysis pass manager with lazy running and caching of
|
2013-11-26 11:24:37 +00:00
|
|
|
/// results.
|
2015-01-13 02:51:47 +00:00
|
|
|
///
|
|
|
|
/// This analysis manager can be used for any IR unit where the address of the
|
|
|
|
/// IR unit sufficies as its identity. It manages the cache for a unit of IR via
|
|
|
|
/// the address of each unit of IR cached.
|
|
|
|
template <typename IRUnitT>
|
|
|
|
class AnalysisManager
|
|
|
|
: public detail::AnalysisManagerBase<AnalysisManager<IRUnitT>, IRUnitT> {
|
|
|
|
friend class detail::AnalysisManagerBase<AnalysisManager<IRUnitT>, IRUnitT>;
|
|
|
|
typedef detail::AnalysisManagerBase<AnalysisManager<IRUnitT>, IRUnitT> BaseT;
|
|
|
|
typedef typename BaseT::ResultConceptT ResultConceptT;
|
|
|
|
typedef typename 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
|
|
|
|
2015-01-13 22:42:38 +00:00
|
|
|
/// \brief Construct an empty analysis manager.
|
|
|
|
///
|
|
|
|
/// A flag can be passed to indicate that the manager should perform debug
|
|
|
|
/// logging.
|
|
|
|
AnalysisManager(bool DebugLogging = false) : DebugLogging(DebugLogging) {}
|
|
|
|
|
2014-03-10 00:50:56 +00:00
|
|
|
// We have to explicitly define all the special member functions because MSVC
|
|
|
|
// refuses to generate them.
|
2015-01-13 02:51:47 +00:00
|
|
|
AnalysisManager(AnalysisManager &&Arg)
|
2014-03-10 00:35:47 +00:00
|
|
|
: BaseT(std::move(static_cast<BaseT &>(Arg))),
|
2015-01-13 22:42:38 +00:00
|
|
|
AnalysisResults(std::move(Arg.AnalysisResults)),
|
|
|
|
DebugLogging(std::move(Arg.DebugLogging)) {}
|
2015-01-13 02:51:47 +00:00
|
|
|
AnalysisManager &operator=(AnalysisManager &&RHS) {
|
2014-03-10 00:35:47 +00:00
|
|
|
BaseT::operator=(std::move(static_cast<BaseT &>(RHS)));
|
2015-01-13 02:51:47 +00:00
|
|
|
AnalysisResults = std::move(RHS.AnalysisResults);
|
2015-01-13 22:42:38 +00:00
|
|
|
DebugLogging = std::move(RHS.DebugLogging);
|
2014-03-10 00:35:47 +00:00
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
2013-11-21 02:11:31 +00:00
|
|
|
/// \brief Returns true if the analysis manager has an empty results cache.
|
2015-01-13 02:51:47 +00:00
|
|
|
bool empty() const {
|
|
|
|
assert(AnalysisResults.empty() == AnalysisResultLists.empty() &&
|
|
|
|
"The storage and index of analysis results disagree on how many "
|
|
|
|
"there are!");
|
|
|
|
return AnalysisResults.empty();
|
|
|
|
}
|
2013-11-21 02:11:31 +00:00
|
|
|
|
2015-01-13 02:51:47 +00:00
|
|
|
/// \brief Clear the analysis result cache.
|
2013-11-21 02:11:31 +00:00
|
|
|
///
|
2015-01-13 02:51:47 +00:00
|
|
|
/// This routine allows cleaning up when the set of IR units itself has
|
2013-11-21 02:11:31 +00:00
|
|
|
/// potentially changed, and thus we can't even look up a a result and
|
2015-01-13 02:51:47 +00:00
|
|
|
/// invalidate it directly. Notably, this does *not* call invalidate functions
|
|
|
|
/// as there is nothing to be done for them.
|
|
|
|
void clear() {
|
|
|
|
AnalysisResults.clear();
|
|
|
|
AnalysisResultLists.clear();
|
|
|
|
}
|
2013-11-21 02:11:31 +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
|
|
|
private:
|
2015-02-15 22:54:22 +00:00
|
|
|
AnalysisManager(const AnalysisManager &) = delete;
|
|
|
|
AnalysisManager &operator=(const AnalysisManager &) = delete;
|
2015-01-13 02:51:47 +00:00
|
|
|
|
|
|
|
/// \brief Get an analysis result, running the pass if necessary.
|
|
|
|
ResultConceptT &getResultImpl(void *PassID, IRUnitT &IR) {
|
|
|
|
typename AnalysisResultMapT::iterator RI;
|
|
|
|
bool Inserted;
|
|
|
|
std::tie(RI, Inserted) = AnalysisResults.insert(std::make_pair(
|
|
|
|
std::make_pair(PassID, &IR), typename AnalysisResultListT::iterator()));
|
|
|
|
|
|
|
|
// If we don't have a cached result for this function, look up the pass and
|
|
|
|
// run it to produce a result, which we then add to the cache.
|
|
|
|
if (Inserted) {
|
|
|
|
auto &P = this->lookupPass(PassID);
|
2015-01-13 22:42:38 +00:00
|
|
|
if (DebugLogging)
|
2015-01-13 02:51:47 +00:00
|
|
|
dbgs() << "Running analysis: " << P.name() << "\n";
|
|
|
|
AnalysisResultListT &ResultList = AnalysisResultLists[&IR];
|
|
|
|
ResultList.emplace_back(PassID, P.run(IR, this));
|
2015-02-27 02:19:11 +00:00
|
|
|
|
|
|
|
// P.run may have inserted elements into AnalysisResults and invalidated
|
|
|
|
// RI.
|
|
|
|
RI = AnalysisResults.find(std::make_pair(PassID, &IR));
|
|
|
|
assert(RI != AnalysisResults.end() && "we just inserted it!");
|
|
|
|
|
2015-01-13 02:51:47 +00:00
|
|
|
RI->second = std::prev(ResultList.end());
|
|
|
|
}
|
2014-03-10 00:35:47 +00:00
|
|
|
|
2015-01-13 02:51:47 +00:00
|
|
|
return *RI->second->second;
|
|
|
|
}
|
2013-11-13 01:12:08 +00:00
|
|
|
|
2015-01-13 02:51:47 +00:00
|
|
|
/// \brief Get a cached analysis result or return null.
|
|
|
|
ResultConceptT *getCachedResultImpl(void *PassID, IRUnitT &IR) const {
|
|
|
|
typename AnalysisResultMapT::const_iterator RI =
|
|
|
|
AnalysisResults.find(std::make_pair(PassID, &IR));
|
|
|
|
return RI == AnalysisResults.end() ? nullptr : &*RI->second->second;
|
|
|
|
}
|
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.
|
2015-01-13 02:51:47 +00:00
|
|
|
void invalidateImpl(void *PassID, IRUnitT &IR) {
|
|
|
|
typename AnalysisResultMapT::iterator RI =
|
|
|
|
AnalysisResults.find(std::make_pair(PassID, &IR));
|
|
|
|
if (RI == AnalysisResults.end())
|
|
|
|
return;
|
|
|
|
|
2015-01-13 22:42:38 +00:00
|
|
|
if (DebugLogging)
|
2015-01-13 02:51:47 +00:00
|
|
|
dbgs() << "Invalidating analysis: " << this->lookupPass(PassID).name()
|
|
|
|
<< "\n";
|
|
|
|
AnalysisResultLists[&IR].erase(RI->second);
|
|
|
|
AnalysisResults.erase(RI);
|
|
|
|
}
|
2013-11-13 01:12:08 +00:00
|
|
|
|
2013-11-26 11:24:37 +00:00
|
|
|
/// \brief Invalidate the results for a function..
|
2015-01-13 02:51:47 +00:00
|
|
|
PreservedAnalyses invalidateImpl(IRUnitT &IR, PreservedAnalyses PA) {
|
|
|
|
// Short circuit for a common case of all analyses being preserved.
|
|
|
|
if (PA.areAllPreserved())
|
2015-05-01 15:16:11 +00:00
|
|
|
return PA;
|
2015-01-13 02:51:47 +00:00
|
|
|
|
2015-01-13 22:42:38 +00:00
|
|
|
if (DebugLogging)
|
2015-01-13 02:51:47 +00:00
|
|
|
dbgs() << "Invalidating all non-preserved analyses for: "
|
|
|
|
<< IR.getName() << "\n";
|
|
|
|
|
|
|
|
// Clear all the invalidated results associated specifically with this
|
|
|
|
// function.
|
|
|
|
SmallVector<void *, 8> InvalidatedPassIDs;
|
|
|
|
AnalysisResultListT &ResultsList = AnalysisResultLists[&IR];
|
|
|
|
for (typename AnalysisResultListT::iterator I = ResultsList.begin(),
|
|
|
|
E = ResultsList.end();
|
|
|
|
I != E;) {
|
|
|
|
void *PassID = I->first;
|
|
|
|
|
|
|
|
// Pass the invalidation down to the pass itself to see if it thinks it is
|
|
|
|
// necessary. The analysis pass can return false if no action on the part
|
|
|
|
// of the analysis manager is required for this invalidation event.
|
|
|
|
if (I->second->invalidate(IR, PA)) {
|
2015-01-13 22:42:38 +00:00
|
|
|
if (DebugLogging)
|
2015-01-13 02:51:47 +00:00
|
|
|
dbgs() << "Invalidating analysis: " << this->lookupPass(PassID).name()
|
|
|
|
<< "\n";
|
|
|
|
|
|
|
|
InvalidatedPassIDs.push_back(I->first);
|
|
|
|
I = ResultsList.erase(I);
|
|
|
|
} else {
|
|
|
|
++I;
|
|
|
|
}
|
|
|
|
|
|
|
|
// After handling each pass, we mark it as preserved. Once we've
|
|
|
|
// invalidated any stale results, the rest of the system is allowed to
|
|
|
|
// start preserving this analysis again.
|
|
|
|
PA.preserve(PassID);
|
|
|
|
}
|
|
|
|
while (!InvalidatedPassIDs.empty())
|
|
|
|
AnalysisResults.erase(
|
|
|
|
std::make_pair(InvalidatedPassIDs.pop_back_val(), &IR));
|
|
|
|
if (ResultsList.empty())
|
|
|
|
AnalysisResultLists.erase(&IR);
|
|
|
|
|
2015-05-01 15:16:11 +00:00
|
|
|
return PA;
|
2015-01-13 02:51:47 +00:00
|
|
|
}
|
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<
|
2015-01-13 02:51:47 +00:00
|
|
|
void *, std::unique_ptr<detail::AnalysisResultConcept<IRUnitT>>>>
|
|
|
|
AnalysisResultListT;
|
2013-11-13 01:12:08 +00:00
|
|
|
|
|
|
|
/// \brief Map type from function pointer to our custom list type.
|
2015-01-13 02:51:47 +00:00
|
|
|
typedef DenseMap<IRUnitT *, AnalysisResultListT> AnalysisResultListMapT;
|
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.
|
2015-01-13 02:51:47 +00:00
|
|
|
AnalysisResultListMapT AnalysisResultLists;
|
2013-11-13 01:12:08 +00:00
|
|
|
|
|
|
|
/// \brief Map type from a pair of analysis ID and function pointer to an
|
|
|
|
/// iterator into a particular result list.
|
2015-01-13 02:51:47 +00:00
|
|
|
typedef DenseMap<std::pair<void *, IRUnitT *>,
|
|
|
|
typename AnalysisResultListT::iterator> AnalysisResultMapT;
|
2013-11-13 01:12:08 +00:00
|
|
|
|
|
|
|
/// \brief Map from an analysis ID and function to a particular cached
|
|
|
|
/// analysis result.
|
2015-01-13 02:51:47 +00:00
|
|
|
AnalysisResultMapT AnalysisResults;
|
2015-01-13 22:42:38 +00:00
|
|
|
|
|
|
|
/// \brief A flag indicating whether debug logging is enabled.
|
|
|
|
bool DebugLogging;
|
2013-11-13 01:12:08 +00:00
|
|
|
};
|
|
|
|
|
2015-01-13 21:30:27 +00:00
|
|
|
/// \brief Convenience typedef for the Module analysis manager.
|
|
|
|
typedef AnalysisManager<Module> ModuleAnalysisManager;
|
|
|
|
|
|
|
|
/// \brief Convenience typedef for the Function analysis manager.
|
|
|
|
typedef AnalysisManager<Function> FunctionAnalysisManager;
|
|
|
|
|
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; }
|
|
|
|
|
2015-01-05 12:21:44 +00:00
|
|
|
static StringRef name() { return "FunctionAnalysisManagerModuleProxy"; }
|
|
|
|
|
2014-03-10 00:35:47 +00:00
|
|
|
explicit FunctionAnalysisManagerModuleProxy(FunctionAnalysisManager &FAM)
|
2014-03-13 09:50:31 +00:00
|
|
|
: FAM(&FAM) {}
|
2014-03-10 00:54:01 +00:00
|
|
|
// We have to explicitly define all the special member functions because MSVC
|
|
|
|
// refuses to generate them.
|
2014-03-10 00:35:47 +00:00
|
|
|
FunctionAnalysisManagerModuleProxy(
|
|
|
|
const FunctionAnalysisManagerModuleProxy &Arg)
|
|
|
|
: FAM(Arg.FAM) {}
|
|
|
|
FunctionAnalysisManagerModuleProxy(FunctionAnalysisManagerModuleProxy &&Arg)
|
2014-03-13 09:50:31 +00:00
|
|
|
: FAM(std::move(Arg.FAM)) {}
|
2014-03-10 00:35:47 +00:00
|
|
|
FunctionAnalysisManagerModuleProxy &
|
|
|
|
operator=(FunctionAnalysisManagerModuleProxy RHS) {
|
2014-03-13 10:42:18 +00:00
|
|
|
std::swap(FAM, RHS.FAM);
|
2014-03-10 00:35:47 +00:00
|
|
|
return *this;
|
|
|
|
}
|
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.
|
2015-01-05 02:47:05 +00:00
|
|
|
Result run(Module &M);
|
2013-11-21 02:11:31 +00:00
|
|
|
|
|
|
|
private:
|
|
|
|
static char PassID;
|
|
|
|
|
2014-03-13 09:50:31 +00:00
|
|
|
FunctionAnalysisManager *FAM;
|
2013-11-21 02:11:31 +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
|
|
|
/// \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:
|
2014-03-13 09:50:31 +00:00
|
|
|
explicit Result(FunctionAnalysisManager &FAM) : FAM(&FAM) {}
|
2014-03-10 00:50:56 +00:00
|
|
|
// We have to explicitly define all the special member functions because MSVC
|
|
|
|
// refuses to generate them.
|
2014-03-10 00:35:47 +00:00
|
|
|
Result(const Result &Arg) : FAM(Arg.FAM) {}
|
2014-03-13 09:50:31 +00:00
|
|
|
Result(Result &&Arg) : FAM(std::move(Arg.FAM)) {}
|
2014-03-10 00:35:47 +00:00
|
|
|
Result &operator=(Result RHS) {
|
2014-03-13 10:42:18 +00:00
|
|
|
std::swap(FAM, RHS.FAM);
|
2014-03-10 00:35:47 +00:00
|
|
|
return *this;
|
|
|
|
}
|
2013-11-21 02:11:31 +00:00
|
|
|
~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-03-13 09:50:31 +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.
|
2015-01-05 02:47:05 +00:00
|
|
|
bool invalidate(Module &M, const PreservedAnalyses &PA);
|
2013-11-21 02:11:31 +00:00
|
|
|
|
|
|
|
private:
|
2014-03-13 09:50:31 +00:00
|
|
|
FunctionAnalysisManager *FAM;
|
2013-11-21 02:11:31 +00:00
|
|
|
};
|
|
|
|
|
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:
|
2014-03-13 09:50:31 +00:00
|
|
|
explicit Result(const ModuleAnalysisManager &MAM) : MAM(&MAM) {}
|
2014-03-10 00:50:56 +00:00
|
|
|
// We have to explicitly define all the special member functions because
|
|
|
|
// MSVC refuses to generate them.
|
2014-03-10 00:35:47 +00:00
|
|
|
Result(const Result &Arg) : MAM(Arg.MAM) {}
|
2014-03-13 09:50:31 +00:00
|
|
|
Result(Result &&Arg) : MAM(std::move(Arg.MAM)) {}
|
2014-03-10 00:35:47 +00:00
|
|
|
Result &operator=(Result RHS) {
|
2014-03-13 10:42:18 +00:00
|
|
|
std::swap(MAM, RHS.MAM);
|
2014-03-10 00:35:47 +00:00
|
|
|
return *this;
|
|
|
|
}
|
2013-11-23 01:25:07 +00:00
|
|
|
|
2014-03-13 09:50:31 +00:00
|
|
|
const ModuleAnalysisManager &getManager() const { return *MAM; }
|
2013-11-23 01:25:07 +00:00
|
|
|
|
|
|
|
/// \brief Handle invalidation by ignoring it, this pass is immutable.
|
2015-01-05 02:47:05 +00:00
|
|
|
bool invalidate(Function &) { return false; }
|
2013-11-23 01:25:07 +00:00
|
|
|
|
|
|
|
private:
|
2014-03-13 09:50:31 +00:00
|
|
|
const ModuleAnalysisManager *MAM;
|
2013-11-23 01:25:07 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static void *ID() { return (void *)&PassID; }
|
|
|
|
|
2015-01-05 12:21:44 +00:00
|
|
|
static StringRef name() { return "ModuleAnalysisManagerFunctionProxy"; }
|
|
|
|
|
2013-11-23 01:25:07 +00:00
|
|
|
ModuleAnalysisManagerFunctionProxy(const ModuleAnalysisManager &MAM)
|
2014-03-13 09:50:31 +00:00
|
|
|
: MAM(&MAM) {}
|
2014-03-10 00:54:01 +00:00
|
|
|
// We have to explicitly define all the special member functions because MSVC
|
|
|
|
// refuses to generate them.
|
|
|
|
ModuleAnalysisManagerFunctionProxy(
|
|
|
|
const ModuleAnalysisManagerFunctionProxy &Arg)
|
|
|
|
: MAM(Arg.MAM) {}
|
|
|
|
ModuleAnalysisManagerFunctionProxy(ModuleAnalysisManagerFunctionProxy &&Arg)
|
2014-03-13 09:50:31 +00:00
|
|
|
: MAM(std::move(Arg.MAM)) {}
|
2014-03-10 00:54:01 +00:00
|
|
|
ModuleAnalysisManagerFunctionProxy &
|
|
|
|
operator=(ModuleAnalysisManagerFunctionProxy RHS) {
|
2014-03-13 10:42:18 +00:00
|
|
|
std::swap(MAM, RHS.MAM);
|
2014-03-10 00:54:01 +00:00
|
|
|
return *this;
|
|
|
|
}
|
2013-11-23 01:25:07 +00:00
|
|
|
|
|
|
|
/// \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.
|
2015-01-05 02:47:05 +00:00
|
|
|
Result run(Function &) { return Result(*MAM); }
|
2013-11-23 01:25:07 +00:00
|
|
|
|
|
|
|
private:
|
|
|
|
static char PassID;
|
|
|
|
|
2014-03-13 09:50:31 +00:00
|
|
|
const ModuleAnalysisManager *MAM;
|
2013-11-23 01:25:07 +00:00
|
|
|
};
|
|
|
|
|
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.
|
2015-01-13 11:13:56 +00:00
|
|
|
///
|
|
|
|
/// Function passes run within this adaptor can rely on having exclusive access
|
|
|
|
/// to the function they are run over. They should not read or modify any other
|
|
|
|
/// functions! Other threads or systems may be manipulating other functions in
|
|
|
|
/// the module, and so their state should never be relied on.
|
|
|
|
/// FIXME: Make the above true for all of LLVM's actual passes, some still
|
|
|
|
/// violate this principle.
|
|
|
|
///
|
|
|
|
/// Function passes can also read the module containing the function, but they
|
|
|
|
/// should not modify that module outside of the use lists of various globals.
|
|
|
|
/// For example, a function pass is not permitted to add functions to the
|
|
|
|
/// module.
|
|
|
|
/// FIXME: Make the above true for all of LLVM's actual passes, some still
|
|
|
|
/// violate this principle.
|
2014-03-10 01:42:03 +00:00
|
|
|
template <typename FunctionPassT> class ModuleToFunctionPassAdaptor {
|
2013-11-21 02:11:31 +00:00
|
|
|
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)) {}
|
2014-03-10 00:50:56 +00:00
|
|
|
// We have to explicitly define all the special member functions because MSVC
|
|
|
|
// refuses to generate them.
|
2014-03-10 00:35:47 +00:00
|
|
|
ModuleToFunctionPassAdaptor(const ModuleToFunctionPassAdaptor &Arg)
|
|
|
|
: Pass(Arg.Pass) {}
|
|
|
|
ModuleToFunctionPassAdaptor(ModuleToFunctionPassAdaptor &&Arg)
|
|
|
|
: Pass(std::move(Arg.Pass)) {}
|
2015-01-02 22:51:44 +00:00
|
|
|
friend void swap(ModuleToFunctionPassAdaptor &LHS,
|
|
|
|
ModuleToFunctionPassAdaptor &RHS) {
|
2014-03-13 10:42:18 +00:00
|
|
|
using std::swap;
|
|
|
|
swap(LHS.Pass, RHS.Pass);
|
|
|
|
}
|
2014-03-10 00:35:47 +00:00
|
|
|
ModuleToFunctionPassAdaptor &operator=(ModuleToFunctionPassAdaptor RHS) {
|
2014-03-13 10:42:18 +00:00
|
|
|
swap(*this, RHS);
|
2014-03-10 00:35:47 +00:00
|
|
|
return *this;
|
|
|
|
}
|
2013-11-21 02:11:31 +00:00
|
|
|
|
|
|
|
/// \brief Runs the function pass across every function in the module.
|
2015-01-05 02:47:05 +00:00
|
|
|
PreservedAnalyses run(Module &M, ModuleAnalysisManager *AM) {
|
2014-04-09 06:08:46 +00:00
|
|
|
FunctionAnalysisManager *FAM = nullptr;
|
[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
|
|
|
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();
|
2015-02-01 10:40:21 +00:00
|
|
|
for (Function &F : M) {
|
2015-02-01 10:47:25 +00:00
|
|
|
if (F.isDeclaration())
|
|
|
|
continue;
|
|
|
|
|
2015-02-01 10:40:21 +00:00
|
|
|
PreservedAnalyses PassPA = Pass.run(F, 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
|
[PM] Fix a pretty nasty bug where the new pass manager would invalidate
passes too many time.
I think this is actually the issue that someone raised with me at the
developer's meeting and in an email, but that we never really got to the
bottom of. Having all the testing utilities made it much easier to dig
down and uncover the core issue.
When a pass manager is running many passes over a single function, we
need it to invalidate the analyses between each run so that they can be
re-computed as needed. We also need to track the intersection of
preserved higher-level analyses across all the passes that we run (for
example, if there is one module analysis which all the function analyses
preserve, we want to track that and propagate it). Unfortunately, this
interacted poorly with any enclosing pass adaptor between two IR units.
It would see the intersection of preserved analyses, and need to
invalidate any other analyses, but some of the un-preserved analyses
might have already been invalidated *and recomputed*! We would fail to
propagate the fact that the analysis had already been invalidated.
The solution to this struck me as really strange at first, but the more
I thought about it, the more natural it seemed. After a nice discussion
with Duncan about it on IRC, it seemed even nicer. The idea is that
invalidating an analysis *causes* it to be preserved! Preserving the
lack of result is trivial. If it is recomputed, great. Until something
*else* invalidates it again, we're good.
The consequence of this is that the invalidate methods on the analysis
manager which operate over many passes now consume their
PreservedAnalyses object, update it to "preserve" every analysis pass to
which it delivers an invalidation (regardless of whether the pass
chooses to be removed, or handles the invalidation itself by updating
itself). Then we return this augmented set from the invalidate routine,
letting the pass manager take the result and use the intersection of
*that* across each pass run to compute the final preserved set. This
accounts for all the places where the early invalidation of an analysis
has already "preserved" it for a future run.
I've beefed up the testing and adjusted the assertions to show that we
no longer repeatedly invalidate or compute the analyses across nested
pass managers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225333 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-07 01:58:35 +00:00
|
|
|
// directly handle the function analysis manager's invalidation here and
|
|
|
|
// update our preserved set to reflect that these have already been
|
|
|
|
// handled.
|
2013-11-22 23:38:07 +00:00
|
|
|
if (FAM)
|
2015-02-01 10:40:21 +00:00
|
|
|
PassPA = FAM->invalidate(F, std::move(PassPA));
|
2013-11-22 23:38:07 +00:00
|
|
|
|
|
|
|
// 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-09 11:49:53 +00:00
|
|
|
return std::move(ModuleToFunctionPassAdaptor<FunctionPassT>(std::move(Pass)));
|
2013-11-21 02:11:31 +00:00
|
|
|
}
|
|
|
|
|
2015-01-06 02:10:51 +00:00
|
|
|
/// \brief A template utility pass to force an analysis result to be available.
|
|
|
|
///
|
|
|
|
/// This is a no-op pass which simply forces a specific analysis pass's result
|
|
|
|
/// to be available when it is run.
|
2015-01-07 11:14:51 +00:00
|
|
|
template <typename AnalysisT> struct RequireAnalysisPass {
|
2015-01-06 02:10:51 +00:00
|
|
|
/// \brief Run this pass over some unit of IR.
|
|
|
|
///
|
|
|
|
/// This pass can be run over any unit of IR and use any analysis manager
|
|
|
|
/// provided they satisfy the basic API requirements. When this pass is
|
|
|
|
/// created, these methods can be instantiated to satisfy whatever the
|
|
|
|
/// context requires.
|
2015-01-13 11:31:43 +00:00
|
|
|
template <typename IRUnitT>
|
|
|
|
PreservedAnalyses run(IRUnitT &Arg, AnalysisManager<IRUnitT> *AM) {
|
2015-01-06 02:10:51 +00:00
|
|
|
if (AM)
|
[PM] Sink the reference vs. value decision for IR units out of the
templated interface.
So far, every single IR unit I can come up with has address-identity.
That is, when two units of IR are both active in LLVM, their addresses
will be distinct of the IR is distinct. This is clearly true for
Modules, Functions, BasicBlocks, and Instructions. It turns out that the
only practical way to make the CGSCC stuff work the way we want is to
make it true for SCCs as well. I expect this pattern to continue.
When first designing the pass manager code, I kept this dimension of
freedom in the type parameters, essentially allowing for a wrapper-type
whose address did not form identity. But that really no longer makes
sense and is making the code more complex or subtle for no gain. If we
ever have an actual use case for this, we can figure out what makes
sense then and there. It will be better because then we will have the
actual example in hand.
While the simplifications afforded in this patch are fairly small
(mostly sinking the '&' out of many type parameters onto a few
interfaces), it would have become much more pronounced with subsequent
changes. I have a sequence of changes that will completely remove the
code duplication that currently exists between all of the pass managers
and analysis managers. =] Should make things much cleaner and avoid bug
fixing N times for the N pass managers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225723 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-12 22:53:31 +00:00
|
|
|
(void)AM->template getResult<AnalysisT>(Arg);
|
2015-01-06 02:10:51 +00:00
|
|
|
|
|
|
|
return PreservedAnalyses::all();
|
|
|
|
}
|
|
|
|
|
2015-01-07 11:14:51 +00:00
|
|
|
static StringRef name() { return "RequireAnalysisPass"; }
|
2015-01-06 02:10:51 +00:00
|
|
|
};
|
|
|
|
|
2015-01-06 04:49:44 +00:00
|
|
|
/// \brief A template utility pass to force an analysis result to be
|
|
|
|
/// invalidated.
|
|
|
|
///
|
|
|
|
/// This is a no-op pass which simply forces a specific analysis result to be
|
|
|
|
/// invalidated when it is run.
|
2015-01-07 11:14:51 +00:00
|
|
|
template <typename AnalysisT> struct InvalidateAnalysisPass {
|
2015-01-06 04:49:44 +00:00
|
|
|
/// \brief Run this pass over some unit of IR.
|
|
|
|
///
|
|
|
|
/// This pass can be run over any unit of IR and use any analysis manager
|
|
|
|
/// provided they satisfy the basic API requirements. When this pass is
|
|
|
|
/// created, these methods can be instantiated to satisfy whatever the
|
|
|
|
/// context requires.
|
2015-01-13 11:31:43 +00:00
|
|
|
template <typename IRUnitT>
|
|
|
|
PreservedAnalyses run(IRUnitT &Arg, AnalysisManager<IRUnitT> *AM) {
|
2015-01-06 04:49:44 +00:00
|
|
|
if (AM)
|
|
|
|
// We have to directly invalidate the analysis result as we can't
|
|
|
|
// enumerate all other analyses and use the preserved set to control it.
|
[PM] Sink the reference vs. value decision for IR units out of the
templated interface.
So far, every single IR unit I can come up with has address-identity.
That is, when two units of IR are both active in LLVM, their addresses
will be distinct of the IR is distinct. This is clearly true for
Modules, Functions, BasicBlocks, and Instructions. It turns out that the
only practical way to make the CGSCC stuff work the way we want is to
make it true for SCCs as well. I expect this pattern to continue.
When first designing the pass manager code, I kept this dimension of
freedom in the type parameters, essentially allowing for a wrapper-type
whose address did not form identity. But that really no longer makes
sense and is making the code more complex or subtle for no gain. If we
ever have an actual use case for this, we can figure out what makes
sense then and there. It will be better because then we will have the
actual example in hand.
While the simplifications afforded in this patch are fairly small
(mostly sinking the '&' out of many type parameters onto a few
interfaces), it would have become much more pronounced with subsequent
changes. I have a sequence of changes that will completely remove the
code duplication that currently exists between all of the pass managers
and analysis managers. =] Should make things much cleaner and avoid bug
fixing N times for the N pass managers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225723 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-12 22:53:31 +00:00
|
|
|
(void)AM->template invalidate<AnalysisT>(Arg);
|
2015-01-06 04:49:44 +00:00
|
|
|
|
|
|
|
return PreservedAnalyses::all();
|
|
|
|
}
|
|
|
|
|
2015-01-07 11:14:51 +00:00
|
|
|
static StringRef name() { return "InvalidateAnalysisPass"; }
|
2015-01-06 04:49:44 +00:00
|
|
|
};
|
|
|
|
|
2015-01-06 09:06:35 +00:00
|
|
|
/// \brief A utility pass that does nothing but preserves no analyses.
|
|
|
|
///
|
|
|
|
/// As a consequence fo not preserving any analyses, this pass will force all
|
|
|
|
/// analysis passes to be re-run to produce fresh results if any are needed.
|
|
|
|
struct InvalidateAllAnalysesPass {
|
|
|
|
/// \brief Run this pass over some unit of IR.
|
2015-01-13 01:44:56 +00:00
|
|
|
template <typename IRUnitT> PreservedAnalyses run(IRUnitT &Arg) {
|
2015-01-06 09:06:35 +00:00
|
|
|
return PreservedAnalyses::none();
|
|
|
|
}
|
|
|
|
|
|
|
|
static StringRef name() { return "InvalidateAllAnalysesPass"; }
|
|
|
|
};
|
|
|
|
|
2013-11-09 13:09:08 +00:00
|
|
|
}
|
2014-01-11 10:59:00 +00:00
|
|
|
|
|
|
|
#endif
|