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"
|
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 {};
|
|
|
|
|
2013-11-20 12:31:50 +01:00
|
|
|
/// \brief An abstract set of preserved analyses following a transformation pass
|
|
|
|
/// run.
|
|
|
|
///
|
|
|
|
/// When a transformation pass is run, it can return a set of analyses whose
|
|
|
|
/// results were preserved by that transformation. The default set is "none",
|
|
|
|
/// and preserving analyses must be done explicitly.
|
|
|
|
///
|
|
|
|
/// There is also an explicit all state which can be used (for example) when
|
|
|
|
/// the IR is not mutated at all.
|
|
|
|
class PreservedAnalyses {
|
|
|
|
public:
|
|
|
|
/// \brief Convenience factory function for the empty preserved set.
|
|
|
|
static PreservedAnalyses none() { return PreservedAnalyses(); }
|
|
|
|
|
|
|
|
/// \brief Construct a special preserved set that preserves all passes.
|
|
|
|
static PreservedAnalyses all() {
|
|
|
|
PreservedAnalyses PA;
|
2016-11-23 18:53:26 +01:00
|
|
|
PA.PreservedAnalysisIDs.insert(&AllAnalysesKey);
|
2013-11-20 12:31:50 +01:00
|
|
|
return PA;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Mark a particular pass as preserved, adding it to the set.
|
[PM] Fix a pretty nasty bug where the new pass manager would invalidate
passes too many time.
I think this is actually the issue that someone raised with me at the
developer's meeting and in an email, but that we never really got to the
bottom of. Having all the testing utilities made it much easier to dig
down and uncover the core issue.
When a pass manager is running many passes over a single function, we
need it to invalidate the analyses between each run so that they can be
re-computed as needed. We also need to track the intersection of
preserved higher-level analyses across all the passes that we run (for
example, if there is one module analysis which all the function analyses
preserve, we want to track that and propagate it). Unfortunately, this
interacted poorly with any enclosing pass adaptor between two IR units.
It would see the intersection of preserved analyses, and need to
invalidate any other analyses, but some of the un-preserved analyses
might have already been invalidated *and recomputed*! We would fail to
propagate the fact that the analysis had already been invalidated.
The solution to this struck me as really strange at first, but the more
I thought about it, the more natural it seemed. After a nice discussion
with Duncan about it on IRC, it seemed even nicer. The idea is that
invalidating an analysis *causes* it to be preserved! Preserving the
lack of result is trivial. If it is recomputed, great. Until something
*else* invalidates it again, we're good.
The consequence of this is that the invalidate methods on the analysis
manager which operate over many passes now consume their
PreservedAnalyses object, update it to "preserve" every analysis pass to
which it delivers an invalidation (regardless of whether the pass
chooses to be removed, or handles the invalidation itself by updating
itself). Then we return this augmented set from the invalidate routine,
letting the pass manager take the result and use the intersection of
*that* across each pass run to compute the final preserved set. This
accounts for all the places where the early invalidation of an analysis
has already "preserved" it for a future run.
I've beefed up the testing and adjusted the assertions to show that we
no longer repeatedly invalidate or compute the analyses across nested
pass managers.
llvm-svn: 225333
2015-01-07 02:58:35 +01:00
|
|
|
template <typename PassT> void preserve() { preserve(PassT::ID()); }
|
|
|
|
|
2016-11-23 18:53:26 +01:00
|
|
|
/// \brief Mark an abstract ID as preserved, adding it to the set.
|
|
|
|
void preserve(AnalysisKey *ID) {
|
2013-11-20 12:31:50 +01:00
|
|
|
if (!areAllPreserved())
|
2016-11-23 18:53:26 +01:00
|
|
|
PreservedAnalysisIDs.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-11-23 18:53:26 +01:00
|
|
|
PreservedAnalysisIDs = Arg.PreservedAnalysisIDs;
|
2013-11-20 12:31:50 +01:00
|
|
|
return;
|
|
|
|
}
|
2016-11-23 18:53:26 +01:00
|
|
|
for (auto ID : PreservedAnalysisIDs)
|
|
|
|
if (!Arg.PreservedAnalysisIDs.count(ID))
|
|
|
|
PreservedAnalysisIDs.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-11-23 18:53:26 +01:00
|
|
|
PreservedAnalysisIDs = std::move(Arg.PreservedAnalysisIDs);
|
2013-11-20 12:31:50 +01:00
|
|
|
return;
|
|
|
|
}
|
2016-11-23 18:53:26 +01:00
|
|
|
for (auto ID : PreservedAnalysisIDs)
|
|
|
|
if (!Arg.PreservedAnalysisIDs.count(ID))
|
|
|
|
PreservedAnalysisIDs.erase(ID);
|
2013-11-20 12:31:50 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Query whether a pass is marked as preserved by this set.
|
|
|
|
template <typename PassT> bool preserved() const {
|
|
|
|
return preserved(PassT::ID());
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Query whether an abstract pass ID is marked as preserved by this
|
|
|
|
/// set.
|
2016-11-23 18:53:26 +01:00
|
|
|
bool preserved(AnalysisKey *ID) const {
|
|
|
|
return PreservedAnalysisIDs.count(&AllAnalysesKey) ||
|
|
|
|
PreservedAnalysisIDs.count(ID);
|
2013-11-20 12:31:50 +01:00
|
|
|
}
|
|
|
|
|
2016-05-03 23:35:08 +02:00
|
|
|
/// \brief Query whether all of the analyses in the set are preserved.
|
|
|
|
bool preserved(PreservedAnalyses Arg) {
|
|
|
|
if (Arg.areAllPreserved())
|
|
|
|
return areAllPreserved();
|
2016-11-23 18:53:26 +01:00
|
|
|
for (auto ID : Arg.PreservedAnalysisIDs)
|
|
|
|
if (!preserved(ID))
|
2016-05-03 23:35:08 +02:00
|
|
|
return false;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-01-05 13:32:11 +01:00
|
|
|
/// \brief Test whether all passes are preserved.
|
|
|
|
///
|
|
|
|
/// This is used primarily to optimize for the case of no changes which will
|
|
|
|
/// common in many scenarios.
|
|
|
|
bool areAllPreserved() const {
|
2016-11-23 18:53:26 +01:00
|
|
|
return PreservedAnalysisIDs.count(&AllAnalysesKey);
|
2015-01-05 13:32:11 +01:00
|
|
|
}
|
|
|
|
|
2013-11-20 12:31:50 +01:00
|
|
|
private:
|
2016-11-23 18:53:26 +01:00
|
|
|
// A special key used to indicate all analyses.
|
|
|
|
static AnalysisKey AllAnalysesKey;
|
2013-11-20 12:31:50 +01:00
|
|
|
|
2016-11-23 18:53:26 +01:00
|
|
|
SmallPtrSet<AnalysisKey *, 2> PreservedAnalysisIDs;
|
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
|
|
|
///
|
|
|
|
/// This provides some boiler plate for types that are passes.
|
2016-03-11 11:33:22 +01:00
|
|
|
template <typename DerivedT> struct PassInfoMixin {
|
2016-02-26 12:44:45 +01:00
|
|
|
/// Returns the name of the derived pass type.
|
|
|
|
static StringRef name() {
|
|
|
|
StringRef Name = getTypeName<DerivedT>();
|
|
|
|
if (Name.startswith("llvm::"))
|
|
|
|
Name = Name.drop_front(strlen("llvm::"));
|
|
|
|
return Name;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2016-03-11 11:33:22 +01:00
|
|
|
/// A CRTP mix-in to automatically provide informational APIs needed for
|
|
|
|
/// analysis passes.
|
2016-02-26 12:44:45 +01:00
|
|
|
///
|
2016-03-11 11:33:22 +01:00
|
|
|
/// This provides some boiler plate for types that are analysis passes. It
|
|
|
|
/// automatically mixes in \c PassInfoMixin and adds informational APIs
|
|
|
|
/// specifically used for analyses.
|
|
|
|
template <typename DerivedT>
|
|
|
|
struct AnalysisInfoMixin : PassInfoMixin<DerivedT> {
|
2016-11-23 18:53:26 +01:00
|
|
|
/// Returns an opaque, unique ID for this analysis type.
|
|
|
|
///
|
|
|
|
/// 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 optimized
|
|
|
|
/// for pointer-like types using the alignment-provided low bits.
|
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
|
|
|
///
|
|
|
|
/// FIXME: The only reason the derived type needs to provide this rather than
|
|
|
|
/// this mixin providing it is due to broken implementations which cannot
|
|
|
|
/// correctly unique a templated static so that they have the same addresses
|
|
|
|
/// for each instantiation and are definitively emitted once for each
|
|
|
|
/// instantiation. The only currently known platform with this limitation are
|
|
|
|
/// Windows DLL builds, specifically building each part of LLVM as a DLL. If
|
|
|
|
/// we ever remove that build configuration, this mixin can provide the
|
2016-11-23 18:53:26 +01:00
|
|
|
/// static key as well.
|
|
|
|
static AnalysisKey *ID() { return &DerivedT::Key; }
|
2016-02-26 12:44:45 +01:00
|
|
|
};
|
|
|
|
|
2016-08-20 06:57:28 +02:00
|
|
|
/// A class template to provide analysis sets for IR units.
|
|
|
|
///
|
|
|
|
/// Analyses operate on units of IR. It is useful to be able to talk about
|
|
|
|
/// preservation of all analyses for a given unit of IR as a set. This class
|
|
|
|
/// template can be used with the \c PreservedAnalyses API for that purpose and
|
|
|
|
/// the \c AnalysisManager will automatically check and use this set to skip
|
|
|
|
/// invalidation events.
|
|
|
|
///
|
|
|
|
/// Note that you must provide an explicit instantiation declaration and
|
|
|
|
/// definition for this template in order to get the correct behavior on
|
2016-11-23 18:53:26 +01:00
|
|
|
/// Windows. Otherwise, the address of SetKey will not be stable.
|
2016-08-20 06:57:28 +02:00
|
|
|
template <typename IRUnitT>
|
|
|
|
class AllAnalysesOn {
|
|
|
|
public:
|
2016-11-23 18:53:26 +01:00
|
|
|
static AnalysisKey *ID() { return &SetKey; }
|
2016-08-20 06:57:28 +02:00
|
|
|
|
|
|
|
private:
|
2016-11-23 18:53:26 +01:00
|
|
|
static AnalysisKey SetKey;
|
2016-08-20 06:57:28 +02:00
|
|
|
};
|
|
|
|
|
2016-11-23 18:53:26 +01:00
|
|
|
template <typename IRUnitT> AnalysisKey AllAnalysesOn<IRUnitT>::SetKey;
|
2016-08-20 06:57:28 +02:00
|
|
|
|
|
|
|
extern template class AllAnalysesOn<Module>;
|
|
|
|
extern template class AllAnalysesOn<Function>;
|
|
|
|
|
2015-01-13 12:13:56 +01:00
|
|
|
/// \brief Manages a sequence of passes over units of IR.
|
2015-01-03 00:34:39 +01:00
|
|
|
///
|
2015-01-13 12:13:56 +01:00
|
|
|
/// A pass manager contains a sequence of passes to run over units of IR. It is
|
|
|
|
/// itself a valid pass over that unit of IR, and when over some given IR will
|
|
|
|
/// run each pass in sequence. This is the primary and most basic building
|
|
|
|
/// block of a pass pipeline.
|
2015-01-03 00:34:39 +01:00
|
|
|
///
|
2015-01-13 12:13:56 +01:00
|
|
|
/// If it is run with an \c AnalysisManager<IRUnitT> argument, it will propagate
|
2015-01-03 00:34:39 +01:00
|
|
|
/// that analysis manager to each pass it runs, as well as calling the analysis
|
|
|
|
/// manager's invalidation routine with the PreservedAnalyses of each pass it
|
|
|
|
/// runs.
|
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.
|
|
|
|
///
|
|
|
|
/// It can be passed a flag to get debug logging as the passes are run.
|
|
|
|
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)) {}
|
|
|
|
PassManager &operator=(PassManager &&RHS) {
|
|
|
|
Passes = std::move(RHS.Passes);
|
|
|
|
DebugLogging = std::move(RHS.DebugLogging);
|
|
|
|
return *this;
|
|
|
|
}
|
2014-03-10 01:35:47 +01:00
|
|
|
|
2015-01-13 12:13:56 +01:00
|
|
|
/// \brief Run all of the passes in this manager over the IR.
|
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
|
|
|
|
2016-11-28 11:42:21 +01:00
|
|
|
// Finally, we intersect the preserved analyses to compute the aggregate
|
|
|
|
// 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.
|
|
|
|
PA.preserve<AllAnalysesOn<IRUnitT>>();
|
|
|
|
|
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;
|
|
|
|
|
2016-08-19 10:31:47 +02:00
|
|
|
/// \brief A generic analysis pass manager with lazy running and caching of
|
|
|
|
/// results.
|
2015-01-13 03:51:47 +01:00
|
|
|
///
|
2016-08-19 10:31:47 +02:00
|
|
|
/// This analysis manager can be used for any IR unit where the address of the
|
|
|
|
/// IR unit sufficies as its identity. It manages the cache for a unit of IR via
|
|
|
|
/// the address of each unit of IR cached.
|
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:
|
|
|
|
// Now that we've defined our invalidator, we can build types for the concept
|
|
|
|
// types.
|
|
|
|
typedef detail::AnalysisResultConcept<IRUnitT, PreservedAnalyses, Invalidator>
|
|
|
|
ResultConceptT;
|
|
|
|
typedef detail::AnalysisPassConcept<IRUnitT, PreservedAnalyses, Invalidator,
|
|
|
|
ExtraArgTs...>
|
|
|
|
PassConceptT;
|
|
|
|
|
|
|
|
/// \brief List of function analysis pass IDs and associated concept pointers.
|
|
|
|
///
|
|
|
|
/// Requires iterators to be valid across appending new entries and arbitrary
|
|
|
|
/// 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.
|
|
|
|
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
|
|
|
|
/// iterator into a particular result list which is where the actual result
|
|
|
|
/// is stored.
|
|
|
|
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
|
|
|
|
/// if any of those embedded analysis results end up invalidated. We pass in
|
|
|
|
/// an \c Invalidator object from the analysis manager in order to let the
|
|
|
|
/// analysis results themselves define the dependency graph on the fly. This
|
|
|
|
/// avoids building an explicit data structure representation of the
|
|
|
|
/// dependencies between analysis results.
|
|
|
|
class Invalidator {
|
|
|
|
public:
|
|
|
|
/// Trigger the invalidation of some other analysis pass if not already
|
|
|
|
/// handled and return whether it will in fact be invalidated.
|
|
|
|
///
|
|
|
|
/// 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.
|
|
|
|
///
|
|
|
|
/// The first time this is called for a given analysis pass, it will
|
|
|
|
/// trigger the corresponding result's \c invalidate method to be called.
|
|
|
|
/// Subsequent calls will use a cache of the results of that initial call.
|
|
|
|
/// It is an error to form cyclic dependencies between analysis results.
|
|
|
|
///
|
|
|
|
/// This returns true if the given analysis pass's result is invalid and
|
|
|
|
/// any dependecies on it will become invalid as a result.
|
|
|
|
template <typename PassT>
|
|
|
|
bool invalidate(IRUnitT &IR, const PreservedAnalyses &PA) {
|
|
|
|
AnalysisKey *ID = PassT::ID();
|
|
|
|
SmallDenseMap<AnalysisKey *, bool, 8>::iterator IMapI;
|
|
|
|
bool Inserted;
|
|
|
|
std::tie(IMapI, Inserted) = IsResultInvalidated.insert({ID, false});
|
|
|
|
|
|
|
|
// If we've already visited this pass, return true if it was invalidated
|
|
|
|
// and false otherwise.
|
|
|
|
if (!Inserted)
|
|
|
|
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!");
|
|
|
|
|
|
|
|
typedef detail::AnalysisResultModel<IRUnitT, PassT,
|
|
|
|
typename PassT::Result,
|
|
|
|
PreservedAnalyses, Invalidator>
|
|
|
|
ResultModelT;
|
|
|
|
auto &ResultModel = static_cast<ResultModelT &>(*RI->second->second);
|
|
|
|
|
|
|
|
// Mark in the map whether the result should be invalidated and return
|
|
|
|
// that.
|
|
|
|
IMapI->second = ResultModel.invalidate(IR, PA, *this);
|
|
|
|
return IMapI->second;
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
friend class AnalysisManager;
|
|
|
|
|
|
|
|
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.
|
|
|
|
///
|
|
|
|
/// A flag can be passed to indicate that the manager should perform debug
|
|
|
|
/// logging.
|
|
|
|
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();
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
/// \brief Clear any results for a single unit of IR.
|
|
|
|
///
|
|
|
|
/// This doesn't invalidate but directly clears the results. It is useful
|
|
|
|
/// when the IR is being removed and we want to clear out all the memory
|
|
|
|
/// pinned for it.
|
|
|
|
void clear(IRUnitT &IR) {
|
|
|
|
if (DebugLogging)
|
|
|
|
dbgs() << "Clearing all analysis results for: " << IR.getName() << "\n";
|
|
|
|
|
|
|
|
// Clear all the invalidated results associated specifically with this
|
|
|
|
// function.
|
2016-11-23 18:53:26 +01:00
|
|
|
SmallVector<AnalysisKey *, 8> InvalidatedIDs;
|
[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
|
|
|
auto ResultsListI = AnalysisResultLists.find(&IR);
|
|
|
|
if (ResultsListI == AnalysisResultLists.end())
|
|
|
|
return;
|
|
|
|
// Clear the map pointing into the results list.
|
2016-11-23 18:53:26 +01:00
|
|
|
for (auto &IDAndResult : ResultsListI->second)
|
|
|
|
AnalysisResults.erase(std::make_pair(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);
|
|
|
|
}
|
|
|
|
|
2016-08-19 10:31:47 +02:00
|
|
|
/// \brief Clear the analysis result cache.
|
|
|
|
///
|
|
|
|
/// This routine allows cleaning up when the set of IR units itself has
|
|
|
|
/// potentially changed, and thus we can't even look up a a result and
|
[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
|
|
|
/// invalidate it directly. Notably, this does *not* call invalidate
|
|
|
|
/// functions as there is nothing to be done for them.
|
2016-08-19 10:31:47 +02:00
|
|
|
void clear() {
|
|
|
|
AnalysisResults.clear();
|
|
|
|
AnalysisResultLists.clear();
|
|
|
|
}
|
|
|
|
|
2013-11-13 02:12:08 +01:00
|
|
|
/// \brief Get the result of an analysis pass for this module.
|
|
|
|
///
|
|
|
|
/// If there is not a valid cached result in the manager already, this will
|
|
|
|
/// re-run the analysis to produce a valid result.
|
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
|
|
|
}
|
|
|
|
|
2013-11-23 01:38:42 +01:00
|
|
|
/// \brief Get the cached result of an analysis pass for this module.
|
|
|
|
///
|
|
|
|
/// This method never runs the analysis.
|
|
|
|
///
|
|
|
|
/// \returns null if there is no cached result.
|
|
|
|
template <typename PassT>
|
[PM] Sink the reference vs. value decision for IR units out of the
templated interface.
So far, every single IR unit I can come up with has address-identity.
That is, when two units of IR are both active in LLVM, their addresses
will be distinct of the IR is distinct. This is clearly true for
Modules, Functions, BasicBlocks, and Instructions. It turns out that the
only practical way to make the CGSCC stuff work the way we want is to
make it true for SCCs as well. I expect this pattern to continue.
When first designing the pass manager code, I kept this dimension of
freedom in the type parameters, essentially allowing for a wrapper-type
whose address did not form identity. But that really no longer makes
sense and is making the code more complex or subtle for no gain. If we
ever have an actual use case for this, we can figure out what makes
sense then and there. It will be better because then we will have the
actual example in hand.
While the simplifications afforded in this patch are fairly small
(mostly sinking the '&' out of many type parameters onto a few
interfaces), it would have become much more pronounced with subsequent
changes. I have a sequence of changes that will completely remove the
code duplication that currently exists between all of the pass managers
and analysis managers. =] Should make things much cleaner and avoid bug
fixing N times for the N pass managers.
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.
|
|
|
|
///
|
2016-02-18 10:45:17 +01:00
|
|
|
/// The argument is a callable whose result is a pass. This allows passing in
|
|
|
|
/// a lambda to construct the pass.
|
|
|
|
///
|
|
|
|
/// The pass type registered is the result type of calling the argument. If
|
|
|
|
/// that pass has already been registered, then the argument will not be
|
|
|
|
/// called and this function will return false. Otherwise, the pass type
|
|
|
|
/// becomes registered, with the instance provided by calling the argument
|
|
|
|
/// once, and this function returns true.
|
|
|
|
///
|
|
|
|
/// While this returns whether or not the pass type was already registered,
|
|
|
|
/// there in't an independent way to query that as that would be prone to
|
|
|
|
/// risky use when *querying* the analysis manager. Instead, the only
|
|
|
|
/// supported use case is avoiding duplicate registry of an analysis. This
|
|
|
|
/// interface also lends itself to minimizing the number of times we have to
|
|
|
|
/// do lookups for analyses or construct complex passes only to throw them
|
|
|
|
/// away.
|
|
|
|
template <typename PassBuilderT> bool registerPass(PassBuilderT PassBuilder) {
|
|
|
|
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.
|
|
|
|
///
|
|
|
|
/// Note that the analysis result can disregard invalidation.
|
[PM] Sink the reference vs. value decision for IR units out of the
templated interface.
So far, every single IR unit I can come up with has address-identity.
That is, when two units of IR are both active in LLVM, their addresses
will be distinct of the IR is distinct. This is clearly true for
Modules, Functions, BasicBlocks, and Instructions. It turns out that the
only practical way to make the CGSCC stuff work the way we want is to
make it true for SCCs as well. I expect this pattern to continue.
When first designing the pass manager code, I kept this dimension of
freedom in the type parameters, essentially allowing for a wrapper-type
whose address did not form identity. But that really no longer makes
sense and is making the code more complex or subtle for no gain. If we
ever have an actual use case for this, we can figure out what makes
sense then and there. It will be better because then we will have the
actual example in hand.
While the simplifications afforded in this patch are fairly small
(mostly sinking the '&' out of many type parameters onto a few
interfaces), it would have become much more pronounced with subsequent
changes. I have a sequence of changes that will completely remove the
code duplication that currently exists between all of the pass managers
and analysis managers. =] Should make things much cleaner and avoid bug
fixing N times for the N pass managers.
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
|
|
|
}
|
|
|
|
|
2013-11-26 12:24:37 +01:00
|
|
|
/// \brief Invalidate analyses cached 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
|
|
|
|
/// 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-08-20 06:57:28 +02:00
|
|
|
// Short circuit for common cases of all analyses being preserved.
|
|
|
|
if (PA.areAllPreserved() || PA.preserved<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";
|
|
|
|
|
[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
|
|
|
// Track whether each pass's result is invalidated. Memoize the results
|
|
|
|
// using the IsResultInvalidated map.
|
|
|
|
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;
|
|
|
|
|
|
|
|
SmallDenseMap<AnalysisKey *, bool, 8>::iterator IMapI;
|
|
|
|
bool Inserted;
|
|
|
|
std::tie(IMapI, Inserted) = IsResultInvalidated.insert({ID, false});
|
|
|
|
if (!Inserted)
|
|
|
|
// 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.
|
|
|
|
IMapI->second = Result.invalidate(IR, PA, Inv);
|
|
|
|
}
|
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.
|
|
|
|
for (auto I = ResultsList.begin(), E = ResultsList.end(); I != E;) {
|
|
|
|
AnalysisKey *ID = I->first;
|
|
|
|
if (!IsResultInvalidated.lookup(ID)) {
|
2016-08-19 10:31:47 +02:00
|
|
|
++I;
|
[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
|
|
|
continue;
|
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
|
|
|
|
|
|
|
if (DebugLogging)
|
|
|
|
dbgs() << "Invalidating analysis: " << this->lookupPass(ID).name()
|
|
|
|
<< "\n";
|
|
|
|
|
|
|
|
I = ResultsList.erase(I);
|
|
|
|
AnalysisResults.erase({ID, &IR});
|
2016-08-19 10:31:47 +02:00
|
|
|
}
|
|
|
|
if (ResultsList.empty())
|
|
|
|
AnalysisResultLists.erase(&IR);
|
|
|
|
|
2016-11-28 11:42:21 +01:00
|
|
|
return;
|
2013-11-26 12:24:37 +01:00
|
|
|
}
|
|
|
|
|
2016-08-19 10:31:47 +02:00
|
|
|
private:
|
2013-11-26 12:24:37 +01:00
|
|
|
/// \brief Lookup a registered analysis pass.
|
2016-11-23 18:53:26 +01:00
|
|
|
PassConceptT &lookupPass(AnalysisKey *ID) {
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Lookup a registered analysis pass.
|
2016-11-23 18:53:26 +01:00
|
|
|
const PassConceptT &lookupPass(AnalysisKey *ID) const {
|
|
|
|
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-11-23 18:53:26 +01:00
|
|
|
auto &P = this->lookupPass(ID);
|
2015-01-13 23:42:38 +01:00
|
|
|
if (DebugLogging)
|
2015-01-13 03:51:47 +01:00
|
|
|
dbgs() << "Running analysis: " << P.name() << "\n";
|
|
|
|
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-11-23 18:53:26 +01:00
|
|
|
RI = AnalysisResults.find(std::make_pair(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-11-23 18:53:26 +01:00
|
|
|
AnalysisResults.find(std::make_pair(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-11-23 18:53:26 +01:00
|
|
|
AnalysisResults.find(std::make_pair(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-11-23 18:53:26 +01:00
|
|
|
dbgs() << "Invalidating analysis: " << this->lookupPass(ID).name()
|
2015-01-13 03:51:47 +01:00
|
|
|
<< "\n";
|
|
|
|
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
|
|
|
|
|
|
|
/// \brief A flag indicating whether debug logging is enabled.
|
|
|
|
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;
|
|
|
|
|
2013-11-21 03:11:31 +01:00
|
|
|
/// \brief A module analysis which acts as a proxy for a function analysis
|
|
|
|
/// manager.
|
|
|
|
///
|
|
|
|
/// This primarily proxies invalidation information from the module analysis
|
|
|
|
/// manager and module pass manager to a function analysis manager. You should
|
|
|
|
/// never use a function analysis manager from within (transitively) a module
|
|
|
|
/// pass manager unless your parent module pass has received a proxy result
|
|
|
|
/// object for it.
|
2016-02-23 01:05:00 +01:00
|
|
|
///
|
|
|
|
/// Note that the proxy's result is a move-only object and represents ownership
|
|
|
|
/// of the validity of the analyses in the \c FunctionAnalysisManager it
|
|
|
|
/// provides.
|
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:
|
|
|
|
explicit Result(AnalysisManagerT &AM) : AM(&AM) {}
|
|
|
|
Result(Result &&Arg) : AM(std::move(Arg.AM)) {
|
|
|
|
// 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.
|
|
|
|
Arg.AM = nullptr;
|
|
|
|
}
|
|
|
|
Result &operator=(Result &&RHS) {
|
|
|
|
AM = RHS.AM;
|
|
|
|
// 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.
|
|
|
|
RHS.AM = nullptr;
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
~Result() {
|
|
|
|
// AM is cleared in a moved from state where there is nothing to do.
|
|
|
|
if (!AM)
|
|
|
|
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.
|
|
|
|
AM->clear();
|
|
|
|
}
|
2013-11-21 03:11:31 +01:00
|
|
|
|
2016-02-27 11:38:10 +01:00
|
|
|
/// \brief Accessor for the analysis manager.
|
|
|
|
AnalysisManagerT &getManager() { return *AM; }
|
|
|
|
|
|
|
|
/// \brief Handler for invalidation of the module.
|
|
|
|
///
|
|
|
|
/// If this analysis itself is preserved, then we assume that the set of \c
|
|
|
|
/// Function objects in the \c Module hasn't changed and thus we don't need
|
|
|
|
/// to invalidate *all* cached data associated with a \c Function* in the \c
|
|
|
|
/// FunctionAnalysisManager.
|
|
|
|
///
|
|
|
|
/// Regardless of whether this analysis is marked as preserved, all of the
|
|
|
|
/// analyses in the \c FunctionAnalysisManager are potentially invalidated
|
|
|
|
/// based on the set of preserved analyses.
|
[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,
|
|
|
|
typename AnalysisManager<IRUnitT, ExtraArgTs...>::Invalidator &) {
|
2016-02-27 11:38:10 +01:00
|
|
|
// If this proxy isn't marked as preserved, then we can't even invalidate
|
|
|
|
// individual function analyses, there may be an invalid set of Function
|
|
|
|
// objects in the cache making it impossible to incrementally preserve
|
|
|
|
// them. Just clear the entire manager.
|
|
|
|
if (!PA.preserved(InnerAnalysisManagerProxy::ID()))
|
|
|
|
AM->clear();
|
|
|
|
|
|
|
|
// Return false to indicate that this result is still a valid proxy.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
AnalysisManagerT *AM;
|
|
|
|
};
|
|
|
|
|
|
|
|
explicit InnerAnalysisManagerProxy(AnalysisManagerT &AM) : AM(&AM) {}
|
2013-11-21 03:11:31 +01:00
|
|
|
|
|
|
|
/// \brief Run the analysis pass and create our proxy result object.
|
|
|
|
///
|
|
|
|
/// This doesn't do any interesting work, it is primarily used to insert our
|
|
|
|
/// proxy result object into the module analysis cache so that we can proxy
|
|
|
|
/// invalidation to the function analysis manager.
|
|
|
|
///
|
|
|
|
/// In debug builds, it will also assert that the analysis manager is empty
|
|
|
|
/// as no queries should arrive at the function analysis manager prior to
|
|
|
|
/// this analysis being requested.
|
2016-08-19 20:36:06 +02:00
|
|
|
Result run(IRUnitT &IR, AnalysisManager<IRUnitT, ExtraArgTs...> &,
|
|
|
|
ExtraArgTs...) {
|
|
|
|
return Result(*AM);
|
|
|
|
}
|
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
|
|
|
|
2016-02-27 11:38:10 +01:00
|
|
|
AnalysisManagerT *AM;
|
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
|
|
|
extern template class InnerAnalysisManagerProxy<FunctionAnalysisManager,
|
|
|
|
Module>;
|
|
|
|
/// Provide the \c FunctionAnalysisManager to \c Module proxy.
|
|
|
|
typedef InnerAnalysisManagerProxy<FunctionAnalysisManager, Module>
|
|
|
|
FunctionAnalysisManagerModuleProxy;
|
2013-11-21 03:11:31 +01:00
|
|
|
|
2013-11-23 02:25:07 +01:00
|
|
|
/// \brief A function analysis which acts as a proxy for a module analysis
|
|
|
|
/// manager.
|
|
|
|
///
|
|
|
|
/// This primarily provides an accessor to a parent module analysis manager to
|
|
|
|
/// function passes. Only the const interface of the module analysis manager is
|
|
|
|
/// provided to indicate that once inside of a function analysis pass you
|
|
|
|
/// cannot request a module analysis to actually run. Instead, the user must
|
|
|
|
/// rely on the \c getCachedResult API.
|
|
|
|
///
|
|
|
|
/// This proxy *doesn't* manage the invalidation in any way. That is handled by
|
|
|
|
/// the recursive return path of each layer of the pass manager and the
|
|
|
|
/// returned PreservedAnalysis set.
|
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<
|
2016-02-27 11:38:10 +01:00
|
|
|
OuterAnalysisManagerProxy<AnalysisManagerT, IRUnitT>> {
|
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
|
|
|
|
|
|
|
/// \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
|
|
|
|
|
|
|
private:
|
2016-02-27 11:38:10 +01:00
|
|
|
const AnalysisManagerT *AM;
|
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<
|
|
|
|
OuterAnalysisManagerProxy<AnalysisManagerT, IRUnitT>>;
|
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>;
|
|
|
|
/// Provide the \c ModuleAnalysisManager to \c Fucntion proxy.
|
|
|
|
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
|
|
|
|
/// a ModulePassManager. Note that if this pass is constructed with a pointer
|
|
|
|
/// to a \c ModuleAnalysisManager it will run the
|
|
|
|
/// \c FunctionAnalysisManagerModuleProxy analysis prior to running the function
|
|
|
|
/// pass over the module to enable a \c FunctionAnalysisManager to be used
|
|
|
|
/// within this run safely.
|
2015-01-13 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.
|
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) {
|
|
|
|
// Setup the function analysis manager from its proxy.
|
|
|
|
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
|
|
|
|
2016-11-28 11:42:21 +01:00
|
|
|
// By definition we preserve the proxy. We also preserve all analyses on
|
|
|
|
// Function units. This precludes *any* invalidation of function analyses
|
|
|
|
// by the proxy, but that's OK because we've taken care to invalidate
|
|
|
|
// analyses in the function analysis manager incrementally above.
|
|
|
|
PA.preserve<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
|
|
|
}
|
|
|
|
|
2015-01-06 03:10:51 +01:00
|
|
|
/// \brief A template utility pass to force an analysis result to be available.
|
|
|
|
///
|
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();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2015-01-06 05:49:44 +01:00
|
|
|
/// \brief A template utility pass to force an analysis result to be
|
|
|
|
/// invalidated.
|
|
|
|
///
|
|
|
|
/// This is a no-op pass which simply forces a specific analysis result to be
|
|
|
|
/// invalidated when it is run.
|
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.
|
|
|
|
///
|
|
|
|
/// 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
|
|
|
template <typename IRUnitT, typename AnalysisManagerT, typename... ExtraArgTs>
|
|
|
|
PreservedAnalyses run(IRUnitT &Arg, AnalysisManagerT &AM, ExtraArgTs &&...) {
|
2016-03-11 12:05:24 +01:00
|
|
|
// We have to directly invalidate the analysis result as we can't
|
|
|
|
// enumerate all other analyses and use the preserved set to control it.
|
|
|
|
AM.template invalidate<AnalysisT>(Arg);
|
2015-01-06 05:49:44 +01:00
|
|
|
|
|
|
|
return PreservedAnalyses::all();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2015-01-06 10:06:35 +01:00
|
|
|
/// \brief A utility pass that does nothing but preserves no analyses.
|
|
|
|
///
|
|
|
|
/// As a consequence fo not preserving any analyses, this pass will force all
|
|
|
|
/// analysis passes to be re-run to produce fresh results if any are needed.
|
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
|