2013-11-14 11:55:14 +01:00
|
|
|
//===- PassManager.h - Pass management infrastructure -----------*- C++ -*-===//
|
2013-11-09 14:09:08 +01:00
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
/// \file
|
|
|
|
///
|
|
|
|
/// This header defines various interfaces for pass management in LLVM. There
|
|
|
|
/// is no "pass" interface in LLVM per se. Instead, an instance of any class
|
|
|
|
/// which supports a method to 'run' it over a unit of IR can be used as
|
|
|
|
/// a pass. A pass manager is generally a tool to collect a sequence of passes
|
|
|
|
/// which run over a particular IR construct, and run each of them in sequence
|
|
|
|
/// over each such construct in the containing IR construct. As there is no
|
|
|
|
/// containing IR construct for a Module, a manager for passes over modules
|
|
|
|
/// forms the base case which runs its managed passes in sequence over the
|
|
|
|
/// single module provided.
|
|
|
|
///
|
|
|
|
/// The core IR library provides managers for running passes over
|
|
|
|
/// modules and functions.
|
|
|
|
///
|
|
|
|
/// * FunctionPassManager can run over a Module, runs each pass over
|
|
|
|
/// a Function.
|
|
|
|
/// * ModulePassManager must be directly run, runs each pass over the Module.
|
|
|
|
///
|
2013-11-13 02:51:36 +01:00
|
|
|
/// Note that the implementations of the pass managers use concept-based
|
|
|
|
/// polymorphism as outlined in the "Value Semantics and Concept-based
|
|
|
|
/// Polymorphism" talk (or its abbreviated sibling "Inheritance Is The Base
|
|
|
|
/// Class of Evil") by Sean Parent:
|
|
|
|
/// * http://github.com/sean-parent/sean-parent.github.com/wiki/Papers-and-Presentations
|
2013-11-13 03:49:38 +01:00
|
|
|
/// * http://www.youtube.com/watch?v=_BpMYeUFXv8
|
2013-11-13 02:51:36 +01:00
|
|
|
/// * http://channel9.msdn.com/Events/GoingNative/2013/Inheritance-Is-The-Base-Class-of-Evil
|
|
|
|
///
|
2013-11-09 14:09:08 +01:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2014-08-13 18:26:38 +02:00
|
|
|
#ifndef LLVM_IR_PASSMANAGER_H
|
|
|
|
#define LLVM_IR_PASSMANAGER_H
|
2014-01-11 11:59:00 +01:00
|
|
|
|
2013-11-13 02:12:08 +01:00
|
|
|
#include "llvm/ADT/DenseMap.h"
|
2014-03-09 12:49:53 +01:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2013-11-20 12:31:50 +01:00
|
|
|
#include "llvm/ADT/SmallPtrSet.h"
|
2016-12-27 09:40:39 +01:00
|
|
|
#include "llvm/ADT/TinyPtrVector.h"
|
2013-11-13 02:12:08 +01:00
|
|
|
#include "llvm/IR/Function.h"
|
2013-11-09 14:09:08 +01:00
|
|
|
#include "llvm/IR/Module.h"
|
2015-01-03 00:25:16 +01:00
|
|
|
#include "llvm/IR/PassManagerInternal.h"
|
2015-01-13 03:51:47 +01:00
|
|
|
#include "llvm/Support/Debug.h"
|
2016-02-25 11:27:39 +01:00
|
|
|
#include "llvm/Support/TypeName.h"
|
2015-03-23 19:23:08 +01:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2014-01-07 12:48:04 +01:00
|
|
|
#include "llvm/Support/type_traits.h"
|
2013-11-13 02:12:08 +01:00
|
|
|
#include <list>
|
2014-03-09 12:49:53 +01:00
|
|
|
#include <memory>
|
2013-11-09 14:09:08 +01:00
|
|
|
#include <vector>
|
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
|
2016-11-23 18:53:26 +01:00
|
|
|
/// A special type used by analysis passes to provide an address that
|
|
|
|
/// identifies that particular analysis pass type.
|
|
|
|
///
|
|
|
|
/// Analysis passes should have a static data member of this type and derive
|
|
|
|
/// from the \c AnalysisInfoMixin to get a static ID method used to identify
|
|
|
|
/// the analysis in the pass management infrastructure.
|
|
|
|
struct alignas(8) AnalysisKey {};
|
|
|
|
|
2016-12-27 09:40:39 +01:00
|
|
|
/// A special type used to provide an address that identifies a set of related
|
2017-01-05 01:12:51 +01:00
|
|
|
/// analyses. These sets are primarily used below to mark sets of analyses as
|
|
|
|
/// preserved.
|
2013-11-20 12:31:50 +01:00
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// For example, a transformation can indicate that it preserves the CFG of a
|
|
|
|
/// function by preserving the appropriate AnalysisSetKey. An analysis that
|
|
|
|
/// depends only on the CFG can then check if that AnalysisSetKey is preserved;
|
|
|
|
/// if it is, the analysis knows that it itself is preserved.
|
2016-12-27 09:40:39 +01:00
|
|
|
struct alignas(8) AnalysisSetKey {};
|
|
|
|
|
2017-01-15 07:32:49 +01:00
|
|
|
/// This templated class represents "all analyses that operate over \<a
|
|
|
|
/// particular IR unit\>" (e.g. a Function or a Module) in instances of
|
|
|
|
/// PreservedAnalysis.
|
|
|
|
///
|
|
|
|
/// This lets a transformation say e.g. "I preserved all function analyses".
|
|
|
|
///
|
|
|
|
/// Note that you must provide an explicit instantiation declaration and
|
|
|
|
/// definition for this template in order to get the correct behavior on
|
|
|
|
/// Windows. Otherwise, the address of SetKey will not be stable.
|
|
|
|
template <typename IRUnitT> class AllAnalysesOn {
|
|
|
|
public:
|
|
|
|
static AnalysisSetKey *ID() { return &SetKey; }
|
|
|
|
|
|
|
|
private:
|
|
|
|
static AnalysisSetKey SetKey;
|
|
|
|
};
|
|
|
|
|
|
|
|
template <typename IRUnitT> AnalysisSetKey AllAnalysesOn<IRUnitT>::SetKey;
|
|
|
|
|
|
|
|
extern template class AllAnalysesOn<Module>;
|
|
|
|
extern template class AllAnalysesOn<Function>;
|
|
|
|
|
|
|
|
/// Represents analyses that only rely on functions' control flow.
|
|
|
|
///
|
|
|
|
/// This can be used with \c PreservedAnalyses to mark the CFG as preserved and
|
|
|
|
/// to query whether it has been preserved.
|
|
|
|
///
|
|
|
|
/// The CFG of a function is defined as the set of basic blocks and the edges
|
|
|
|
/// between them. Changing the set of basic blocks in a function is enough to
|
|
|
|
/// mutate the CFG. Mutating the condition of a branch or argument of an
|
|
|
|
/// invoked function does not mutate the CFG, but changing the successor labels
|
|
|
|
/// of those instructions does.
|
|
|
|
class CFGAnalyses {
|
|
|
|
public:
|
|
|
|
static AnalysisSetKey *ID() { return &SetKey; }
|
|
|
|
|
|
|
|
private:
|
|
|
|
static AnalysisSetKey SetKey;
|
|
|
|
};
|
|
|
|
|
2017-01-05 01:12:51 +01:00
|
|
|
/// A set of analyses that are preserved following a run of a transformation
|
|
|
|
/// pass.
|
2013-11-20 12:31:50 +01:00
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// Transformation passes build and return these objects to communicate which
|
|
|
|
/// analyses are still valid after the transformation. For most passes this is
|
|
|
|
/// fairly simple: if they don't change anything all analyses are preserved,
|
2016-12-27 09:40:39 +01:00
|
|
|
/// otherwise only a short list of analyses that have been explicitly updated
|
|
|
|
/// are preserved.
|
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// This class also lets transformation passes mark abstract *sets* of analyses
|
|
|
|
/// as preserved. A transformation that (say) does not alter the CFG can
|
|
|
|
/// indicate such by marking a particular AnalysisSetKey as preserved, and
|
|
|
|
/// then analyses can query whether that AnalysisSetKey is preserved.
|
2016-12-27 09:40:39 +01:00
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// Finally, this class can represent an "abandoned" analysis, which is
|
|
|
|
/// not preserved even if it would be covered by some abstract set of analyses.
|
2016-12-27 09:40:39 +01:00
|
|
|
///
|
|
|
|
/// Given a `PreservedAnalyses` object, an analysis will typically want to
|
|
|
|
/// figure out whether it is preserved. In the example below, MyAnalysisType is
|
|
|
|
/// preserved if it's not abandoned, and (a) it's explicitly marked as
|
|
|
|
/// preserved, (b), the set AllAnalysesOn<MyIRUnit> is preserved, or (c) both
|
|
|
|
/// AnalysisSetA and AnalysisSetB are preserved.
|
|
|
|
///
|
|
|
|
/// ```
|
|
|
|
/// auto PAC = PA.getChecker<MyAnalysisType>();
|
|
|
|
/// if (PAC.preserved() || PAC.preservedSet<AllAnalysesOn<MyIRUnit>>() ||
|
|
|
|
/// (PAC.preservedSet<AnalysisSetA>() &&
|
|
|
|
/// PAC.preservedSet<AnalysisSetB>())) {
|
|
|
|
/// // The analysis has been successfully preserved ...
|
|
|
|
/// }
|
|
|
|
/// ```
|
2013-11-20 12:31:50 +01:00
|
|
|
class PreservedAnalyses {
|
|
|
|
public:
|
|
|
|
/// \brief Convenience factory function for the empty preserved set.
|
|
|
|
static PreservedAnalyses none() { return PreservedAnalyses(); }
|
|
|
|
|
|
|
|
/// \brief Construct a special preserved set that preserves all passes.
|
|
|
|
static PreservedAnalyses all() {
|
|
|
|
PreservedAnalyses PA;
|
2016-12-27 09:40:39 +01:00
|
|
|
PA.PreservedIDs.insert(&AllAnalysesKey);
|
2013-11-20 12:31:50 +01:00
|
|
|
return PA;
|
|
|
|
}
|
|
|
|
|
2016-12-27 09:40:39 +01:00
|
|
|
/// Mark an analysis as preserved.
|
|
|
|
template <typename AnalysisT> void preserve() { preserve(AnalysisT::ID()); }
|
[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.
llvm-svn: 225333
2015-01-07 02:58:35 +01:00
|
|
|
|
2017-01-05 01:12:51 +01:00
|
|
|
/// \brief Given an analysis's ID, mark the analysis as preserved, adding it
|
|
|
|
/// to the set.
|
2016-11-23 18:53:26 +01:00
|
|
|
void preserve(AnalysisKey *ID) {
|
2016-12-27 09:40:39 +01:00
|
|
|
// Clear this ID from the explicit not-preserved set if present.
|
|
|
|
NotPreservedAnalysisIDs.erase(ID);
|
|
|
|
|
|
|
|
// If we're not already preserving all analyses (other than those in
|
|
|
|
// NotPreservedAnalysisIDs).
|
2013-11-20 12:31:50 +01:00
|
|
|
if (!areAllPreserved())
|
2016-12-27 09:40:39 +01:00
|
|
|
PreservedIDs.insert(ID);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Mark an analysis set as preserved.
|
|
|
|
template <typename AnalysisSetT> void preserveSet() {
|
|
|
|
preserveSet(AnalysisSetT::ID());
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Mark an analysis set as preserved using its ID.
|
|
|
|
void preserveSet(AnalysisSetKey *ID) {
|
|
|
|
// If we're not already in the saturated 'all' state, add this set.
|
|
|
|
if (!areAllPreserved())
|
|
|
|
PreservedIDs.insert(ID);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Mark an analysis as abandoned.
|
|
|
|
///
|
|
|
|
/// An abandoned analysis is not preserved, even if it is nominally covered
|
|
|
|
/// by some other set or was previously explicitly marked as preserved.
|
|
|
|
///
|
|
|
|
/// Note that you can only abandon a specific analysis, not a *set* of
|
|
|
|
/// analyses.
|
|
|
|
template <typename AnalysisT> void abandon() { abandon(AnalysisT::ID()); }
|
|
|
|
|
|
|
|
/// Mark an analysis as abandoned using its ID.
|
|
|
|
///
|
|
|
|
/// An abandoned analysis is not preserved, even if it is nominally covered
|
|
|
|
/// by some other set or was previously explicitly marked as preserved.
|
|
|
|
///
|
|
|
|
/// Note that you can only abandon a specific analysis, not a *set* of
|
|
|
|
/// analyses.
|
|
|
|
void abandon(AnalysisKey *ID) {
|
|
|
|
PreservedIDs.erase(ID);
|
|
|
|
NotPreservedAnalysisIDs.insert(ID);
|
2013-11-20 12:31:50 +01: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()) {
|
2016-12-27 09:40:39 +01:00
|
|
|
*this = Arg;
|
2013-11-20 12:31:50 +01:00
|
|
|
return;
|
|
|
|
}
|
2016-12-27 09:40:39 +01:00
|
|
|
// The intersection requires the *union* of the explicitly not-preserved
|
|
|
|
// IDs and the *intersection* of the preserved IDs.
|
|
|
|
for (auto ID : Arg.NotPreservedAnalysisIDs) {
|
|
|
|
PreservedIDs.erase(ID);
|
|
|
|
NotPreservedAnalysisIDs.insert(ID);
|
|
|
|
}
|
|
|
|
for (auto ID : PreservedIDs)
|
|
|
|
if (!Arg.PreservedIDs.count(ID))
|
|
|
|
PreservedIDs.erase(ID);
|
2013-11-20 12:31:50 +01: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()) {
|
2016-12-27 09:40:39 +01:00
|
|
|
*this = std::move(Arg);
|
2013-11-20 12:31:50 +01:00
|
|
|
return;
|
|
|
|
}
|
2016-12-27 09:40:39 +01:00
|
|
|
// The intersection requires the *union* of the explicitly not-preserved
|
|
|
|
// IDs and the *intersection* of the preserved IDs.
|
|
|
|
for (auto ID : Arg.NotPreservedAnalysisIDs) {
|
|
|
|
PreservedIDs.erase(ID);
|
|
|
|
NotPreservedAnalysisIDs.insert(ID);
|
|
|
|
}
|
|
|
|
for (auto ID : PreservedIDs)
|
|
|
|
if (!Arg.PreservedIDs.count(ID))
|
|
|
|
PreservedIDs.erase(ID);
|
2013-11-20 12:31:50 +01:00
|
|
|
}
|
|
|
|
|
2016-12-27 09:40:39 +01:00
|
|
|
/// A checker object that makes it easy to query for whether an analysis or
|
|
|
|
/// some set covering it is preserved.
|
|
|
|
class PreservedAnalysisChecker {
|
|
|
|
friend class PreservedAnalyses;
|
|
|
|
|
|
|
|
const PreservedAnalyses &PA;
|
|
|
|
AnalysisKey *const ID;
|
|
|
|
const bool IsAbandoned;
|
|
|
|
|
|
|
|
/// A PreservedAnalysisChecker is tied to a particular Analysis because
|
|
|
|
/// `preserved()` and `preservedSet()` both return false if the Analysis
|
|
|
|
/// was abandoned.
|
|
|
|
PreservedAnalysisChecker(const PreservedAnalyses &PA, AnalysisKey *ID)
|
|
|
|
: PA(PA), ID(ID), IsAbandoned(PA.NotPreservedAnalysisIDs.count(ID)) {}
|
|
|
|
|
|
|
|
public:
|
2017-01-05 01:12:51 +01:00
|
|
|
/// Returns true if the checker's analysis was not abandoned and either
|
|
|
|
/// - the analysis is explicitly preserved or
|
|
|
|
/// - all analyses are preserved.
|
2016-12-27 09:40:39 +01:00
|
|
|
bool preserved() {
|
|
|
|
return !IsAbandoned && (PA.PreservedIDs.count(&AllAnalysesKey) ||
|
|
|
|
PA.PreservedIDs.count(ID));
|
|
|
|
}
|
2013-11-20 12:31:50 +01:00
|
|
|
|
2017-01-05 01:12:51 +01:00
|
|
|
/// Returns true if the checker's analysis was not abandoned and either
|
|
|
|
/// - \p AnalysisSetT is explicitly preserved or
|
|
|
|
/// - all analyses are preserved.
|
2016-12-27 09:40:39 +01:00
|
|
|
template <typename AnalysisSetT> bool preservedSet() {
|
|
|
|
AnalysisSetKey *SetID = AnalysisSetT::ID();
|
|
|
|
return !IsAbandoned && (PA.PreservedIDs.count(&AllAnalysesKey) ||
|
|
|
|
PA.PreservedIDs.count(SetID));
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
/// Build a checker for this `PreservedAnalyses` and the specified analysis
|
|
|
|
/// type.
|
|
|
|
///
|
|
|
|
/// You can use the returned object to query whether an analysis was
|
|
|
|
/// preserved. See the example in the comment on `PreservedAnalysis`.
|
|
|
|
template <typename AnalysisT> PreservedAnalysisChecker getChecker() const {
|
|
|
|
return PreservedAnalysisChecker(*this, AnalysisT::ID());
|
2013-11-20 12:31:50 +01:00
|
|
|
}
|
|
|
|
|
2016-12-27 09:40:39 +01:00
|
|
|
/// Build a checker for this `PreservedAnalyses` and the specified analysis
|
|
|
|
/// ID.
|
|
|
|
///
|
|
|
|
/// You can use the returned object to query whether an analysis was
|
|
|
|
/// preserved. See the example in the comment on `PreservedAnalysis`.
|
|
|
|
PreservedAnalysisChecker getChecker(AnalysisKey *ID) const {
|
|
|
|
return PreservedAnalysisChecker(*this, ID);
|
2016-05-03 23:35:08 +02:00
|
|
|
}
|
|
|
|
|
2016-12-27 09:40:39 +01:00
|
|
|
/// Test whether all analyses are preserved (and none are abandoned).
|
2015-01-05 13:32:11 +01:00
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// This is used primarily to optimize for the common case of a transformation
|
|
|
|
/// which makes no changes to the IR.
|
2015-01-05 13:32:11 +01:00
|
|
|
bool areAllPreserved() const {
|
2016-12-27 09:40:39 +01:00
|
|
|
return NotPreservedAnalysisIDs.empty() &&
|
|
|
|
PreservedIDs.count(&AllAnalysesKey);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Directly test whether a set of analyses is preserved.
|
|
|
|
///
|
|
|
|
/// This is only true when no analyses have been explicitly abandoned.
|
|
|
|
template <typename AnalysisSetT> bool allAnalysesInSetPreserved() const {
|
|
|
|
return allAnalysesInSetPreserved(AnalysisSetT::ID());
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Directly test whether a set of analyses is preserved.
|
|
|
|
///
|
|
|
|
/// This is only true when no analyses have been explicitly abandoned.
|
|
|
|
bool allAnalysesInSetPreserved(AnalysisSetKey *SetID) const {
|
|
|
|
return NotPreservedAnalysisIDs.empty() &&
|
|
|
|
(PreservedIDs.count(&AllAnalysesKey) || PreservedIDs.count(SetID));
|
2015-01-05 13:32:11 +01:00
|
|
|
}
|
|
|
|
|
2013-11-20 12:31:50 +01:00
|
|
|
private:
|
2016-12-27 09:40:39 +01:00
|
|
|
/// A special key used to indicate all analyses.
|
|
|
|
static AnalysisSetKey AllAnalysesKey;
|
2013-11-20 12:31:50 +01:00
|
|
|
|
2016-12-27 09:40:39 +01:00
|
|
|
/// The IDs of analyses and analysis sets that are preserved.
|
|
|
|
SmallPtrSet<void *, 2> PreservedIDs;
|
|
|
|
|
|
|
|
/// The IDs of explicitly not-preserved analyses.
|
|
|
|
///
|
|
|
|
/// If an analysis in this set is covered by a set in `PreservedIDs`, we
|
|
|
|
/// consider it not-preserved. That is, `NotPreservedAnalysisIDs` always
|
|
|
|
/// "wins" over analysis sets in `PreservedIDs`.
|
|
|
|
///
|
|
|
|
/// Also, a given ID should never occur both here and in `PreservedIDs`.
|
|
|
|
SmallPtrSet<AnalysisKey *, 2> NotPreservedAnalysisIDs;
|
2013-11-20 12:31:50 +01:00
|
|
|
};
|
|
|
|
|
2015-01-13 22:30:27 +01:00
|
|
|
// Forward declare the analysis manager template.
|
2016-08-19 20:36:06 +02:00
|
|
|
template <typename IRUnitT, typename... ExtraArgTs> class AnalysisManager;
|
2013-11-13 02:12:08 +01:00
|
|
|
|
2016-03-11 11:33:22 +01:00
|
|
|
/// A CRTP mix-in to automatically provide informational APIs needed for
|
|
|
|
/// passes.
|
2016-02-26 12:44:45 +01:00
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// This provides some boilerplate for types that are passes.
|
2016-03-11 11:33:22 +01:00
|
|
|
template <typename DerivedT> struct PassInfoMixin {
|
2017-01-05 01:12:51 +01:00
|
|
|
/// Gets the name of the pass we are mixed into.
|
2016-02-26 12:44:45 +01:00
|
|
|
static StringRef name() {
|
2017-02-07 02:50:48 +01:00
|
|
|
static_assert(std::is_base_of<PassInfoMixin, DerivedT>::value,
|
|
|
|
"Must pass the derived type as the template argument!");
|
2016-02-26 12:44:45 +01:00
|
|
|
StringRef Name = getTypeName<DerivedT>();
|
|
|
|
if (Name.startswith("llvm::"))
|
|
|
|
Name = Name.drop_front(strlen("llvm::"));
|
|
|
|
return Name;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2017-01-05 01:12:51 +01:00
|
|
|
/// A CRTP mix-in that provides informational APIs needed for analysis passes.
|
2016-02-26 12:44:45 +01:00
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// This provides some boilerplate for types that are analysis passes. It
|
|
|
|
/// automatically mixes in \c PassInfoMixin.
|
2016-03-11 11:33:22 +01:00
|
|
|
template <typename DerivedT>
|
|
|
|
struct AnalysisInfoMixin : PassInfoMixin<DerivedT> {
|
2016-11-23 18:53:26 +01:00
|
|
|
/// Returns an opaque, unique ID for this analysis type.
|
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// This ID is a pointer type that is guaranteed to be 8-byte aligned and thus
|
|
|
|
/// suitable for use in sets, maps, and other data structures that use the low
|
|
|
|
/// bits of pointers.
|
2016-03-11 11:22:49 +01:00
|
|
|
///
|
2016-11-23 18:53:26 +01:00
|
|
|
/// Note that this requires the derived type provide a static \c AnalysisKey
|
|
|
|
/// member called \c Key.
|
2016-03-11 11:22:49 +01:00
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// FIXME: The only reason the mixin type itself can't declare the Key value
|
|
|
|
/// is that some compilers cannot correctly unique a templated static variable
|
|
|
|
/// so it has the same addresses in each instantiation. The only currently
|
|
|
|
/// known platform with this limitation is Windows DLL builds, specifically
|
|
|
|
/// building each part of LLVM as a DLL. If we ever remove that build
|
|
|
|
/// configuration, this mixin can provide the static key as well.
|
2017-02-07 02:50:48 +01:00
|
|
|
static AnalysisKey *ID() {
|
|
|
|
static_assert(std::is_base_of<AnalysisInfoMixin, DerivedT>::value,
|
|
|
|
"Must pass the derived type as the template argument!");
|
|
|
|
return &DerivedT::Key;
|
|
|
|
}
|
2016-02-26 12:44:45 +01:00
|
|
|
};
|
|
|
|
|
2017-01-05 01:12:51 +01:00
|
|
|
/// \brief Manages a sequence of passes over a particular unit of IR.
|
2015-01-03 00:34:39 +01:00
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// A pass manager contains a sequence of passes to run over a particular unit
|
|
|
|
/// of IR (e.g. Functions, Modules). It is itself a valid pass over that unit of
|
|
|
|
/// IR, and when run over some given IR will run each of its contained passes in
|
|
|
|
/// sequence. Pass managers are the primary and most basic building block of a
|
|
|
|
/// pass pipeline.
|
2015-01-03 00:34:39 +01:00
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// When you run a pass manager, you provide an \c AnalysisManager<IRUnitT>
|
|
|
|
/// argument. The pass manager will propagate that analysis manager to each
|
|
|
|
/// pass it runs, and will call the analysis manager's invalidation routine with
|
|
|
|
/// the PreservedAnalyses of each pass it runs.
|
2016-08-19 20:36:06 +02:00
|
|
|
template <typename IRUnitT,
|
|
|
|
typename AnalysisManagerT = AnalysisManager<IRUnitT>,
|
|
|
|
typename... ExtraArgTs>
|
|
|
|
class PassManager : public PassInfoMixin<
|
|
|
|
PassManager<IRUnitT, AnalysisManagerT, ExtraArgTs...>> {
|
2013-11-09 14:09:08 +01:00
|
|
|
public:
|
2015-01-13 23:42:38 +01:00
|
|
|
/// \brief Construct a pass manager.
|
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// If \p DebugLogging is true, we'll log our progress to llvm::dbgs().
|
2016-12-03 20:49:15 +01:00
|
|
|
explicit PassManager(bool DebugLogging = false) : DebugLogging(DebugLogging) {}
|
|
|
|
|
2016-10-24 20:11:05 +02:00
|
|
|
// FIXME: These are equivalent to the default move constructor/move
|
|
|
|
// assignment. However, using = default triggers linker errors due to the
|
|
|
|
// explicit instantiations below. Find away to use the default and remove the
|
|
|
|
// duplicated code here.
|
2016-10-20 18:50:07 +02:00
|
|
|
PassManager(PassManager &&Arg)
|
|
|
|
: Passes(std::move(Arg.Passes)),
|
|
|
|
DebugLogging(std::move(Arg.DebugLogging)) {}
|
2017-01-05 01:12:51 +01:00
|
|
|
|
2016-10-20 18:50:07 +02:00
|
|
|
PassManager &operator=(PassManager &&RHS) {
|
|
|
|
Passes = std::move(RHS.Passes);
|
|
|
|
DebugLogging = std::move(RHS.DebugLogging);
|
|
|
|
return *this;
|
|
|
|
}
|
2014-03-10 01:35:47 +01:00
|
|
|
|
2017-01-05 01:12:51 +01:00
|
|
|
/// \brief Run all of the passes in this manager over the given unit of IR.
|
|
|
|
/// ExtraArgs are passed to each pass.
|
2016-08-19 20:36:06 +02:00
|
|
|
PreservedAnalyses run(IRUnitT &IR, AnalysisManagerT &AM,
|
|
|
|
ExtraArgTs... ExtraArgs) {
|
2015-01-13 12:13:56 +01:00
|
|
|
PreservedAnalyses PA = PreservedAnalyses::all();
|
2013-11-09 14:09:08 +01:00
|
|
|
|
2015-01-13 23:42:38 +01:00
|
|
|
if (DebugLogging)
|
2016-02-25 11:27:39 +01:00
|
|
|
dbgs() << "Starting " << getTypeName<IRUnitT>() << " pass manager run.\n";
|
2013-11-09 14:09:08 +01:00
|
|
|
|
2015-01-13 12:13:56 +01:00
|
|
|
for (unsigned Idx = 0, Size = Passes.size(); Idx != Size; ++Idx) {
|
2015-01-13 23:42:38 +01:00
|
|
|
if (DebugLogging)
|
2015-10-30 23:58:15 +01:00
|
|
|
dbgs() << "Running pass: " << Passes[Idx]->name() << " on "
|
|
|
|
<< IR.getName() << "\n";
|
2015-01-13 12:13:56 +01:00
|
|
|
|
2016-08-19 20:36:06 +02:00
|
|
|
PreservedAnalyses PassPA = Passes[Idx]->run(IR, AM, ExtraArgs...);
|
2015-01-13 12:13:56 +01:00
|
|
|
|
2016-03-11 12:05:24 +01:00
|
|
|
// Update the analysis manager as each pass runs and potentially
|
2016-11-28 11:42:21 +01:00
|
|
|
// invalidates analyses.
|
|
|
|
AM.invalidate(IR, PassPA);
|
2015-01-13 12:13:56 +01:00
|
|
|
|
2017-01-05 01:12:51 +01:00
|
|
|
// Finally, intersect the preserved analyses to compute the aggregate
|
2016-11-28 11:42:21 +01:00
|
|
|
// preserved set for this pass manager.
|
2015-01-13 12:13:56 +01:00
|
|
|
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 01:35:47 +01:00
|
|
|
|
2016-08-20 06:57:28 +02:00
|
|
|
// Invaliadtion was handled after each pass in the above loop for the
|
|
|
|
// current unit of IR. Therefore, the remaining analysis results in the
|
|
|
|
// AnalysisManager are preserved. We mark this with a set so that we don't
|
|
|
|
// need to inspect each one individually.
|
2016-12-27 09:40:39 +01:00
|
|
|
PA.preserveSet<AllAnalysesOn<IRUnitT>>();
|
2016-08-20 06:57:28 +02:00
|
|
|
|
2015-01-13 23:42:38 +01:00
|
|
|
if (DebugLogging)
|
2016-02-25 11:27:39 +01:00
|
|
|
dbgs() << "Finished " << getTypeName<IRUnitT>() << " pass manager run.\n";
|
2013-11-09 14:09:08 +01:00
|
|
|
|
2015-01-13 12:13:56 +01:00
|
|
|
return PA;
|
2014-03-10 01:35:47 +01:00
|
|
|
}
|
|
|
|
|
2015-01-13 12:13:56 +01:00
|
|
|
template <typename PassT> void addPass(PassT Pass) {
|
2016-08-19 20:36:06 +02:00
|
|
|
typedef detail::PassModel<IRUnitT, PassT, PreservedAnalyses,
|
|
|
|
AnalysisManagerT, ExtraArgTs...>
|
|
|
|
PassModelT;
|
2015-01-13 12:36:43 +01:00
|
|
|
Passes.emplace_back(new PassModelT(std::move(Pass)));
|
2013-11-09 14:09:08 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
2016-08-19 20:36:06 +02:00
|
|
|
typedef detail::PassConcept<IRUnitT, AnalysisManagerT, ExtraArgTs...>
|
|
|
|
PassConceptT;
|
2013-11-09 14:09:08 +01:00
|
|
|
|
2015-01-13 12:36:43 +01:00
|
|
|
std::vector<std::unique_ptr<PassConceptT>> Passes;
|
2015-01-13 23:42:38 +01:00
|
|
|
|
|
|
|
/// \brief Flag indicating whether we should do debug logging.
|
|
|
|
bool DebugLogging;
|
2013-11-09 14:09:08 +01:00
|
|
|
};
|
|
|
|
|
2016-02-27 11:45:35 +01:00
|
|
|
extern template class PassManager<Module>;
|
2015-01-13 12:13:56 +01:00
|
|
|
/// \brief Convenience typedef for a pass manager over modules.
|
|
|
|
typedef PassManager<Module> ModulePassManager;
|
|
|
|
|
2016-02-27 11:45:35 +01:00
|
|
|
extern template class PassManager<Function>;
|
2015-01-13 12:13:56 +01:00
|
|
|
/// \brief Convenience typedef for a pass manager over functions.
|
|
|
|
typedef PassManager<Function> FunctionPassManager;
|
|
|
|
|
2017-01-05 01:12:51 +01:00
|
|
|
/// \brief A container for analyses that lazily runs them and caches their
|
2016-08-19 10:31:47 +02:00
|
|
|
/// results.
|
2015-01-13 03:51:47 +01:00
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// This class can manage analyses for any IR unit where the address of the IR
|
|
|
|
/// unit sufficies as its identity.
|
2016-08-19 20:36:06 +02:00
|
|
|
template <typename IRUnitT, typename... ExtraArgTs> class AnalysisManager {
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
public:
|
|
|
|
class Invalidator;
|
|
|
|
|
|
|
|
private:
|
2017-01-05 01:12:51 +01:00
|
|
|
// Now that we've defined our invalidator, we can define the concept types.
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
typedef detail::AnalysisResultConcept<IRUnitT, PreservedAnalyses, Invalidator>
|
|
|
|
ResultConceptT;
|
|
|
|
typedef detail::AnalysisPassConcept<IRUnitT, PreservedAnalyses, Invalidator,
|
|
|
|
ExtraArgTs...>
|
|
|
|
PassConceptT;
|
|
|
|
|
2017-01-05 01:12:51 +01:00
|
|
|
/// \brief List of analysis pass IDs and associated concept pointers.
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
///
|
|
|
|
/// Requires iterators to be valid across appending new entries and arbitrary
|
2017-01-05 01:12:51 +01:00
|
|
|
/// erases. Provides the analysis ID to enable finding iterators to a given
|
|
|
|
/// entry in maps below, and provides the storage for the actual result
|
|
|
|
/// concept.
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
typedef std::list<std::pair<AnalysisKey *, std::unique_ptr<ResultConceptT>>>
|
|
|
|
AnalysisResultListT;
|
|
|
|
|
|
|
|
/// \brief Map type from IRUnitT pointer to our custom list type.
|
|
|
|
typedef DenseMap<IRUnitT *, AnalysisResultListT> AnalysisResultListMapT;
|
|
|
|
|
|
|
|
/// \brief Map type from a pair of analysis ID and IRUnitT pointer to an
|
2017-01-05 01:12:51 +01:00
|
|
|
/// iterator into a particular result list (which is where the actual analysis
|
|
|
|
/// result is stored).
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
typedef DenseMap<std::pair<AnalysisKey *, IRUnitT *>,
|
|
|
|
typename AnalysisResultListT::iterator>
|
|
|
|
AnalysisResultMapT;
|
2013-11-13 02:12:08 +01:00
|
|
|
|
2016-08-19 10:31:47 +02:00
|
|
|
public:
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
/// API to communicate dependencies between analyses during invalidation.
|
|
|
|
///
|
|
|
|
/// When an analysis result embeds handles to other analysis results, it
|
|
|
|
/// needs to be invalidated both when its own information isn't preserved and
|
2017-01-05 01:12:51 +01:00
|
|
|
/// when any of its embedded analysis results end up invalidated. We pass an
|
|
|
|
/// \c Invalidator object as an argument to \c invalidate() in order to let
|
|
|
|
/// the analysis results themselves define the dependency graph on the fly.
|
|
|
|
/// This lets us avoid building building an explicit representation of the
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
/// dependencies between analysis results.
|
|
|
|
class Invalidator {
|
|
|
|
public:
|
|
|
|
/// Trigger the invalidation of some other analysis pass if not already
|
2017-01-05 01:12:51 +01:00
|
|
|
/// handled and return whether it was in fact invalidated.
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
///
|
|
|
|
/// This is expected to be called from within a given analysis result's \c
|
|
|
|
/// invalidate method to trigger a depth-first walk of all inter-analysis
|
|
|
|
/// dependencies. The same \p IR unit and \p PA passed to that result's \c
|
|
|
|
/// invalidate method should in turn be provided to this routine.
|
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// The first time this is called for a given analysis pass, it will call
|
|
|
|
/// the corresponding result's \c invalidate method. Subsequent calls will
|
|
|
|
/// use a cache of the results of that initial call. It is an error to form
|
|
|
|
/// cyclic dependencies between analysis results.
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// This returns true if the given analysis's result is invalid. Any
|
|
|
|
/// dependecies on it will become invalid as a result.
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
template <typename PassT>
|
|
|
|
bool invalidate(IRUnitT &IR, const PreservedAnalyses &PA) {
|
2016-12-27 09:40:39 +01:00
|
|
|
typedef detail::AnalysisResultModel<IRUnitT, PassT,
|
|
|
|
typename PassT::Result,
|
|
|
|
PreservedAnalyses, Invalidator>
|
|
|
|
ResultModelT;
|
|
|
|
return invalidateImpl<ResultModelT>(PassT::ID(), IR, PA);
|
|
|
|
}
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
|
2016-12-27 09:40:39 +01:00
|
|
|
/// A type-erased variant of the above invalidate method with the same core
|
|
|
|
/// API other than passing an analysis ID rather than an analysis type
|
|
|
|
/// parameter.
|
|
|
|
///
|
|
|
|
/// This is sadly less efficient than the above routine, which leverages
|
|
|
|
/// the type parameter to avoid the type erasure overhead.
|
|
|
|
bool invalidate(AnalysisKey *ID, IRUnitT &IR, const PreservedAnalyses &PA) {
|
|
|
|
return invalidateImpl<>(ID, IR, PA);
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
friend class AnalysisManager;
|
|
|
|
|
|
|
|
template <typename ResultT = ResultConceptT>
|
|
|
|
bool invalidateImpl(AnalysisKey *ID, IRUnitT &IR,
|
|
|
|
const PreservedAnalyses &PA) {
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
// If we've already visited this pass, return true if it was invalidated
|
|
|
|
// and false otherwise.
|
2016-11-29 13:54:34 +01:00
|
|
|
auto IMapI = IsResultInvalidated.find(ID);
|
|
|
|
if (IMapI != IsResultInvalidated.end())
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
return IMapI->second;
|
|
|
|
|
|
|
|
// Otherwise look up the result object.
|
|
|
|
auto RI = Results.find({ID, &IR});
|
|
|
|
assert(RI != Results.end() &&
|
|
|
|
"Trying to invalidate a dependent result that isn't in the "
|
|
|
|
"manager's cache is always an error, likely due to a stale result "
|
|
|
|
"handle!");
|
|
|
|
|
2016-12-27 09:40:39 +01:00
|
|
|
auto &Result = static_cast<ResultT &>(*RI->second->second);
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
|
2017-01-05 01:12:51 +01:00
|
|
|
// Insert into the map whether the result should be invalidated and return
|
|
|
|
// that. Note that we cannot reuse IMapI and must do a fresh insert here,
|
|
|
|
// as calling invalidate could (recursively) insert things into the map,
|
|
|
|
// making any iterator or reference invalid.
|
2016-11-29 13:54:34 +01:00
|
|
|
bool Inserted;
|
2016-12-27 09:40:39 +01:00
|
|
|
std::tie(IMapI, Inserted) =
|
|
|
|
IsResultInvalidated.insert({ID, Result.invalidate(IR, PA, *this)});
|
2016-11-29 13:54:34 +01:00
|
|
|
(void)Inserted;
|
|
|
|
assert(Inserted && "Should not have already inserted this ID, likely "
|
|
|
|
"indicates a dependency cycle!");
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
return IMapI->second;
|
|
|
|
}
|
|
|
|
|
|
|
|
Invalidator(SmallDenseMap<AnalysisKey *, bool, 8> &IsResultInvalidated,
|
|
|
|
const AnalysisResultMapT &Results)
|
|
|
|
: IsResultInvalidated(IsResultInvalidated), Results(Results) {}
|
|
|
|
|
|
|
|
SmallDenseMap<AnalysisKey *, bool, 8> &IsResultInvalidated;
|
|
|
|
const AnalysisResultMapT &Results;
|
|
|
|
};
|
2016-08-19 10:31:47 +02:00
|
|
|
|
|
|
|
/// \brief Construct an empty analysis manager.
|
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// If \p DebugLogging is true, we'll log our progress to llvm::dbgs().
|
2016-08-19 10:31:47 +02:00
|
|
|
AnalysisManager(bool DebugLogging = false) : DebugLogging(DebugLogging) {}
|
2016-10-20 14:20:28 +02:00
|
|
|
AnalysisManager(AnalysisManager &&) = default;
|
|
|
|
AnalysisManager &operator=(AnalysisManager &&) = default;
|
2014-03-10 01:35:47 +01:00
|
|
|
|
2016-08-19 10:31:47 +02:00
|
|
|
/// \brief Returns true if the analysis manager has an empty results cache.
|
|
|
|
bool empty() const {
|
|
|
|
assert(AnalysisResults.empty() == AnalysisResultLists.empty() &&
|
|
|
|
"The storage and index of analysis results disagree on how many "
|
|
|
|
"there are!");
|
|
|
|
return AnalysisResults.empty();
|
|
|
|
}
|
|
|
|
|
2017-01-05 01:12:51 +01:00
|
|
|
/// \brief Clear any cached analysis results for a single unit of IR.
|
[PM] Introduce basic update capabilities to the new PM's CGSCC pass
manager, including both plumbing and logic to handle function pass
updates.
There are three fundamentally tied changes here:
1) Plumbing *some* mechanism for updating the CGSCC pass manager as the
CG changes while passes are running.
2) Changing the CGSCC pass manager infrastructure to have support for
the underlying graph to mutate mid-pass run.
3) Actually updating the CG after function passes run.
I can separate them if necessary, but I think its really useful to have
them together as the needs of #3 drove #2, and that in turn drove #1.
The plumbing technique is to extend the "run" method signature with
extra arguments. We provide the call graph that intrinsically is
available as it is the basis of the pass manager's IR units, and an
output parameter that records the results of updating the call graph
during an SCC passes's run. Note that "...UpdateResult" isn't a *great*
name here... suggestions very welcome.
I tried a pretty frustrating number of different data structures and such
for the innards of the update result. Every other one failed for one
reason or another. Sometimes I just couldn't keep the layers of
complexity right in my head. The thing that really worked was to just
directly provide access to the underlying structures used to walk the
call graph so that their updates could be informed by the *particular*
nature of the change to the graph.
The technique for how to make the pass management infrastructure cope
with mutating graphs was also something that took a really, really large
number of iterations to get to a place where I was happy. Here are some
of the considerations that drove the design:
- We operate at three levels within the infrastructure: RefSCC, SCC, and
Node. In each case, we are working bottom up and so we want to
continue to iterate on the "lowest" node as the graph changes. Look at
how we iterate over nodes in an SCC running function passes as those
function passes mutate the CG. We continue to iterate on the "lowest"
SCC, which is the one that continues to contain the function just
processed.
- The call graph structure re-uses SCCs (and RefSCCs) during mutation
events for the *highest* entry in the resulting new subgraph, not the
lowest. This means that it is necessary to continually update the
current SCC or RefSCC as it shifts. This is really surprising and
subtle, and took a long time for me to work out. I actually tried
changing the call graph to provide the opposite behavior, and it
breaks *EVERYTHING*. The graph update algorithms are really deeply
tied to this particualr pattern.
- When SCCs or RefSCCs are split apart and refined and we continually
re-pin our processing to the bottom one in the subgraph, we need to
enqueue the newly formed SCCs and RefSCCs for subsequent processing.
Queuing them presents a few challenges:
1) SCCs and RefSCCs use wildly different iteration strategies at
a high level. We end up needing to converge them on worklist
approaches that can be extended in order to be able to handle the
mutations.
2) The order of the enqueuing need to remain bottom-up post-order so
that we don't get surprising order of visitation for things like
the inliner.
3) We need the worklists to have set semantics so we don't duplicate
things endlessly. We don't need a *persistent* set though because
we always keep processing the bottom node!!!! This is super, super
surprising to me and took a long time to convince myself this is
correct, but I'm pretty sure it is... Once we sink down to the
bottom node, we can't re-split out the same node in any way, and
the postorder of the current queue is fixed and unchanging.
4) We need to make sure that the "current" SCC or RefSCC actually gets
enqueued here such that we re-visit it because we continue
processing a *new*, *bottom* SCC/RefSCC.
- We also need the ability to *skip* SCCs and RefSCCs that get merged
into a larger component. We even need the ability to skip *nodes* from
an SCC that are no longer part of that SCC.
This led to the design you see in the patch which uses SetVector-based
worklists. The RefSCC worklist is always empty until an update occurs
and is just used to handle those RefSCCs created by updates as the
others don't even exist yet and are formed on-demand during the
bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and
we push new SCCs onto it and blacklist existing SCCs on it to get the
desired processing.
We then *directly* update these when updating the call graph as I was
never able to find a satisfactory abstraction around the update
strategy.
Finally, we need to compute the updates for function passes. This is
mostly used as an initial customer of all the update mechanisms to drive
their design to at least cover some real set of use cases. There are
a bunch of interesting things that came out of doing this:
- It is really nice to do this a function at a time because that
function is likely hot in the cache. This means we want even the
function pass adaptor to support online updates to the call graph!
- To update the call graph after arbitrary function pass mutations is
quite hard. We have to build a fairly comprehensive set of
data structures and then process them. Fortunately, some of this code
is related to the code for building the cal graph in the first place.
Unfortunately, very little of it makes any sense to share because the
nature of what we're doing is so very different. I've factored out the
one part that made sense at least.
- We need to transfer these updates into the various structures for the
CGSCC pass manager. Once those were more sanely worked out, this
became relatively easier. But some of those needs necessitated changes
to the LazyCallGraph interface to make it significantly easier to
extract the changed SCCs from an update operation.
- We also need to update the CGSCC analysis manager as the shape of the
graph changes. When an SCC is merged away we need to clear analyses
associated with it from the analysis manager which we didn't have
support for in the analysis manager infrsatructure. New SCCs are easy!
But then we have the case that the original SCC has its shape changed
but remains in the call graph. There we need to *invalidate* the
analyses associated with it.
- We also need to invalidate analyses after we *finish* processing an
SCC. But the analyses we need to invalidate here are *only those for
the newly updated SCC*!!! Because we only continue processing the
bottom SCC, if we split SCCs apart the original one gets invalidated
once when its shape changes and is not processed farther so its
analyses will be correct. It is the bottom SCC which continues being
processed and needs to have the "normal" invalidation done based on
the preserved analyses set.
All of this is mostly background and context for the changes here.
Many thanks to all the reviewers who helped here. Especially Sanjoy who
caught several interesting bugs in the graph algorithms, David, Sean,
and others who all helped with feedback.
Differential Revision: http://reviews.llvm.org/D21464
llvm-svn: 279618
2016-08-24 11:37:14 +02:00
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// This doesn't invalidate, but instead simply deletes, the relevant results.
|
|
|
|
/// It is useful when the IR is being removed and we want to clear out all the
|
|
|
|
/// memory pinned for it.
|
[PM] Introduce basic update capabilities to the new PM's CGSCC pass
manager, including both plumbing and logic to handle function pass
updates.
There are three fundamentally tied changes here:
1) Plumbing *some* mechanism for updating the CGSCC pass manager as the
CG changes while passes are running.
2) Changing the CGSCC pass manager infrastructure to have support for
the underlying graph to mutate mid-pass run.
3) Actually updating the CG after function passes run.
I can separate them if necessary, but I think its really useful to have
them together as the needs of #3 drove #2, and that in turn drove #1.
The plumbing technique is to extend the "run" method signature with
extra arguments. We provide the call graph that intrinsically is
available as it is the basis of the pass manager's IR units, and an
output parameter that records the results of updating the call graph
during an SCC passes's run. Note that "...UpdateResult" isn't a *great*
name here... suggestions very welcome.
I tried a pretty frustrating number of different data structures and such
for the innards of the update result. Every other one failed for one
reason or another. Sometimes I just couldn't keep the layers of
complexity right in my head. The thing that really worked was to just
directly provide access to the underlying structures used to walk the
call graph so that their updates could be informed by the *particular*
nature of the change to the graph.
The technique for how to make the pass management infrastructure cope
with mutating graphs was also something that took a really, really large
number of iterations to get to a place where I was happy. Here are some
of the considerations that drove the design:
- We operate at three levels within the infrastructure: RefSCC, SCC, and
Node. In each case, we are working bottom up and so we want to
continue to iterate on the "lowest" node as the graph changes. Look at
how we iterate over nodes in an SCC running function passes as those
function passes mutate the CG. We continue to iterate on the "lowest"
SCC, which is the one that continues to contain the function just
processed.
- The call graph structure re-uses SCCs (and RefSCCs) during mutation
events for the *highest* entry in the resulting new subgraph, not the
lowest. This means that it is necessary to continually update the
current SCC or RefSCC as it shifts. This is really surprising and
subtle, and took a long time for me to work out. I actually tried
changing the call graph to provide the opposite behavior, and it
breaks *EVERYTHING*. The graph update algorithms are really deeply
tied to this particualr pattern.
- When SCCs or RefSCCs are split apart and refined and we continually
re-pin our processing to the bottom one in the subgraph, we need to
enqueue the newly formed SCCs and RefSCCs for subsequent processing.
Queuing them presents a few challenges:
1) SCCs and RefSCCs use wildly different iteration strategies at
a high level. We end up needing to converge them on worklist
approaches that can be extended in order to be able to handle the
mutations.
2) The order of the enqueuing need to remain bottom-up post-order so
that we don't get surprising order of visitation for things like
the inliner.
3) We need the worklists to have set semantics so we don't duplicate
things endlessly. We don't need a *persistent* set though because
we always keep processing the bottom node!!!! This is super, super
surprising to me and took a long time to convince myself this is
correct, but I'm pretty sure it is... Once we sink down to the
bottom node, we can't re-split out the same node in any way, and
the postorder of the current queue is fixed and unchanging.
4) We need to make sure that the "current" SCC or RefSCC actually gets
enqueued here such that we re-visit it because we continue
processing a *new*, *bottom* SCC/RefSCC.
- We also need the ability to *skip* SCCs and RefSCCs that get merged
into a larger component. We even need the ability to skip *nodes* from
an SCC that are no longer part of that SCC.
This led to the design you see in the patch which uses SetVector-based
worklists. The RefSCC worklist is always empty until an update occurs
and is just used to handle those RefSCCs created by updates as the
others don't even exist yet and are formed on-demand during the
bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and
we push new SCCs onto it and blacklist existing SCCs on it to get the
desired processing.
We then *directly* update these when updating the call graph as I was
never able to find a satisfactory abstraction around the update
strategy.
Finally, we need to compute the updates for function passes. This is
mostly used as an initial customer of all the update mechanisms to drive
their design to at least cover some real set of use cases. There are
a bunch of interesting things that came out of doing this:
- It is really nice to do this a function at a time because that
function is likely hot in the cache. This means we want even the
function pass adaptor to support online updates to the call graph!
- To update the call graph after arbitrary function pass mutations is
quite hard. We have to build a fairly comprehensive set of
data structures and then process them. Fortunately, some of this code
is related to the code for building the cal graph in the first place.
Unfortunately, very little of it makes any sense to share because the
nature of what we're doing is so very different. I've factored out the
one part that made sense at least.
- We need to transfer these updates into the various structures for the
CGSCC pass manager. Once those were more sanely worked out, this
became relatively easier. But some of those needs necessitated changes
to the LazyCallGraph interface to make it significantly easier to
extract the changed SCCs from an update operation.
- We also need to update the CGSCC analysis manager as the shape of the
graph changes. When an SCC is merged away we need to clear analyses
associated with it from the analysis manager which we didn't have
support for in the analysis manager infrsatructure. New SCCs are easy!
But then we have the case that the original SCC has its shape changed
but remains in the call graph. There we need to *invalidate* the
analyses associated with it.
- We also need to invalidate analyses after we *finish* processing an
SCC. But the analyses we need to invalidate here are *only those for
the newly updated SCC*!!! Because we only continue processing the
bottom SCC, if we split SCCs apart the original one gets invalidated
once when its shape changes and is not processed farther so its
analyses will be correct. It is the bottom SCC which continues being
processed and needs to have the "normal" invalidation done based on
the preserved analyses set.
All of this is mostly background and context for the changes here.
Many thanks to all the reviewers who helped here. Especially Sanjoy who
caught several interesting bugs in the graph algorithms, David, Sean,
and others who all helped with feedback.
Differential Revision: http://reviews.llvm.org/D21464
llvm-svn: 279618
2016-08-24 11:37:14 +02:00
|
|
|
void clear(IRUnitT &IR) {
|
|
|
|
if (DebugLogging)
|
|
|
|
dbgs() << "Clearing all analysis results for: " << IR.getName() << "\n";
|
|
|
|
|
|
|
|
auto ResultsListI = AnalysisResultLists.find(&IR);
|
|
|
|
if (ResultsListI == AnalysisResultLists.end())
|
|
|
|
return;
|
2017-01-05 01:12:51 +01:00
|
|
|
// Delete the map entries that point into the results list.
|
2016-11-23 18:53:26 +01:00
|
|
|
for (auto &IDAndResult : ResultsListI->second)
|
2016-12-03 20:49:27 +01:00
|
|
|
AnalysisResults.erase({IDAndResult.first, &IR});
|
[PM] Introduce basic update capabilities to the new PM's CGSCC pass
manager, including both plumbing and logic to handle function pass
updates.
There are three fundamentally tied changes here:
1) Plumbing *some* mechanism for updating the CGSCC pass manager as the
CG changes while passes are running.
2) Changing the CGSCC pass manager infrastructure to have support for
the underlying graph to mutate mid-pass run.
3) Actually updating the CG after function passes run.
I can separate them if necessary, but I think its really useful to have
them together as the needs of #3 drove #2, and that in turn drove #1.
The plumbing technique is to extend the "run" method signature with
extra arguments. We provide the call graph that intrinsically is
available as it is the basis of the pass manager's IR units, and an
output parameter that records the results of updating the call graph
during an SCC passes's run. Note that "...UpdateResult" isn't a *great*
name here... suggestions very welcome.
I tried a pretty frustrating number of different data structures and such
for the innards of the update result. Every other one failed for one
reason or another. Sometimes I just couldn't keep the layers of
complexity right in my head. The thing that really worked was to just
directly provide access to the underlying structures used to walk the
call graph so that their updates could be informed by the *particular*
nature of the change to the graph.
The technique for how to make the pass management infrastructure cope
with mutating graphs was also something that took a really, really large
number of iterations to get to a place where I was happy. Here are some
of the considerations that drove the design:
- We operate at three levels within the infrastructure: RefSCC, SCC, and
Node. In each case, we are working bottom up and so we want to
continue to iterate on the "lowest" node as the graph changes. Look at
how we iterate over nodes in an SCC running function passes as those
function passes mutate the CG. We continue to iterate on the "lowest"
SCC, which is the one that continues to contain the function just
processed.
- The call graph structure re-uses SCCs (and RefSCCs) during mutation
events for the *highest* entry in the resulting new subgraph, not the
lowest. This means that it is necessary to continually update the
current SCC or RefSCC as it shifts. This is really surprising and
subtle, and took a long time for me to work out. I actually tried
changing the call graph to provide the opposite behavior, and it
breaks *EVERYTHING*. The graph update algorithms are really deeply
tied to this particualr pattern.
- When SCCs or RefSCCs are split apart and refined and we continually
re-pin our processing to the bottom one in the subgraph, we need to
enqueue the newly formed SCCs and RefSCCs for subsequent processing.
Queuing them presents a few challenges:
1) SCCs and RefSCCs use wildly different iteration strategies at
a high level. We end up needing to converge them on worklist
approaches that can be extended in order to be able to handle the
mutations.
2) The order of the enqueuing need to remain bottom-up post-order so
that we don't get surprising order of visitation for things like
the inliner.
3) We need the worklists to have set semantics so we don't duplicate
things endlessly. We don't need a *persistent* set though because
we always keep processing the bottom node!!!! This is super, super
surprising to me and took a long time to convince myself this is
correct, but I'm pretty sure it is... Once we sink down to the
bottom node, we can't re-split out the same node in any way, and
the postorder of the current queue is fixed and unchanging.
4) We need to make sure that the "current" SCC or RefSCC actually gets
enqueued here such that we re-visit it because we continue
processing a *new*, *bottom* SCC/RefSCC.
- We also need the ability to *skip* SCCs and RefSCCs that get merged
into a larger component. We even need the ability to skip *nodes* from
an SCC that are no longer part of that SCC.
This led to the design you see in the patch which uses SetVector-based
worklists. The RefSCC worklist is always empty until an update occurs
and is just used to handle those RefSCCs created by updates as the
others don't even exist yet and are formed on-demand during the
bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and
we push new SCCs onto it and blacklist existing SCCs on it to get the
desired processing.
We then *directly* update these when updating the call graph as I was
never able to find a satisfactory abstraction around the update
strategy.
Finally, we need to compute the updates for function passes. This is
mostly used as an initial customer of all the update mechanisms to drive
their design to at least cover some real set of use cases. There are
a bunch of interesting things that came out of doing this:
- It is really nice to do this a function at a time because that
function is likely hot in the cache. This means we want even the
function pass adaptor to support online updates to the call graph!
- To update the call graph after arbitrary function pass mutations is
quite hard. We have to build a fairly comprehensive set of
data structures and then process them. Fortunately, some of this code
is related to the code for building the cal graph in the first place.
Unfortunately, very little of it makes any sense to share because the
nature of what we're doing is so very different. I've factored out the
one part that made sense at least.
- We need to transfer these updates into the various structures for the
CGSCC pass manager. Once those were more sanely worked out, this
became relatively easier. But some of those needs necessitated changes
to the LazyCallGraph interface to make it significantly easier to
extract the changed SCCs from an update operation.
- We also need to update the CGSCC analysis manager as the shape of the
graph changes. When an SCC is merged away we need to clear analyses
associated with it from the analysis manager which we didn't have
support for in the analysis manager infrsatructure. New SCCs are easy!
But then we have the case that the original SCC has its shape changed
but remains in the call graph. There we need to *invalidate* the
analyses associated with it.
- We also need to invalidate analyses after we *finish* processing an
SCC. But the analyses we need to invalidate here are *only those for
the newly updated SCC*!!! Because we only continue processing the
bottom SCC, if we split SCCs apart the original one gets invalidated
once when its shape changes and is not processed farther so its
analyses will be correct. It is the bottom SCC which continues being
processed and needs to have the "normal" invalidation done based on
the preserved analyses set.
All of this is mostly background and context for the changes here.
Many thanks to all the reviewers who helped here. Especially Sanjoy who
caught several interesting bugs in the graph algorithms, David, Sean,
and others who all helped with feedback.
Differential Revision: http://reviews.llvm.org/D21464
llvm-svn: 279618
2016-08-24 11:37:14 +02:00
|
|
|
|
|
|
|
// And actually destroy and erase the results associated with this IR.
|
|
|
|
AnalysisResultLists.erase(ResultsListI);
|
|
|
|
}
|
|
|
|
|
2017-01-05 01:12:51 +01:00
|
|
|
/// \brief Clear all analysis results cached by this AnalysisManager.
|
2016-08-19 10:31:47 +02:00
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// Like \c clear(IRUnitT&), this doesn't invalidate the results; it simply
|
|
|
|
/// deletes them. This lets you clean up the AnalysisManager when the set of
|
|
|
|
/// IR units itself has potentially changed, and thus we can't even look up a
|
|
|
|
/// a result and invalidate/clear it directly.
|
2016-08-19 10:31:47 +02:00
|
|
|
void clear() {
|
|
|
|
AnalysisResults.clear();
|
|
|
|
AnalysisResultLists.clear();
|
|
|
|
}
|
|
|
|
|
2017-01-05 01:12:51 +01:00
|
|
|
/// \brief Get the result of an analysis pass for a given IR unit.
|
2013-11-13 02:12:08 +01:00
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// Runs the analysis if a cached result is not available.
|
2016-08-19 20:36:06 +02:00
|
|
|
template <typename PassT>
|
|
|
|
typename PassT::Result &getResult(IRUnitT &IR, ExtraArgTs... ExtraArgs) {
|
2013-11-26 12:24:37 +01:00
|
|
|
assert(AnalysisPasses.count(PassT::ID()) &&
|
2013-11-17 04:18:05 +01:00
|
|
|
"This analysis pass was not registered prior to being queried");
|
2016-08-19 20:36:06 +02:00
|
|
|
ResultConceptT &ResultConcept =
|
|
|
|
getResultImpl(PassT::ID(), IR, ExtraArgs...);
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
typedef detail::AnalysisResultModel<IRUnitT, PassT, typename PassT::Result,
|
|
|
|
PreservedAnalyses, Invalidator>
|
2013-11-22 01:48:49 +01:00
|
|
|
ResultModelT;
|
2014-02-05 22:41:42 +01:00
|
|
|
return static_cast<ResultModelT &>(ResultConcept).Result;
|
2013-11-13 02:12:08 +01:00
|
|
|
}
|
|
|
|
|
2017-01-05 01:12:51 +01:00
|
|
|
/// \brief Get the cached result of an analysis pass for a given IR unit.
|
2013-11-23 01:38:42 +01:00
|
|
|
///
|
|
|
|
/// 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.
llvm-svn: 225723
2015-01-12 23:53:31 +01:00
|
|
|
typename PassT::Result *getCachedResult(IRUnitT &IR) const {
|
2013-11-26 12:24:37 +01:00
|
|
|
assert(AnalysisPasses.count(PassT::ID()) &&
|
2013-11-23 01:38:42 +01:00
|
|
|
"This analysis pass was not registered prior to being queried");
|
|
|
|
|
2016-08-19 10:31:47 +02:00
|
|
|
ResultConceptT *ResultConcept = getCachedResultImpl(PassT::ID(), IR);
|
2013-11-23 01:38:42 +01:00
|
|
|
if (!ResultConcept)
|
2014-04-24 08:44:33 +02:00
|
|
|
return nullptr;
|
2013-11-23 01:38:42 +01:00
|
|
|
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
typedef detail::AnalysisResultModel<IRUnitT, PassT, typename PassT::Result,
|
|
|
|
PreservedAnalyses, Invalidator>
|
2013-11-23 01:38:42 +01:00
|
|
|
ResultModelT;
|
2014-02-05 22:41:42 +01:00
|
|
|
return &static_cast<ResultModelT *>(ResultConcept)->Result;
|
2013-11-23 01:38:42 +01:00
|
|
|
}
|
|
|
|
|
2013-11-13 02:12:08 +01:00
|
|
|
/// \brief Register an analysis pass with the manager.
|
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// The parameter is a callable whose result is an analysis pass. This allows
|
|
|
|
/// passing in a lambda to construct the analysis.
|
2016-02-18 10:45:17 +01:00
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// The analysis type to register is the type returned by calling the \c
|
|
|
|
/// PassBuilder argument. If that type has already been registered, then the
|
|
|
|
/// argument will not be called and this function will return false.
|
|
|
|
/// Otherwise, we register the analysis returned by calling \c PassBuilder(),
|
|
|
|
/// and this function returns true.
|
2016-02-18 10:45:17 +01:00
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// (Note: Although the return value of this function indicates whether or not
|
|
|
|
/// an analysis was previously registered, there intentionally isn't a way to
|
|
|
|
/// query this directly. Instead, you should just register all the analyses
|
|
|
|
/// you might want and let this class run them lazily. This idiom lets us
|
|
|
|
/// minimize the number of times we have to look up analyses in our
|
|
|
|
/// hashtable.)
|
2016-12-03 20:49:19 +01:00
|
|
|
template <typename PassBuilderT>
|
|
|
|
bool registerPass(PassBuilderT &&PassBuilder) {
|
2016-02-18 10:45:17 +01:00
|
|
|
typedef decltype(PassBuilder()) PassT;
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
typedef detail::AnalysisPassModel<IRUnitT, PassT, PreservedAnalyses,
|
|
|
|
Invalidator, ExtraArgTs...>
|
|
|
|
PassModelT;
|
2016-02-18 10:45:17 +01:00
|
|
|
|
|
|
|
auto &PassPtr = AnalysisPasses[PassT::ID()];
|
|
|
|
if (PassPtr)
|
|
|
|
// Already registered this pass type!
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Construct a new model around the instance returned by the builder.
|
|
|
|
PassPtr.reset(new PassModelT(PassBuilder()));
|
|
|
|
return true;
|
2013-11-13 02:12:08 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Invalidate a specific analysis pass for an IR module.
|
|
|
|
///
|
2017-01-05 01:12:51 +01:00
|
|
|
/// Note that the analysis result can disregard invalidation, if it determines
|
|
|
|
/// it is in fact still valid.
|
[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.
llvm-svn: 225723
2015-01-12 23:53:31 +01:00
|
|
|
template <typename PassT> void invalidate(IRUnitT &IR) {
|
2013-11-26 12:24:37 +01: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.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
"This analysis pass was not registered prior to being invalidated");
|
2016-08-19 10:31:47 +02:00
|
|
|
invalidateImpl(PassT::ID(), IR);
|
2013-11-13 02:12:08 +01:00
|
|
|
}
|
|
|
|
|
2017-01-05 01:12:51 +01:00
|
|
|
/// \brief Invalidate cached analyses for an IR unit.
|
2013-11-13 02:12:08 +01:00
|
|
|
///
|
2013-11-26 13:00:58 +01:00
|
|
|
/// Walk through all of the analyses pertaining to this unit of IR and
|
2017-01-05 01:12:51 +01:00
|
|
|
/// invalidate them, unless they are preserved by the PreservedAnalyses set.
|
2016-11-28 11:42:21 +01:00
|
|
|
void invalidate(IRUnitT &IR, const PreservedAnalyses &PA) {
|
2016-12-27 09:40:39 +01:00
|
|
|
// We're done if all analyses on this IR unit are preserved.
|
|
|
|
if (PA.allAnalysesInSetPreserved<AllAnalysesOn<IRUnitT>>())
|
2016-11-28 11:42:21 +01:00
|
|
|
return;
|
2016-08-19 10:31:47 +02:00
|
|
|
|
|
|
|
if (DebugLogging)
|
|
|
|
dbgs() << "Invalidating all non-preserved analyses for: " << IR.getName()
|
|
|
|
<< "\n";
|
|
|
|
|
2017-01-05 01:12:51 +01:00
|
|
|
// Track whether each analysis's result is invalidated in
|
|
|
|
// IsResultInvalidated.
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
SmallDenseMap<AnalysisKey *, bool, 8> IsResultInvalidated;
|
|
|
|
Invalidator Inv(IsResultInvalidated, AnalysisResults);
|
2016-08-19 10:31:47 +02:00
|
|
|
AnalysisResultListT &ResultsList = AnalysisResultLists[&IR];
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
for (auto &AnalysisResultPair : ResultsList) {
|
|
|
|
// This is basically the same thing as Invalidator::invalidate, but we
|
|
|
|
// can't call it here because we're operating on the type-erased result.
|
|
|
|
// Moreover if we instead called invalidate() directly, it would do an
|
|
|
|
// unnecessary look up in ResultsList.
|
|
|
|
AnalysisKey *ID = AnalysisResultPair.first;
|
|
|
|
auto &Result = *AnalysisResultPair.second;
|
|
|
|
|
2016-11-29 13:54:34 +01:00
|
|
|
auto IMapI = IsResultInvalidated.find(ID);
|
|
|
|
if (IMapI != IsResultInvalidated.end())
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
// This result was already handled via the Invalidator.
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Try to invalidate the result, giving it the Invalidator so it can
|
|
|
|
// recursively query for any dependencies it has and record the result.
|
2017-01-05 01:12:51 +01:00
|
|
|
// Note that we cannot reuse 'IMapI' here or pre-insert the ID, as
|
|
|
|
// Result.invalidate may insert things into the map, invalidating our
|
|
|
|
// iterator.
|
2016-11-29 13:54:34 +01:00
|
|
|
bool Inserted =
|
|
|
|
IsResultInvalidated.insert({ID, Result.invalidate(IR, PA, Inv)})
|
|
|
|
.second;
|
|
|
|
(void)Inserted;
|
|
|
|
assert(Inserted && "Should never have already inserted this ID, likely "
|
|
|
|
"indicates a cycle!");
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
}
|
2016-08-19 10:31:47 +02:00
|
|
|
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
// Now erase the results that were marked above as invalidated.
|
2016-12-03 20:49:23 +01:00
|
|
|
if (!IsResultInvalidated.empty()) {
|
|
|
|
for (auto I = ResultsList.begin(), E = ResultsList.end(); I != E;) {
|
|
|
|
AnalysisKey *ID = I->first;
|
|
|
|
if (!IsResultInvalidated.lookup(ID)) {
|
|
|
|
++I;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (DebugLogging)
|
|
|
|
dbgs() << "Invalidating analysis: " << this->lookUpPass(ID).name()
|
2017-01-22 11:33:54 +01:00
|
|
|
<< " on " << IR.getName() << "\n";
|
2016-12-03 20:49:23 +01:00
|
|
|
|
|
|
|
I = ResultsList.erase(I);
|
|
|
|
AnalysisResults.erase({ID, &IR});
|
2016-08-19 10:31:47 +02:00
|
|
|
}
|
|
|
|
}
|
2016-12-03 20:49:23 +01:00
|
|
|
|
2016-08-19 10:31:47 +02:00
|
|
|
if (ResultsList.empty())
|
|
|
|
AnalysisResultLists.erase(&IR);
|
2013-11-26 12:24:37 +01:00
|
|
|
}
|
|
|
|
|
2016-08-19 10:31:47 +02:00
|
|
|
private:
|
2016-12-03 20:49:35 +01:00
|
|
|
/// \brief Look up a registered analysis pass.
|
|
|
|
PassConceptT &lookUpPass(AnalysisKey *ID) {
|
2016-11-23 18:53:26 +01:00
|
|
|
typename AnalysisPassMapT::iterator PI = AnalysisPasses.find(ID);
|
2013-11-26 12:24:37 +01:00
|
|
|
assert(PI != AnalysisPasses.end() &&
|
|
|
|
"Analysis passes must be registered prior to being queried!");
|
|
|
|
return *PI->second;
|
|
|
|
}
|
|
|
|
|
2016-12-03 20:49:35 +01:00
|
|
|
/// \brief Look up a registered analysis pass.
|
|
|
|
const PassConceptT &lookUpPass(AnalysisKey *ID) const {
|
2016-11-23 18:53:26 +01:00
|
|
|
typename AnalysisPassMapT::const_iterator PI = AnalysisPasses.find(ID);
|
2013-11-26 12:24:37 +01:00
|
|
|
assert(PI != AnalysisPasses.end() &&
|
|
|
|
"Analysis passes must be registered prior to being queried!");
|
|
|
|
return *PI->second;
|
|
|
|
}
|
|
|
|
|
2015-01-13 03:51:47 +01:00
|
|
|
/// \brief Get an analysis result, running the pass if necessary.
|
2016-11-23 18:53:26 +01:00
|
|
|
ResultConceptT &getResultImpl(AnalysisKey *ID, IRUnitT &IR,
|
2016-08-19 20:36:06 +02:00
|
|
|
ExtraArgTs... ExtraArgs) {
|
2015-01-13 03:51:47 +01:00
|
|
|
typename AnalysisResultMapT::iterator RI;
|
|
|
|
bool Inserted;
|
|
|
|
std::tie(RI, Inserted) = AnalysisResults.insert(std::make_pair(
|
2016-11-23 18:53:26 +01:00
|
|
|
std::make_pair(ID, &IR), typename AnalysisResultListT::iterator()));
|
2015-01-13 03:51:47 +01:00
|
|
|
|
|
|
|
// 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) {
|
2016-12-03 20:49:35 +01:00
|
|
|
auto &P = this->lookUpPass(ID);
|
2015-01-13 23:42:38 +01:00
|
|
|
if (DebugLogging)
|
2017-01-22 11:33:54 +01:00
|
|
|
dbgs() << "Running analysis: " << P.name() << " on " << IR.getName()
|
|
|
|
<< "\n";
|
2015-01-13 03:51:47 +01:00
|
|
|
AnalysisResultListT &ResultList = AnalysisResultLists[&IR];
|
2016-11-23 18:53:26 +01:00
|
|
|
ResultList.emplace_back(ID, P.run(IR, *this, ExtraArgs...));
|
2015-02-27 03:19:11 +01:00
|
|
|
|
|
|
|
// P.run may have inserted elements into AnalysisResults and invalidated
|
|
|
|
// RI.
|
2016-12-03 20:49:27 +01:00
|
|
|
RI = AnalysisResults.find({ID, &IR});
|
2015-02-27 03:19:11 +01:00
|
|
|
assert(RI != AnalysisResults.end() && "we just inserted it!");
|
|
|
|
|
2015-01-13 03:51:47 +01:00
|
|
|
RI->second = std::prev(ResultList.end());
|
|
|
|
}
|
2014-03-10 01:35:47 +01:00
|
|
|
|
2015-01-13 03:51:47 +01:00
|
|
|
return *RI->second->second;
|
|
|
|
}
|
2013-11-13 02:12:08 +01:00
|
|
|
|
2015-01-13 03:51:47 +01:00
|
|
|
/// \brief Get a cached analysis result or return null.
|
2016-11-23 18:53:26 +01:00
|
|
|
ResultConceptT *getCachedResultImpl(AnalysisKey *ID, IRUnitT &IR) const {
|
2015-01-13 03:51:47 +01:00
|
|
|
typename AnalysisResultMapT::const_iterator RI =
|
2016-12-03 20:49:27 +01:00
|
|
|
AnalysisResults.find({ID, &IR});
|
2015-01-13 03:51:47 +01:00
|
|
|
return RI == AnalysisResults.end() ? nullptr : &*RI->second->second;
|
|
|
|
}
|
2013-11-23 01:38:42 +01:00
|
|
|
|
[PM] Split the analysis manager into a function-specific interface and
a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.
After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.
As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.
This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.
llvm-svn: 195189
2013-11-20 05:01:38 +01:00
|
|
|
/// \brief Invalidate a function pass result.
|
2016-11-23 18:53:26 +01:00
|
|
|
void invalidateImpl(AnalysisKey *ID, IRUnitT &IR) {
|
2015-01-13 03:51:47 +01:00
|
|
|
typename AnalysisResultMapT::iterator RI =
|
2016-12-03 20:49:27 +01:00
|
|
|
AnalysisResults.find({ID, &IR});
|
2015-01-13 03:51:47 +01:00
|
|
|
if (RI == AnalysisResults.end())
|
|
|
|
return;
|
|
|
|
|
2015-01-13 23:42:38 +01:00
|
|
|
if (DebugLogging)
|
2016-12-03 20:49:35 +01:00
|
|
|
dbgs() << "Invalidating analysis: " << this->lookUpPass(ID).name()
|
2017-01-22 11:33:54 +01:00
|
|
|
<< " on " << IR.getName() << "\n";
|
2015-01-13 03:51:47 +01:00
|
|
|
AnalysisResultLists[&IR].erase(RI->second);
|
|
|
|
AnalysisResults.erase(RI);
|
|
|
|
}
|
2013-11-13 02:12:08 +01:00
|
|
|
|
2016-08-19 10:31:47 +02:00
|
|
|
/// \brief Map type from module analysis pass ID to pass concept pointer.
|
2016-11-23 18:53:26 +01:00
|
|
|
typedef DenseMap<AnalysisKey *, std::unique_ptr<PassConceptT>> AnalysisPassMapT;
|
2015-01-13 03:51:47 +01:00
|
|
|
|
2016-08-19 10:31:47 +02:00
|
|
|
/// \brief Collection of module analysis passes, indexed by ID.
|
|
|
|
AnalysisPassMapT AnalysisPasses;
|
2013-11-13 02:12:08 +01:00
|
|
|
|
|
|
|
/// \brief Map from function to a list of function analysis results.
|
|
|
|
///
|
|
|
|
/// Provides linear time removal of all analysis results for a function and
|
|
|
|
/// the ultimate storage for a particular cached analysis result.
|
2015-01-13 03:51:47 +01:00
|
|
|
AnalysisResultListMapT AnalysisResultLists;
|
2013-11-13 02:12:08 +01:00
|
|
|
|
|
|
|
/// \brief Map from an analysis ID and function to a particular cached
|
|
|
|
/// analysis result.
|
2015-01-13 03:51:47 +01:00
|
|
|
AnalysisResultMapT AnalysisResults;
|
2015-01-13 23:42:38 +01:00
|
|
|
|
2017-01-05 01:12:51 +01:00
|
|
|
/// \brief Indicates whether we log to \c llvm::dbgs().
|
2015-01-13 23:42:38 +01:00
|
|
|
bool DebugLogging;
|
2013-11-13 02:12:08 +01:00
|
|
|
};
|
|
|
|
|
2016-02-27 11:45:35 +01:00
|
|
|
extern template class AnalysisManager<Module>;
|
2015-01-13 22:30:27 +01:00
|
|
|
/// \brief Convenience typedef for the Module analysis manager.
|
|
|
|
typedef AnalysisManager<Module> ModuleAnalysisManager;
|
|
|
|
|
2016-02-27 11:45:35 +01:00
|
|
|
extern template class AnalysisManager<Function>;
|
2015-01-13 22:30:27 +01:00
|
|
|
/// \brief Convenience typedef for the Function analysis manager.
|
|
|
|
typedef AnalysisManager<Function> FunctionAnalysisManager;
|
|
|
|
|
2017-01-07 00:32:02 +01:00
|
|
|
/// \brief An analysis over an "outer" IR unit that provides access to an
|
|
|
|
/// analysis manager over an "inner" IR unit. The inner unit must be contained
|
|
|
|
/// in the outer unit.
|
2013-11-21 03:11:31 +01:00
|
|
|
///
|
2017-01-07 00:32:02 +01:00
|
|
|
/// Fore example, InnerAnalysisManagerProxy<FunctionAnalysisManager, Module> is
|
|
|
|
/// an analysis over Modules (the "outer" unit) that provides access to a
|
|
|
|
/// Function analysis manager. The FunctionAnalysisManager is the "inner"
|
|
|
|
/// manager being proxied, and Functions are the "inner" unit. The inner/outer
|
|
|
|
/// relationship is valid because each Function is contained in one Module.
|
2016-02-23 01:05:00 +01:00
|
|
|
///
|
2017-01-07 00:32:02 +01:00
|
|
|
/// If you're (transitively) within a pass manager for an IR unit U that
|
|
|
|
/// contains IR unit V, you should never use an analysis manager over V, except
|
|
|
|
/// via one of these proxies.
|
|
|
|
///
|
|
|
|
/// Note that the proxy's result is a move-only RAII object. The validity of
|
|
|
|
/// the analyses in the inner analysis manager is tied to its lifetime.
|
2016-08-19 20:36:06 +02:00
|
|
|
template <typename AnalysisManagerT, typename IRUnitT, typename... ExtraArgTs>
|
2016-02-27 11:38:10 +01:00
|
|
|
class InnerAnalysisManagerProxy
|
2016-03-11 11:33:22 +01:00
|
|
|
: public AnalysisInfoMixin<
|
2016-02-27 11:38:10 +01:00
|
|
|
InnerAnalysisManagerProxy<AnalysisManagerT, IRUnitT>> {
|
2013-11-21 03:11:31 +01:00
|
|
|
public:
|
2016-02-27 11:38:10 +01:00
|
|
|
class Result {
|
|
|
|
public:
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 07:34:44 +01:00
|
|
|
explicit Result(AnalysisManagerT &InnerAM) : InnerAM(&InnerAM) {}
|
|
|
|
Result(Result &&Arg) : InnerAM(std::move(Arg.InnerAM)) {
|
2016-02-27 11:38:10 +01:00
|
|
|
// We have to null out the analysis manager in the moved-from state
|
|
|
|
// because we are taking ownership of the responsibilty to clear the
|
|
|
|
// analysis state.
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 07:34:44 +01:00
|
|
|
Arg.InnerAM = nullptr;
|
2016-02-27 11:38:10 +01:00
|
|
|
}
|
|
|
|
Result &operator=(Result &&RHS) {
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 07:34:44 +01:00
|
|
|
InnerAM = RHS.InnerAM;
|
2016-02-27 11:38:10 +01:00
|
|
|
// We have to null out the analysis manager in the moved-from state
|
|
|
|
// because we are taking ownership of the responsibilty to clear the
|
|
|
|
// analysis state.
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 07:34:44 +01:00
|
|
|
RHS.InnerAM = nullptr;
|
2016-02-27 11:38:10 +01:00
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
~Result() {
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 07:34:44 +01:00
|
|
|
// InnerAM is cleared in a moved from state where there is nothing to do.
|
|
|
|
if (!InnerAM)
|
2016-02-27 11:38:10 +01:00
|
|
|
return;
|
|
|
|
|
|
|
|
// Clear out the analysis manager if we're being destroyed -- it means we
|
|
|
|
// didn't even see an invalidate call when we got invalidated.
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 07:34:44 +01:00
|
|
|
InnerAM->clear();
|
2016-02-27 11:38:10 +01:00
|
|
|
}
|
2013-11-21 03:11:31 +01:00
|
|
|
|
2016-02-27 11:38:10 +01:00
|
|
|
/// \brief Accessor for the analysis manager.
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 07:34:44 +01:00
|
|
|
AnalysisManagerT &getManager() { return *InnerAM; }
|
2016-02-27 11:38:10 +01:00
|
|
|
|
2017-01-07 00:32:02 +01:00
|
|
|
/// \brief Handler for invalidation of the outer IR unit, \c IRUnitT.
|
2016-02-27 11:38:10 +01:00
|
|
|
///
|
2017-01-07 00:32:02 +01:00
|
|
|
/// If the proxy analysis itself is not preserved, we assume that the set of
|
|
|
|
/// inner IR objects contained in IRUnit may have changed. In this case,
|
|
|
|
/// we have to call \c clear() on the inner analysis manager, as it may now
|
|
|
|
/// have stale pointers to its inner IR objects.
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 07:34:44 +01:00
|
|
|
///
|
2017-01-07 00:32:02 +01:00
|
|
|
/// Regardless of whether the proxy analysis is marked as preserved, all of
|
|
|
|
/// the analyses in the inner analysis manager are potentially invalidated
|
|
|
|
/// based on the set of preserved analyses.
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
bool invalidate(
|
|
|
|
IRUnitT &IR, const PreservedAnalyses &PA,
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 07:34:44 +01:00
|
|
|
typename AnalysisManager<IRUnitT, ExtraArgTs...>::Invalidator &Inv);
|
2016-02-27 11:38:10 +01:00
|
|
|
|
|
|
|
private:
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 07:34:44 +01:00
|
|
|
AnalysisManagerT *InnerAM;
|
2016-02-27 11:38:10 +01:00
|
|
|
};
|
|
|
|
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 07:34:44 +01:00
|
|
|
explicit InnerAnalysisManagerProxy(AnalysisManagerT &InnerAM)
|
|
|
|
: InnerAM(&InnerAM) {}
|
2013-11-21 03:11:31 +01:00
|
|
|
|
|
|
|
/// \brief Run the analysis pass and create our proxy result object.
|
|
|
|
///
|
2017-01-07 00:32:02 +01:00
|
|
|
/// This doesn't do any interesting work; it is primarily used to insert our
|
|
|
|
/// proxy result object into the outer analysis cache so that we can proxy
|
|
|
|
/// invalidation to the inner analysis manager.
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 07:34:44 +01:00
|
|
|
Result run(IRUnitT &IR, AnalysisManager<IRUnitT, ExtraArgTs...> &AM,
|
2016-08-19 20:36:06 +02:00
|
|
|
ExtraArgTs...) {
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 07:34:44 +01:00
|
|
|
return Result(*InnerAM);
|
2016-08-19 20:36:06 +02:00
|
|
|
}
|
2013-11-21 03:11:31 +01:00
|
|
|
|
|
|
|
private:
|
2016-03-11 11:33:22 +01:00
|
|
|
friend AnalysisInfoMixin<
|
|
|
|
InnerAnalysisManagerProxy<AnalysisManagerT, IRUnitT>>;
|
2016-11-23 18:53:26 +01:00
|
|
|
static AnalysisKey Key;
|
2016-03-11 11:22:49 +01:00
|
|
|
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 07:34:44 +01:00
|
|
|
AnalysisManagerT *InnerAM;
|
2013-11-21 03:11:31 +01:00
|
|
|
};
|
|
|
|
|
2016-08-19 20:36:06 +02:00
|
|
|
template <typename AnalysisManagerT, typename IRUnitT, typename... ExtraArgTs>
|
2016-11-23 18:53:26 +01:00
|
|
|
AnalysisKey
|
|
|
|
InnerAnalysisManagerProxy<AnalysisManagerT, IRUnitT, ExtraArgTs...>::Key;
|
2016-03-11 11:22:49 +01:00
|
|
|
|
2016-02-27 11:38:10 +01:00
|
|
|
/// Provide the \c FunctionAnalysisManager to \c Module proxy.
|
|
|
|
typedef InnerAnalysisManagerProxy<FunctionAnalysisManager, Module>
|
|
|
|
FunctionAnalysisManagerModuleProxy;
|
2013-11-21 03:11:31 +01:00
|
|
|
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 07:34:44 +01:00
|
|
|
/// Specialization of the invalidate method for the \c
|
|
|
|
/// FunctionAnalysisManagerModuleProxy's result.
|
|
|
|
template <>
|
|
|
|
bool FunctionAnalysisManagerModuleProxy::Result::invalidate(
|
|
|
|
Module &M, const PreservedAnalyses &PA,
|
|
|
|
ModuleAnalysisManager::Invalidator &Inv);
|
|
|
|
|
|
|
|
// Ensure the \c FunctionAnalysisManagerModuleProxy is provided as an extern
|
|
|
|
// template.
|
|
|
|
extern template class InnerAnalysisManagerProxy<FunctionAnalysisManager,
|
|
|
|
Module>;
|
|
|
|
|
2017-01-07 00:32:02 +01:00
|
|
|
/// \brief An analysis over an "inner" IR unit that provides access to an
|
|
|
|
/// analysis manager over a "outer" IR unit. The inner unit must be contained
|
|
|
|
/// in the outer unit.
|
2013-11-23 02:25:07 +01:00
|
|
|
///
|
2017-01-07 00:32:02 +01:00
|
|
|
/// For example OuterAnalysisManagerProxy<ModuleAnalysisManager, Function> is an
|
|
|
|
/// analysis over Functions (the "inner" unit) which provides access to a Module
|
|
|
|
/// analysis manager. The ModuleAnalysisManager is the "outer" manager being
|
|
|
|
/// proxied, and Modules are the "outer" IR unit. The inner/outer relationship
|
|
|
|
/// is valid because each Function is contained in one Module.
|
2013-11-23 02:25:07 +01:00
|
|
|
///
|
2017-01-07 00:32:02 +01:00
|
|
|
/// This proxy only exposes the const interface of the outer analysis manager,
|
|
|
|
/// to indicate that you cannot cause an outer analysis to run from within an
|
|
|
|
/// inner pass. Instead, you must rely on the \c getCachedResult API.
|
2016-12-27 09:40:39 +01:00
|
|
|
///
|
2017-01-07 00:32:02 +01:00
|
|
|
/// This proxy doesn't manage invalidation in any way -- that is handled by the
|
|
|
|
/// recursive return path of each layer of the pass manager. A consequence of
|
|
|
|
/// this is the outer analyses may be stale. We invalidate the outer analyses
|
|
|
|
/// only when we're done running passes over the inner IR units.
|
2016-08-19 20:36:06 +02:00
|
|
|
template <typename AnalysisManagerT, typename IRUnitT, typename... ExtraArgTs>
|
2016-02-27 11:38:10 +01:00
|
|
|
class OuterAnalysisManagerProxy
|
2016-03-11 11:33:22 +01:00
|
|
|
: public AnalysisInfoMixin<
|
2017-02-07 02:50:48 +01:00
|
|
|
OuterAnalysisManagerProxy<AnalysisManagerT, IRUnitT, ExtraArgTs...>> {
|
2013-11-23 02:25:07 +01:00
|
|
|
public:
|
2016-02-27 11:38:10 +01:00
|
|
|
/// \brief Result proxy object for \c OuterAnalysisManagerProxy.
|
2013-11-23 02:25:07 +01:00
|
|
|
class Result {
|
|
|
|
public:
|
2016-02-27 11:38:10 +01:00
|
|
|
explicit Result(const AnalysisManagerT &AM) : AM(&AM) {}
|
2013-11-23 02:25:07 +01:00
|
|
|
|
2016-02-27 11:38:10 +01:00
|
|
|
const AnalysisManagerT &getManager() const { return *AM; }
|
2013-11-23 02:25:07 +01:00
|
|
|
|
2017-01-07 00:32:02 +01:00
|
|
|
/// \brief Handle invalidation by ignoring it; this pass is immutable.
|
[PM] Extend the explicit 'invalidate' method API on analysis results to
accept an Invalidator that allows them to invalidate themselves if their
dependencies are in turn invalidated.
Rather than recording the dependency graph ahead of time when analysis
get results from other analyses, this simply lets each result trigger
the immediate invalidation of any analyses they actually depend on. They
do this in a way that has three nice properties:
1) They don't have to handle transitive dependencies because the
infrastructure will recurse for them.
2) The invalidate methods are still called only once. We just
dynamically discover the necessary topological ordering, everything
is memoized nicely.
3) The infrastructure still provides a default implementation and can
access it so that only analyses which have dependencies need to do
anything custom.
To make this work at all, the invalidation logic also has to defer the
deletion of the result objects themselves so that they can remain alive
until we have collected the complete set of results to invalidate.
A unittest is added here that has exactly the dependency pattern we are
concerned with. It hit the use-after-free described by Sean in much
detail in the long thread about analysis invalidation before this
change, and even in an intermediate form of this change where we failed
to defer the deletion of the result objects.
There is an important problem with doing dependency invalidation that
*isn't* solved here: we don't *enforce* that results correctly
invalidate all the analyses whose results they depend on.
I actually looked at what it would take to do that, and it isn't as hard
as I had thought but the complexity it introduces seems very likely to
outweigh the benefit. The technique would be to provide a base class for
an analysis result that would be populated with other results, and
automatically provide the invalidate method which immediately does the
correct thing. This approach has some nice pros IMO:
- Handles the case we care about and nothing else: only *results*
that depend on other analyses trigger extra invalidation.
- Localized to the result rather than centralized in the analysis
manager.
- Ties the storage of the reference to another result to the triggering
of the invalidation of that analysis.
- Still supports extending invalidation in customized ways.
But the down sides here are:
- Very heavy-weight meta-programming is needed to provide this base
class.
- Requires a pretty awful API for accessing the dependencies.
Ultimately, I fear it will not pull its weight. But we can re-evaluate
this at any point if we start discovering consistent problems where the
invalidation and dependencies get out of sync. It will fit as a clean
layer on top of the facilities in this patch that we can add if and when
we need it.
Note that I'm not really thrilled with the names for these APIs... The
name "Invalidator" seems ok but not great. The method name "invalidate"
also. In review some improvements were suggested, but they really need
*other* uses of these terms to be updated as well so I'm going to do
that in a follow-up commit.
I'm working on the actual fixes to various analyses that need to use
these, but I want to try to get tests for each of them so we don't
regress. And those changes are seperable and obvious so once this goes
in I should be able to roll them out throughout LLVM.
Many thanks to Sean, Justin, and others for help reviewing here.
Differential Revision: https://reviews.llvm.org/D23738
llvm-svn: 288077
2016-11-28 23:04:31 +01:00
|
|
|
bool invalidate(
|
|
|
|
IRUnitT &, const PreservedAnalyses &,
|
|
|
|
typename AnalysisManager<IRUnitT, ExtraArgTs...>::Invalidator &) {
|
|
|
|
return false;
|
|
|
|
}
|
2013-11-23 02:25:07 +01:00
|
|
|
|
2016-12-27 09:40:39 +01:00
|
|
|
/// Register a deferred invalidation event for when the outer analysis
|
|
|
|
/// manager processes its invalidations.
|
|
|
|
template <typename OuterAnalysisT, typename InvalidatedAnalysisT>
|
|
|
|
void registerOuterAnalysisInvalidation() {
|
|
|
|
AnalysisKey *OuterID = OuterAnalysisT::ID();
|
|
|
|
AnalysisKey *InvalidatedID = InvalidatedAnalysisT::ID();
|
|
|
|
|
|
|
|
auto &InvalidatedIDList = OuterAnalysisInvalidationMap[OuterID];
|
|
|
|
// Note, this is a linear scan. If we end up with large numbers of
|
|
|
|
// analyses that all trigger invalidation on the same outer analysis,
|
|
|
|
// this entire system should be changed to some other deterministic
|
|
|
|
// data structure such as a `SetVector` of a pair of pointers.
|
|
|
|
auto InvalidatedIt = std::find(InvalidatedIDList.begin(),
|
|
|
|
InvalidatedIDList.end(), InvalidatedID);
|
|
|
|
if (InvalidatedIt == InvalidatedIDList.end())
|
|
|
|
InvalidatedIDList.push_back(InvalidatedID);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Access the map from outer analyses to deferred invalidation requiring
|
|
|
|
/// analyses.
|
|
|
|
const SmallDenseMap<AnalysisKey *, TinyPtrVector<AnalysisKey *>, 2> &
|
|
|
|
getOuterInvalidations() const {
|
|
|
|
return OuterAnalysisInvalidationMap;
|
|
|
|
}
|
|
|
|
|
2013-11-23 02:25:07 +01:00
|
|
|
private:
|
2016-02-27 11:38:10 +01:00
|
|
|
const AnalysisManagerT *AM;
|
2016-12-27 09:40:39 +01:00
|
|
|
|
|
|
|
/// A map from an outer analysis ID to the set of this IR-unit's analyses
|
|
|
|
/// which need to be invalidated.
|
|
|
|
SmallDenseMap<AnalysisKey *, TinyPtrVector<AnalysisKey *>, 2>
|
|
|
|
OuterAnalysisInvalidationMap;
|
2013-11-23 02:25:07 +01:00
|
|
|
};
|
|
|
|
|
2016-02-27 11:38:10 +01:00
|
|
|
OuterAnalysisManagerProxy(const AnalysisManagerT &AM) : AM(&AM) {}
|
2013-11-23 02:25:07 +01:00
|
|
|
|
|
|
|
/// \brief Run the analysis pass and create our proxy result object.
|
2016-02-27 11:38:10 +01:00
|
|
|
/// Nothing to see here, it just forwards the \c AM reference into the
|
2013-11-23 02:25:07 +01:00
|
|
|
/// result.
|
2016-08-19 20:36:06 +02:00
|
|
|
Result run(IRUnitT &, AnalysisManager<IRUnitT, ExtraArgTs...> &,
|
|
|
|
ExtraArgTs...) {
|
|
|
|
return Result(*AM);
|
|
|
|
}
|
2013-11-23 02:25:07 +01:00
|
|
|
|
|
|
|
private:
|
2016-03-11 11:33:22 +01:00
|
|
|
friend AnalysisInfoMixin<
|
2017-02-07 02:50:48 +01:00
|
|
|
OuterAnalysisManagerProxy<AnalysisManagerT, IRUnitT, ExtraArgTs...>>;
|
2016-11-23 18:53:26 +01:00
|
|
|
static AnalysisKey Key;
|
2016-03-11 11:22:49 +01:00
|
|
|
|
2016-02-27 11:38:10 +01:00
|
|
|
const AnalysisManagerT *AM;
|
2013-11-23 02:25:07 +01:00
|
|
|
};
|
|
|
|
|
2016-08-19 20:36:06 +02:00
|
|
|
template <typename AnalysisManagerT, typename IRUnitT, typename... ExtraArgTs>
|
2016-11-23 18:53:26 +01:00
|
|
|
AnalysisKey
|
|
|
|
OuterAnalysisManagerProxy<AnalysisManagerT, IRUnitT, ExtraArgTs...>::Key;
|
2016-03-11 11:22:49 +01:00
|
|
|
|
2016-02-27 11:38:10 +01:00
|
|
|
extern template class OuterAnalysisManagerProxy<ModuleAnalysisManager,
|
|
|
|
Function>;
|
2017-01-07 00:32:02 +01:00
|
|
|
/// Provide the \c ModuleAnalysisManager to \c Function proxy.
|
2016-02-27 11:38:10 +01:00
|
|
|
typedef OuterAnalysisManagerProxy<ModuleAnalysisManager, Function>
|
|
|
|
ModuleAnalysisManagerFunctionProxy;
|
|
|
|
|
2013-11-21 03:11:31 +01: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!
llvm-svn: 195400
2013-11-22 01:43:29 +01:00
|
|
|
/// Designed to allow composition of a FunctionPass(Manager) and
|
2017-01-07 00:32:02 +01:00
|
|
|
/// a ModulePassManager, by running the FunctionPass(Manager) over every
|
|
|
|
/// function in the module.
|
2015-01-13 12:13:56 +01: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.
|
2017-01-07 00:32:02 +01:00
|
|
|
///
|
|
|
|
/// Note that although function passes can access module analyses, module
|
|
|
|
/// analyses are not invalidated while the function passes are running, so they
|
|
|
|
/// may be stale. Function analyses will not be stale.
|
2016-02-26 12:44:45 +01:00
|
|
|
template <typename FunctionPassT>
|
|
|
|
class ModuleToFunctionPassAdaptor
|
2016-03-11 11:33:22 +01:00
|
|
|
: public PassInfoMixin<ModuleToFunctionPassAdaptor<FunctionPassT>> {
|
2013-11-21 03:11:31 +01: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!
llvm-svn: 195400
2013-11-22 01:43:29 +01:00
|
|
|
explicit ModuleToFunctionPassAdaptor(FunctionPassT Pass)
|
2014-03-02 05:08:41 +01:00
|
|
|
: Pass(std::move(Pass)) {}
|
2013-11-21 03:11:31 +01:00
|
|
|
|
|
|
|
/// \brief Runs the function pass across every function in the module.
|
2016-03-11 12:05:24 +01:00
|
|
|
PreservedAnalyses run(Module &M, ModuleAnalysisManager &AM) {
|
|
|
|
FunctionAnalysisManager &FAM =
|
|
|
|
AM.getResult<FunctionAnalysisManagerModuleProxy>(M).getManager();
|
2013-11-21 03:11:31 +01:00
|
|
|
|
|
|
|
PreservedAnalyses PA = PreservedAnalyses::all();
|
2015-02-01 11:40:21 +01:00
|
|
|
for (Function &F : M) {
|
2015-02-01 11:47:25 +01:00
|
|
|
if (F.isDeclaration())
|
|
|
|
continue;
|
|
|
|
|
2015-02-01 11:40:21 +01:00
|
|
|
PreservedAnalyses PassPA = Pass.run(F, FAM);
|
2013-11-23 00:38:07 +01: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
|
2016-11-28 11:42:21 +01:00
|
|
|
// directly handle the function analysis manager's invalidation here.
|
|
|
|
FAM.invalidate(F, PassPA);
|
2013-11-23 00:38:07 +01:00
|
|
|
|
|
|
|
// Then intersect the preserved set so that invalidation of module
|
|
|
|
// analyses will eventually occur when the module pass completes.
|
2014-03-02 05:08:41 +01:00
|
|
|
PA.intersect(std::move(PassPA));
|
2013-11-21 03:11:31 +01:00
|
|
|
}
|
2013-11-21 12:04:53 +01:00
|
|
|
|
2017-01-07 00:32:02 +01:00
|
|
|
// The FunctionAnalysisManagerModuleProxy is preserved because (we assume)
|
|
|
|
// the function passes we ran didn't add or remove any functions.
|
|
|
|
//
|
|
|
|
// We also preserve all analyses on Functions, because we did all the
|
|
|
|
// invalidation we needed to do above.
|
2016-12-27 09:40:39 +01:00
|
|
|
PA.preserveSet<AllAnalysesOn<Function>>();
|
[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!
llvm-svn: 195400
2013-11-22 01:43:29 +01:00
|
|
|
PA.preserve<FunctionAnalysisManagerModuleProxy>();
|
2013-11-21 03:11:31 +01:00
|
|
|
return PA;
|
|
|
|
}
|
|
|
|
|
|
|
|
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!
llvm-svn: 195400
2013-11-22 01:43:29 +01:00
|
|
|
createModuleToFunctionPassAdaptor(FunctionPassT Pass) {
|
2015-05-01 17:26:22 +02:00
|
|
|
return ModuleToFunctionPassAdaptor<FunctionPassT>(std::move(Pass));
|
2013-11-21 03:11:31 +01:00
|
|
|
}
|
|
|
|
|
2017-01-07 00:32:02 +01:00
|
|
|
/// \brief A utility pass template to force an analysis result to be available.
|
2015-01-06 03:10:51 +01:00
|
|
|
///
|
2016-08-19 20:36:06 +02:00
|
|
|
/// If there are extra arguments at the pass's run level there may also be
|
|
|
|
/// extra arguments to the analysis manager's \c getResult routine. We can't
|
|
|
|
/// guess how to effectively map the arguments from one to the other, and so
|
|
|
|
/// this specialization just ignores them.
|
|
|
|
///
|
|
|
|
/// Specific patterns of run-method extra arguments and analysis manager extra
|
|
|
|
/// arguments will have to be defined as appropriate specializations.
|
|
|
|
template <typename AnalysisT, typename IRUnitT,
|
|
|
|
typename AnalysisManagerT = AnalysisManager<IRUnitT>,
|
|
|
|
typename... ExtraArgTs>
|
|
|
|
struct RequireAnalysisPass
|
|
|
|
: PassInfoMixin<RequireAnalysisPass<AnalysisT, IRUnitT, AnalysisManagerT,
|
|
|
|
ExtraArgTs...>> {
|
2015-01-06 03:10:51 +01: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.
|
2016-08-19 20:36:06 +02:00
|
|
|
PreservedAnalyses run(IRUnitT &Arg, AnalysisManagerT &AM,
|
|
|
|
ExtraArgTs &&... Args) {
|
|
|
|
(void)AM.template getResult<AnalysisT>(Arg,
|
|
|
|
std::forward<ExtraArgTs>(Args)...);
|
2015-01-06 03:10:51 +01:00
|
|
|
|
|
|
|
return PreservedAnalyses::all();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2017-01-07 00:32:02 +01:00
|
|
|
/// \brief A no-op pass template which simply forces a specific analysis result
|
|
|
|
/// to be invalidated.
|
2016-02-26 12:44:45 +01:00
|
|
|
template <typename AnalysisT>
|
2016-03-11 11:33:22 +01:00
|
|
|
struct InvalidateAnalysisPass
|
|
|
|
: PassInfoMixin<InvalidateAnalysisPass<AnalysisT>> {
|
2015-01-06 05:49:44 +01:00
|
|
|
/// \brief Run this pass over some unit of IR.
|
|
|
|
///
|
2017-01-07 00:32:02 +01:00
|
|
|
/// This pass can be run over any unit of IR and use any analysis manager,
|
2015-01-06 05:49:44 +01:00
|
|
|
/// provided they satisfy the basic API requirements. When this pass is
|
|
|
|
/// created, these methods can be instantiated to satisfy whatever the
|
|
|
|
/// context requires.
|
2016-08-19 20:36:06 +02:00
|
|
|
template <typename IRUnitT, typename AnalysisManagerT, typename... ExtraArgTs>
|
|
|
|
PreservedAnalyses run(IRUnitT &Arg, AnalysisManagerT &AM, ExtraArgTs &&...) {
|
2016-12-27 09:44:39 +01:00
|
|
|
auto PA = PreservedAnalyses::all();
|
|
|
|
PA.abandon<AnalysisT>();
|
|
|
|
return PA;
|
2015-01-06 05:49:44 +01:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2017-01-07 00:32:02 +01:00
|
|
|
/// \brief A utility pass that does nothing, but preserves no analyses.
|
2015-01-06 10:06:35 +01:00
|
|
|
///
|
2017-01-07 00:32:02 +01:00
|
|
|
/// Because this preserves no analyses, any analysis passes queried after this
|
|
|
|
/// pass runs will recompute fresh results.
|
2016-03-11 11:33:22 +01:00
|
|
|
struct InvalidateAllAnalysesPass : PassInfoMixin<InvalidateAllAnalysesPass> {
|
2015-01-06 10:06:35 +01:00
|
|
|
/// \brief Run this pass over some unit of IR.
|
2016-08-19 20:36:06 +02:00
|
|
|
template <typename IRUnitT, typename AnalysisManagerT, typename... ExtraArgTs>
|
|
|
|
PreservedAnalyses run(IRUnitT &, AnalysisManagerT &, ExtraArgTs &&...) {
|
2015-01-06 10:06:35 +01:00
|
|
|
return PreservedAnalyses::none();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2016-08-03 09:44:48 +02:00
|
|
|
/// A utility pass template that simply runs another pass multiple times.
|
|
|
|
///
|
|
|
|
/// This can be useful when debugging or testing passes. It also serves as an
|
|
|
|
/// example of how to extend the pass manager in ways beyond composition.
|
|
|
|
template <typename PassT>
|
2016-08-04 05:52:53 +02:00
|
|
|
class RepeatedPass : public PassInfoMixin<RepeatedPass<PassT>> {
|
2016-08-03 09:44:48 +02:00
|
|
|
public:
|
2016-08-04 05:52:53 +02:00
|
|
|
RepeatedPass(int Count, PassT P) : Count(Count), P(std::move(P)) {}
|
2016-08-03 09:44:48 +02:00
|
|
|
|
2016-08-19 20:36:06 +02:00
|
|
|
template <typename IRUnitT, typename AnalysisManagerT, typename... Ts>
|
|
|
|
PreservedAnalyses run(IRUnitT &Arg, AnalysisManagerT &AM, Ts &&... Args) {
|
2016-08-03 09:44:48 +02:00
|
|
|
auto PA = PreservedAnalyses::all();
|
|
|
|
for (int i = 0; i < Count; ++i)
|
2016-08-19 20:36:06 +02:00
|
|
|
PA.intersect(P.run(Arg, AM, std::forward<Ts>(Args)...));
|
2016-08-03 09:44:48 +02:00
|
|
|
return PA;
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
2016-08-03 10:16:08 +02:00
|
|
|
int Count;
|
2016-08-03 09:44:48 +02:00
|
|
|
PassT P;
|
|
|
|
};
|
|
|
|
|
|
|
|
template <typename PassT>
|
2016-08-04 05:52:53 +02:00
|
|
|
RepeatedPass<PassT> createRepeatedPass(int Count, PassT P) {
|
|
|
|
return RepeatedPass<PassT>(Count, std::move(P));
|
2016-08-03 09:44:48 +02:00
|
|
|
}
|
|
|
|
|
2015-06-23 11:49:53 +02:00
|
|
|
}
|
2014-01-11 11:59:00 +01:00
|
|
|
|
|
|
|
#endif
|