2014-09-02 21:43:13 +00:00
|
|
|
//===- CFLAliasAnalysis.cpp - CFL-Based Alias Analysis Implementation ------==//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file implements a CFL-based context-insensitive alias analysis
|
|
|
|
// algorithm. It does not depend on types. The algorithm is a mixture of the one
|
|
|
|
// described in "Demand-driven alias analysis for C" by Xin Zheng and Radu
|
|
|
|
// Rugina, and "Fast algorithms for Dyck-CFL-reachability with applications to
|
|
|
|
// Alias Analysis" by Zhang Q, Lyu M R, Yuan H, and Su Z. -- to summarize the
|
|
|
|
// papers, we build a graph of the uses of a variable, where each node is a
|
|
|
|
// memory location, and each edge is an action that happened on that memory
|
2015-06-19 17:32:57 +00:00
|
|
|
// location. The "actions" can be one of Dereference, Reference, or Assign.
|
2014-09-02 21:43:13 +00:00
|
|
|
//
|
|
|
|
// Two variables are considered as aliasing iff you can reach one value's node
|
|
|
|
// from the other value's node and the language formed by concatenating all of
|
|
|
|
// the edge labels (actions) conforms to a context-free grammar.
|
|
|
|
//
|
|
|
|
// Because this algorithm requires a graph search on each query, we execute the
|
|
|
|
// algorithm outlined in "Fast algorithms..." (mentioned above)
|
|
|
|
// in order to transform the graph into sets of variables that may alias in
|
2016-01-28 00:54:01 +00:00
|
|
|
// ~nlogn time (n = number of variables), which makes queries take constant
|
2014-09-02 21:43:13 +00:00
|
|
|
// time.
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2016-01-28 00:54:01 +00:00
|
|
|
// N.B. AliasAnalysis as a whole is phrased as a FunctionPass at the moment, and
|
|
|
|
// CFLAA is interprocedural. This is *technically* A Bad Thing, because
|
|
|
|
// FunctionPasses are only allowed to inspect the Function that they're being
|
|
|
|
// run on. Realistically, this likely isn't a problem until we allow
|
|
|
|
// FunctionPasses to run concurrently.
|
|
|
|
|
2015-08-14 02:42:20 +00:00
|
|
|
#include "llvm/Analysis/CFLAliasAnalysis.h"
|
2014-09-02 21:43:13 +00:00
|
|
|
#include "StratifiedSets.h"
|
|
|
|
#include "llvm/ADT/DenseMap.h"
|
|
|
|
#include "llvm/ADT/None.h"
|
2015-01-14 11:23:27 +00:00
|
|
|
#include "llvm/ADT/Optional.h"
|
2016-06-01 18:39:54 +00:00
|
|
|
#include "llvm/Analysis/MemoryBuiltins.h"
|
|
|
|
#include "llvm/Analysis/TargetLibraryInfo.h"
|
2014-09-02 21:43:13 +00:00
|
|
|
#include "llvm/IR/Constants.h"
|
|
|
|
#include "llvm/IR/Function.h"
|
|
|
|
#include "llvm/IR/InstVisitor.h"
|
2015-01-14 11:23:27 +00:00
|
|
|
#include "llvm/IR/Instructions.h"
|
2014-09-02 21:43:13 +00:00
|
|
|
#include "llvm/Pass.h"
|
2014-09-02 22:13:00 +00:00
|
|
|
#include "llvm/Support/Compiler.h"
|
2015-02-12 03:07:07 +00:00
|
|
|
#include "llvm/Support/Debug.h"
|
2014-09-02 21:43:13 +00:00
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
2015-03-23 19:32:43 +00:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2014-09-02 21:43:13 +00:00
|
|
|
#include <algorithm>
|
|
|
|
#include <cassert>
|
2015-03-23 19:32:43 +00:00
|
|
|
#include <memory>
|
2014-09-02 21:43:13 +00:00
|
|
|
#include <tuple>
|
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
2015-02-12 03:07:07 +00:00
|
|
|
#define DEBUG_TYPE "cfl-aa"
|
|
|
|
|
2016-06-01 18:39:54 +00:00
|
|
|
CFLAAResult::CFLAAResult(const TargetLibraryInfo &TLI)
|
|
|
|
: AAResultBase(), TLI(TLI) {}
|
|
|
|
CFLAAResult::CFLAAResult(CFLAAResult &&Arg)
|
|
|
|
: AAResultBase(std::move(Arg)), TLI(Arg.TLI) {}
|
2016-02-20 03:52:02 +00:00
|
|
|
CFLAAResult::~CFLAAResult() {}
|
2015-08-14 02:42:20 +00:00
|
|
|
|
2016-06-23 18:55:23 +00:00
|
|
|
/// We use InterfaceValue to describe parameters/return value, as well as
|
|
|
|
/// potential memory locations that are pointed to by parameters/return value,
|
|
|
|
/// of a function.
|
|
|
|
/// Index is an integer which represents a single parameter or a return value.
|
|
|
|
/// When the index is 0, it refers to the return value. Non-zero index i refers
|
|
|
|
/// to the i-th parameter.
|
|
|
|
/// DerefLevel indicates the number of dereferences one must perform on the
|
|
|
|
/// parameter/return value to get this InterfaceValue.
|
|
|
|
struct InterfaceValue {
|
|
|
|
unsigned Index;
|
|
|
|
unsigned DerefLevel;
|
|
|
|
};
|
|
|
|
|
|
|
|
bool operator==(InterfaceValue lhs, InterfaceValue rhs) {
|
|
|
|
return lhs.Index == rhs.Index && lhs.DerefLevel == rhs.DerefLevel;
|
|
|
|
}
|
|
|
|
bool operator!=(InterfaceValue lhs, InterfaceValue rhs) {
|
|
|
|
return !(lhs == rhs);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// We use ExternalRelation to describe an externally visible aliasing relations
|
2016-06-20 23:10:56 +00:00
|
|
|
/// between parameters/return value of a function.
|
|
|
|
struct ExternalRelation {
|
2016-06-23 18:55:23 +00:00
|
|
|
InterfaceValue From, To;
|
2016-06-20 23:10:56 +00:00
|
|
|
};
|
|
|
|
|
2016-04-13 23:27:37 +00:00
|
|
|
/// Information we have about a function and would like to keep around.
|
2016-06-20 23:10:56 +00:00
|
|
|
class CFLAAResult::FunctionInfo {
|
2015-08-14 02:42:20 +00:00
|
|
|
StratifiedSets<Value *> Sets;
|
|
|
|
|
2016-06-20 23:10:56 +00:00
|
|
|
// RetParamRelations is a collection of ExternalRelations.
|
|
|
|
SmallVector<ExternalRelation, 8> RetParamRelations;
|
|
|
|
|
|
|
|
public:
|
|
|
|
FunctionInfo(Function &Fn, const SmallVectorImpl<Value *> &RetVals,
|
|
|
|
StratifiedSets<Value *> S);
|
|
|
|
|
|
|
|
const StratifiedSets<Value *> &getStratifiedSets() const { return Sets; }
|
|
|
|
const SmallVectorImpl<ExternalRelation> &getRetParamRelations() const {
|
|
|
|
return RetParamRelations;
|
|
|
|
}
|
2015-08-14 02:42:20 +00:00
|
|
|
};
|
|
|
|
|
2016-04-13 23:27:37 +00:00
|
|
|
/// Try to go from a Value* to a Function*. Never returns nullptr.
|
2014-09-02 21:43:13 +00:00
|
|
|
static Optional<Function *> parentFunctionOfValue(Value *);
|
|
|
|
|
2016-04-13 23:27:37 +00:00
|
|
|
/// Returns possible functions called by the Inst* into the given
|
|
|
|
/// SmallVectorImpl. Returns true if targets found, false otherwise. This is
|
|
|
|
/// templated so we can use it with CallInsts and InvokeInsts.
|
2016-06-14 18:12:28 +00:00
|
|
|
static bool getPossibleTargets(CallSite, SmallVectorImpl<Function *> &);
|
2014-09-02 21:43:13 +00:00
|
|
|
|
2014-09-02 23:50:01 +00:00
|
|
|
const StratifiedIndex StratifiedLink::SetSentinel =
|
2015-03-15 00:52:21 +00:00
|
|
|
std::numeric_limits<StratifiedIndex>::max();
|
2014-09-02 23:50:01 +00:00
|
|
|
|
2014-09-02 21:43:13 +00:00
|
|
|
namespace {
|
2016-04-13 23:27:37 +00:00
|
|
|
/// StratifiedInfo Attribute things.
|
2014-09-02 21:43:13 +00:00
|
|
|
typedef unsigned StratifiedAttr;
|
2014-09-02 22:13:00 +00:00
|
|
|
LLVM_CONSTEXPR unsigned MaxStratifiedAttrIndex = NumStratifiedAttrs;
|
2016-06-07 18:35:37 +00:00
|
|
|
LLVM_CONSTEXPR unsigned AttrEscapedIndex = 0;
|
|
|
|
LLVM_CONSTEXPR unsigned AttrUnknownIndex = 1;
|
|
|
|
LLVM_CONSTEXPR unsigned AttrGlobalIndex = 2;
|
2015-03-10 02:40:06 +00:00
|
|
|
LLVM_CONSTEXPR unsigned AttrFirstArgIndex = 3;
|
2014-09-02 22:13:00 +00:00
|
|
|
LLVM_CONSTEXPR unsigned AttrLastArgIndex = MaxStratifiedAttrIndex;
|
|
|
|
LLVM_CONSTEXPR unsigned AttrMaxNumArgs = AttrLastArgIndex - AttrFirstArgIndex;
|
2014-09-02 21:43:13 +00:00
|
|
|
|
2014-09-02 22:13:00 +00:00
|
|
|
LLVM_CONSTEXPR StratifiedAttr AttrNone = 0;
|
2016-06-07 18:35:37 +00:00
|
|
|
LLVM_CONSTEXPR StratifiedAttr AttrEscaped = 1 << AttrEscapedIndex;
|
2015-03-10 02:40:06 +00:00
|
|
|
LLVM_CONSTEXPR StratifiedAttr AttrUnknown = 1 << AttrUnknownIndex;
|
2016-06-07 18:35:37 +00:00
|
|
|
LLVM_CONSTEXPR StratifiedAttr AttrGlobal = 1 << AttrGlobalIndex;
|
2014-09-02 21:43:13 +00:00
|
|
|
|
2016-06-20 23:10:56 +00:00
|
|
|
/// The maximum number of arguments we can put into a summary.
|
|
|
|
LLVM_CONSTEXPR unsigned MaxSupportedArgsInSummary = 50;
|
|
|
|
|
2016-04-13 23:27:37 +00:00
|
|
|
/// StratifiedSets call for knowledge of "direction", so this is how we
|
|
|
|
/// represent that locally.
|
2014-09-02 21:43:13 +00:00
|
|
|
enum class Level { Same, Above, Below };
|
|
|
|
|
2016-04-13 23:27:37 +00:00
|
|
|
/// Edges can be one of four "weights" -- each weight must have an inverse
|
|
|
|
/// weight (Assign has Assign; Reference has Dereference).
|
2014-09-02 21:43:13 +00:00
|
|
|
enum class EdgeType {
|
2016-04-13 23:27:37 +00:00
|
|
|
/// The weight assigned when assigning from or to a value. For example, in:
|
|
|
|
/// %b = getelementptr %a, 0
|
|
|
|
/// ...The relationships are %b assign %a, and %a assign %b. This used to be
|
|
|
|
/// two edges, but having a distinction bought us nothing.
|
2014-09-02 21:43:13 +00:00
|
|
|
Assign,
|
|
|
|
|
2016-04-13 23:27:37 +00:00
|
|
|
/// The edge used when we have an edge going from some handle to a Value.
|
|
|
|
/// Examples of this include:
|
|
|
|
/// %b = load %a (%b Dereference %a)
|
|
|
|
/// %b = extractelement %a, 0 (%a Dereference %b)
|
2014-09-02 21:43:13 +00:00
|
|
|
Dereference,
|
|
|
|
|
2016-04-13 23:27:37 +00:00
|
|
|
/// The edge used when our edge goes from a value to a handle that may have
|
|
|
|
/// contained it at some point. Examples:
|
|
|
|
/// %b = load %a (%a Reference %b)
|
|
|
|
/// %b = extractelement %a, 0 (%b Reference %a)
|
2014-09-02 21:43:13 +00:00
|
|
|
Reference
|
|
|
|
};
|
|
|
|
|
2016-06-14 18:12:28 +00:00
|
|
|
/// The Program Expression Graph (PEG) of CFL analysis
|
|
|
|
class CFLGraph {
|
|
|
|
typedef Value *Node;
|
|
|
|
|
|
|
|
struct Edge {
|
|
|
|
EdgeType Type;
|
|
|
|
Node Other;
|
|
|
|
};
|
|
|
|
|
|
|
|
typedef std::vector<Edge> EdgeList;
|
2016-06-15 20:43:41 +00:00
|
|
|
|
|
|
|
struct NodeInfo {
|
|
|
|
EdgeList Edges;
|
|
|
|
StratifiedAttrs Attr;
|
|
|
|
};
|
|
|
|
|
|
|
|
typedef DenseMap<Node, NodeInfo> NodeMap;
|
2016-06-14 18:12:28 +00:00
|
|
|
NodeMap NodeImpls;
|
|
|
|
|
|
|
|
// Gets the inverse of a given EdgeType.
|
|
|
|
static EdgeType flipWeight(EdgeType Initial) {
|
|
|
|
switch (Initial) {
|
|
|
|
case EdgeType::Assign:
|
|
|
|
return EdgeType::Assign;
|
|
|
|
case EdgeType::Dereference:
|
|
|
|
return EdgeType::Reference;
|
|
|
|
case EdgeType::Reference:
|
|
|
|
return EdgeType::Dereference;
|
|
|
|
}
|
|
|
|
llvm_unreachable("Incomplete coverage of EdgeType enum");
|
|
|
|
}
|
|
|
|
|
2016-06-15 20:43:41 +00:00
|
|
|
const NodeInfo *getNode(Node N) const {
|
2016-06-14 18:12:28 +00:00
|
|
|
auto Itr = NodeImpls.find(N);
|
|
|
|
if (Itr == NodeImpls.end())
|
|
|
|
return nullptr;
|
|
|
|
return &Itr->second;
|
|
|
|
}
|
2016-06-15 20:43:41 +00:00
|
|
|
NodeInfo *getNode(Node N) {
|
2016-06-14 18:12:28 +00:00
|
|
|
auto Itr = NodeImpls.find(N);
|
|
|
|
if (Itr == NodeImpls.end())
|
|
|
|
return nullptr;
|
|
|
|
return &Itr->second;
|
|
|
|
}
|
|
|
|
|
|
|
|
static Node nodeDeref(const NodeMap::value_type &P) { return P.first; }
|
|
|
|
typedef std::pointer_to_unary_function<const NodeMap::value_type &, Node>
|
|
|
|
NodeDerefFun;
|
2014-09-02 21:43:13 +00:00
|
|
|
|
2016-06-14 18:12:28 +00:00
|
|
|
public:
|
|
|
|
typedef EdgeList::const_iterator const_edge_iterator;
|
|
|
|
typedef mapped_iterator<NodeMap::const_iterator, NodeDerefFun>
|
|
|
|
const_node_iterator;
|
|
|
|
|
|
|
|
bool addNode(Node N) {
|
2016-06-15 20:43:41 +00:00
|
|
|
return NodeImpls.insert(std::make_pair(N, NodeInfo{EdgeList(), AttrNone}))
|
|
|
|
.second;
|
2016-06-14 18:12:28 +00:00
|
|
|
}
|
2014-09-02 21:43:13 +00:00
|
|
|
|
2016-06-15 20:43:41 +00:00
|
|
|
void addAttr(Node N, StratifiedAttrs Attr) {
|
|
|
|
auto *Info = getNode(N);
|
|
|
|
assert(Info != nullptr);
|
|
|
|
Info->Attr |= Attr;
|
|
|
|
}
|
|
|
|
|
|
|
|
void addEdge(Node From, Node To, EdgeType Type) {
|
|
|
|
auto *FromInfo = getNode(From);
|
|
|
|
assert(FromInfo != nullptr);
|
|
|
|
auto *ToInfo = getNode(To);
|
|
|
|
assert(ToInfo != nullptr);
|
2014-09-02 21:43:13 +00:00
|
|
|
|
2016-06-15 20:43:41 +00:00
|
|
|
FromInfo->Edges.push_back(Edge{Type, To});
|
|
|
|
ToInfo->Edges.push_back(Edge{flipWeight(Type), From});
|
|
|
|
}
|
|
|
|
|
|
|
|
StratifiedAttrs attrFor(Node N) const {
|
|
|
|
auto *Info = getNode(N);
|
|
|
|
assert(Info != nullptr);
|
|
|
|
return Info->Attr;
|
2016-06-14 18:12:28 +00:00
|
|
|
}
|
2014-09-02 21:43:13 +00:00
|
|
|
|
2016-06-14 18:12:28 +00:00
|
|
|
iterator_range<const_edge_iterator> edgesFor(Node N) const {
|
2016-06-15 20:43:41 +00:00
|
|
|
auto *Info = getNode(N);
|
|
|
|
assert(Info != nullptr);
|
|
|
|
auto &Edges = Info->Edges;
|
|
|
|
return make_range(Edges.begin(), Edges.end());
|
2016-06-14 18:12:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
iterator_range<const_node_iterator> nodes() const {
|
|
|
|
return make_range<const_node_iterator>(
|
|
|
|
map_iterator(NodeImpls.begin(), NodeDerefFun(nodeDeref)),
|
|
|
|
map_iterator(NodeImpls.end(), NodeDerefFun(nodeDeref)));
|
|
|
|
}
|
|
|
|
|
|
|
|
bool empty() const { return NodeImpls.empty(); }
|
|
|
|
std::size_t size() const { return NodeImpls.size(); }
|
2014-09-02 21:43:13 +00:00
|
|
|
};
|
|
|
|
|
2016-06-23 18:55:23 +00:00
|
|
|
// Interprocedural assignment edges that CFLGraph may not easily model
|
|
|
|
struct InterprocEdge {
|
|
|
|
struct Node {
|
|
|
|
Value *Value;
|
|
|
|
unsigned DerefLevel;
|
|
|
|
};
|
|
|
|
|
|
|
|
Node From, To;
|
|
|
|
};
|
|
|
|
|
2016-04-13 23:27:37 +00:00
|
|
|
/// Gets the edges our graph should have, based on an Instruction*
|
2014-09-02 21:43:13 +00:00
|
|
|
class GetEdgesVisitor : public InstVisitor<GetEdgesVisitor, void> {
|
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
with the new pass manager, and no longer relying on analysis groups.
This builds essentially a ground-up new AA infrastructure stack for
LLVM. The core ideas are the same that are used throughout the new pass
manager: type erased polymorphism and direct composition. The design is
as follows:
- FunctionAAResults is a type-erasing alias analysis results aggregation
interface to walk a single query across a range of results from
different alias analyses. Currently this is function-specific as we
always assume that aliasing queries are *within* a function.
- AAResultBase is a CRTP utility providing stub implementations of
various parts of the alias analysis result concept, notably in several
cases in terms of other more general parts of the interface. This can
be used to implement only a narrow part of the interface rather than
the entire interface. This isn't really ideal, this logic should be
hoisted into FunctionAAResults as currently it will cause
a significant amount of redundant work, but it faithfully models the
behavior of the prior infrastructure.
- All the alias analysis passes are ported to be wrapper passes for the
legacy PM and new-style analysis passes for the new PM with a shared
result object. In some cases (most notably CFL), this is an extremely
naive approach that we should revisit when we can specialize for the
new pass manager.
- BasicAA has been restructured to reflect that it is much more
fundamentally a function analysis because it uses dominator trees and
loop info that need to be constructed for each function.
All of the references to getting alias analysis results have been
updated to use the new aggregation interface. All the preservation and
other pass management code has been updated accordingly.
The way the FunctionAAResultsWrapperPass works is to detect the
available alias analyses when run, and add them to the results object.
This means that we should be able to continue to respect when various
passes are added to the pipeline, for example adding CFL or adding TBAA
passes should just cause their results to be available and to get folded
into this. The exception to this rule is BasicAA which really needs to
be a function pass due to using dominator trees and loop info. As
a consequence, the FunctionAAResultsWrapperPass directly depends on
BasicAA and always includes it in the aggregation.
This has significant implications for preserving analyses. Generally,
most passes shouldn't bother preserving FunctionAAResultsWrapperPass
because rebuilding the results just updates the set of known AA passes.
The exception to this rule are LoopPass instances which need to preserve
all the function analyses that the loop pass manager will end up
needing. This means preserving both BasicAAWrapperPass and the
aggregating FunctionAAResultsWrapperPass.
Now, when preserving an alias analysis, you do so by directly preserving
that analysis. This is only necessary for non-immutable-pass-provided
alias analyses though, and there are only three of interest: BasicAA,
GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
preserved when needed because it (like DominatorTree and LoopInfo) is
marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
set everywhere we previously were preserving all of AliasAnalysis, and
I've added SCEVAA in the intersection of that with where we preserve
SCEV itself.
One significant challenge to all of this is that the CGSCC passes were
actually using the alias analysis implementations by taking advantage of
a pretty amazing set of loop holes in the old pass manager's analysis
management code which allowed analysis groups to slide through in many
cases. Moving away from analysis groups makes this problem much more
obvious. To fix it, I've leveraged the flexibility the design of the new
PM components provides to just directly construct the relevant alias
analyses for the relevant functions in the IPO passes that need them.
This is a bit hacky, but should go away with the new pass manager, and
is already in many ways cleaner than the prior state.
Another significant challenge is that various facilities of the old
alias analysis infrastructure just don't fit any more. The most
significant of these is the alias analysis 'counter' pass. That pass
relied on the ability to snoop on AA queries at different points in the
analysis group chain. Instead, I'm planning to build printing
functionality directly into the aggregation layer. I've not included
that in this patch merely to keep it smaller.
Note that all of this needs a nearly complete rewrite of the AA
documentation. I'm planning to do that, but I'd like to make sure the
new design settles, and to flesh out a bit more of what it looks like in
the new pass manager first.
Differential Revision: http://reviews.llvm.org/D12080
llvm-svn: 247167
2015-09-09 17:55:00 +00:00
|
|
|
CFLAAResult &AA;
|
2016-06-01 18:39:54 +00:00
|
|
|
const TargetLibraryInfo &TLI;
|
2014-09-02 21:43:13 +00:00
|
|
|
|
2016-06-14 18:12:28 +00:00
|
|
|
CFLGraph &Graph;
|
|
|
|
SmallPtrSetImpl<Value *> &Externals;
|
|
|
|
SmallPtrSetImpl<Value *> &Escapes;
|
2016-06-23 18:55:23 +00:00
|
|
|
SmallVectorImpl<InterprocEdge> &InterprocEdges;
|
2016-06-14 18:12:28 +00:00
|
|
|
|
|
|
|
static bool hasUsefulEdges(ConstantExpr *CE) {
|
|
|
|
// ConstantExpr doesn't have terminators, invokes, or fences, so only needs
|
|
|
|
// to check for compares.
|
|
|
|
return CE->getOpcode() != Instruction::ICmp &&
|
|
|
|
CE->getOpcode() != Instruction::FCmp;
|
|
|
|
}
|
|
|
|
|
|
|
|
void addNode(Value *Val) {
|
|
|
|
if (!Graph.addNode(Val))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (isa<GlobalValue>(Val))
|
|
|
|
Externals.insert(Val);
|
|
|
|
else if (auto CExpr = dyn_cast<ConstantExpr>(Val))
|
|
|
|
if (hasUsefulEdges(CExpr))
|
|
|
|
visitConstantExpr(CExpr);
|
|
|
|
}
|
|
|
|
|
2016-06-15 20:43:41 +00:00
|
|
|
void addNodeWithAttr(Value *Val, StratifiedAttrs Attr) {
|
|
|
|
addNode(Val);
|
|
|
|
Graph.addAttr(Val, Attr);
|
|
|
|
}
|
|
|
|
|
|
|
|
void addEdge(Value *From, Value *To, EdgeType Type) {
|
|
|
|
if (!From->getType()->isPointerTy() || !To->getType()->isPointerTy())
|
|
|
|
return;
|
2016-06-14 18:12:28 +00:00
|
|
|
addNode(From);
|
|
|
|
if (To != From)
|
|
|
|
addNode(To);
|
2016-06-15 20:43:41 +00:00
|
|
|
Graph.addEdge(From, To, Type);
|
2016-06-14 18:12:28 +00:00
|
|
|
}
|
|
|
|
|
2014-09-02 21:43:13 +00:00
|
|
|
public:
|
2016-06-14 18:12:28 +00:00
|
|
|
GetEdgesVisitor(CFLAAResult &AA, const TargetLibraryInfo &TLI,
|
|
|
|
CFLGraph &Graph, SmallPtrSetImpl<Value *> &Externals,
|
2016-06-23 18:55:23 +00:00
|
|
|
SmallPtrSetImpl<Value *> &Escapes,
|
|
|
|
SmallVectorImpl<InterprocEdge> &InterprocEdges)
|
|
|
|
: AA(AA), TLI(TLI), Graph(Graph), Externals(Externals), Escapes(Escapes),
|
|
|
|
InterprocEdges(InterprocEdges) {}
|
2014-09-02 21:43:13 +00:00
|
|
|
|
|
|
|
void visitInstruction(Instruction &) {
|
|
|
|
llvm_unreachable("Unsupported instruction encountered");
|
|
|
|
}
|
|
|
|
|
2015-03-10 02:40:06 +00:00
|
|
|
void visitPtrToIntInst(PtrToIntInst &Inst) {
|
|
|
|
auto *Ptr = Inst.getOperand(0);
|
2016-06-15 20:43:41 +00:00
|
|
|
addNodeWithAttr(Ptr, AttrEscaped);
|
2015-03-10 02:40:06 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void visitIntToPtrInst(IntToPtrInst &Inst) {
|
|
|
|
auto *Ptr = &Inst;
|
2016-06-15 20:43:41 +00:00
|
|
|
addNodeWithAttr(Ptr, AttrUnknown);
|
2015-03-10 02:40:06 +00:00
|
|
|
}
|
|
|
|
|
2014-09-02 21:43:13 +00:00
|
|
|
void visitCastInst(CastInst &Inst) {
|
2016-06-14 18:12:28 +00:00
|
|
|
auto *Src = Inst.getOperand(0);
|
2016-06-15 20:43:41 +00:00
|
|
|
addEdge(Src, &Inst, EdgeType::Assign);
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void visitBinaryOperator(BinaryOperator &Inst) {
|
|
|
|
auto *Op1 = Inst.getOperand(0);
|
|
|
|
auto *Op2 = Inst.getOperand(1);
|
2016-06-15 20:43:41 +00:00
|
|
|
addEdge(Op1, &Inst, EdgeType::Assign);
|
|
|
|
addEdge(Op2, &Inst, EdgeType::Assign);
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void visitAtomicCmpXchgInst(AtomicCmpXchgInst &Inst) {
|
|
|
|
auto *Ptr = Inst.getPointerOperand();
|
|
|
|
auto *Val = Inst.getNewValOperand();
|
2016-06-15 20:43:41 +00:00
|
|
|
addEdge(Ptr, Val, EdgeType::Dereference);
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void visitAtomicRMWInst(AtomicRMWInst &Inst) {
|
|
|
|
auto *Ptr = Inst.getPointerOperand();
|
|
|
|
auto *Val = Inst.getValOperand();
|
2016-06-15 20:43:41 +00:00
|
|
|
addEdge(Ptr, Val, EdgeType::Dereference);
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void visitPHINode(PHINode &Inst) {
|
2016-01-28 00:54:01 +00:00
|
|
|
for (Value *Val : Inst.incoming_values())
|
2016-06-15 20:43:41 +00:00
|
|
|
addEdge(Val, &Inst, EdgeType::Assign);
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void visitGetElementPtrInst(GetElementPtrInst &Inst) {
|
|
|
|
auto *Op = Inst.getPointerOperand();
|
2016-06-15 20:43:41 +00:00
|
|
|
addEdge(Op, &Inst, EdgeType::Assign);
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void visitSelectInst(SelectInst &Inst) {
|
2015-01-26 17:31:17 +00:00
|
|
|
// Condition is not processed here (The actual statement producing
|
|
|
|
// the condition result is processed elsewhere). For select, the
|
|
|
|
// condition is evaluated, but not loaded, stored, or assigned
|
|
|
|
// simply as a result of being the condition of a select.
|
|
|
|
|
2014-09-02 21:43:13 +00:00
|
|
|
auto *TrueVal = Inst.getTrueValue();
|
|
|
|
auto *FalseVal = Inst.getFalseValue();
|
2016-06-15 20:43:41 +00:00
|
|
|
addEdge(TrueVal, &Inst, EdgeType::Assign);
|
|
|
|
addEdge(FalseVal, &Inst, EdgeType::Assign);
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
|
|
|
|
2016-06-14 18:12:28 +00:00
|
|
|
void visitAllocaInst(AllocaInst &Inst) { Graph.addNode(&Inst); }
|
2014-09-02 21:43:13 +00:00
|
|
|
|
|
|
|
void visitLoadInst(LoadInst &Inst) {
|
|
|
|
auto *Ptr = Inst.getPointerOperand();
|
|
|
|
auto *Val = &Inst;
|
2016-06-15 20:43:41 +00:00
|
|
|
addEdge(Val, Ptr, EdgeType::Reference);
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void visitStoreInst(StoreInst &Inst) {
|
|
|
|
auto *Ptr = Inst.getPointerOperand();
|
|
|
|
auto *Val = Inst.getValueOperand();
|
2016-06-15 20:43:41 +00:00
|
|
|
addEdge(Ptr, Val, EdgeType::Dereference);
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
|
|
|
|
2014-10-14 20:51:26 +00:00
|
|
|
void visitVAArgInst(VAArgInst &Inst) {
|
|
|
|
// We can't fully model va_arg here. For *Ptr = Inst.getOperand(0), it does
|
|
|
|
// two things:
|
|
|
|
// 1. Loads a value from *((T*)*Ptr).
|
|
|
|
// 2. Increments (stores to) *Ptr by some target-specific amount.
|
|
|
|
// For now, we'll handle this like a landingpad instruction (by placing the
|
|
|
|
// result in its own group, and having that group alias externals).
|
2016-06-15 20:43:41 +00:00
|
|
|
addNodeWithAttr(&Inst, AttrUnknown);
|
2014-10-14 20:51:26 +00:00
|
|
|
}
|
|
|
|
|
2014-09-02 21:43:13 +00:00
|
|
|
static bool isFunctionExternal(Function *Fn) {
|
2016-06-21 01:42:47 +00:00
|
|
|
return !Fn->hasExactDefinition();
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
|
|
|
|
2016-06-20 23:10:56 +00:00
|
|
|
bool tryInterproceduralAnalysis(CallSite CS,
|
|
|
|
const SmallVectorImpl<Function *> &Fns) {
|
2014-09-02 21:43:13 +00:00
|
|
|
assert(Fns.size() > 0);
|
|
|
|
|
2016-06-20 23:10:56 +00:00
|
|
|
if (CS.arg_size() > MaxSupportedArgsInSummary)
|
2014-09-02 21:43:13 +00:00
|
|
|
return false;
|
|
|
|
|
|
|
|
// Exit early if we'll fail anyway
|
|
|
|
for (auto *Fn : Fns) {
|
|
|
|
if (isFunctionExternal(Fn) || Fn->isVarArg())
|
|
|
|
return false;
|
2016-06-20 23:10:56 +00:00
|
|
|
// Fail if the caller does not provide enough arguments
|
|
|
|
assert(Fn->arg_size() <= CS.arg_size());
|
2014-09-02 21:43:13 +00:00
|
|
|
auto &MaybeInfo = AA.ensureCached(Fn);
|
|
|
|
if (!MaybeInfo.hasValue())
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (auto *Fn : Fns) {
|
2016-06-20 23:10:56 +00:00
|
|
|
auto &FnInfo = AA.ensureCached(Fn);
|
|
|
|
assert(FnInfo.hasValue());
|
|
|
|
|
|
|
|
auto &RetParamRelations = FnInfo->getRetParamRelations();
|
|
|
|
for (auto &Relation : RetParamRelations) {
|
2016-06-23 18:55:23 +00:00
|
|
|
auto FromIndex = Relation.From.Index;
|
|
|
|
auto ToIndex = Relation.To.Index;
|
2016-06-20 23:10:56 +00:00
|
|
|
auto FromVal = (FromIndex == 0) ? CS.getInstruction()
|
|
|
|
: CS.getArgument(FromIndex - 1);
|
|
|
|
auto ToVal =
|
|
|
|
(ToIndex == 0) ? CS.getInstruction() : CS.getArgument(ToIndex - 1);
|
|
|
|
if (FromVal->getType()->isPointerTy() &&
|
2016-06-23 18:55:23 +00:00
|
|
|
ToVal->getType()->isPointerTy()) {
|
|
|
|
auto FromLevel = Relation.From.DerefLevel;
|
|
|
|
auto ToLevel = Relation.To.DerefLevel;
|
|
|
|
InterprocEdges.push_back(
|
|
|
|
InterprocEdge{InterprocEdge::Node{FromVal, FromLevel},
|
|
|
|
InterprocEdge::Node{ToVal, ToLevel}});
|
|
|
|
}
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
2016-06-15 20:43:41 +00:00
|
|
|
}
|
2016-06-14 18:12:28 +00:00
|
|
|
|
2014-09-02 21:43:13 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2016-06-14 18:12:28 +00:00
|
|
|
void visitCallSite(CallSite CS) {
|
|
|
|
auto Inst = CS.getInstruction();
|
|
|
|
|
|
|
|
// Make sure all arguments and return value are added to the graph first
|
|
|
|
for (Value *V : CS.args())
|
|
|
|
addNode(V);
|
2016-06-20 23:10:56 +00:00
|
|
|
if (Inst->getType()->isPointerTy())
|
2016-06-14 18:12:28 +00:00
|
|
|
addNode(Inst);
|
|
|
|
|
2016-06-01 18:39:54 +00:00
|
|
|
// Check if Inst is a call to a library function that allocates/deallocates
|
|
|
|
// on the heap. Those kinds of functions do not introduce any aliases.
|
|
|
|
// TODO: address other common library functions such as realloc(), strdup(),
|
|
|
|
// etc.
|
2016-06-14 18:12:28 +00:00
|
|
|
if (isMallocLikeFn(Inst, &TLI) || isCallocLikeFn(Inst, &TLI) ||
|
|
|
|
isFreeCall(Inst, &TLI))
|
2016-06-01 18:39:54 +00:00
|
|
|
return;
|
|
|
|
|
2015-08-28 00:16:18 +00:00
|
|
|
// TODO: Add support for noalias args/all the other fun function attributes
|
|
|
|
// that we can tack on.
|
2014-09-02 21:43:13 +00:00
|
|
|
SmallVector<Function *, 4> Targets;
|
2016-06-14 18:12:28 +00:00
|
|
|
if (getPossibleTargets(CS, Targets))
|
2016-06-20 23:10:56 +00:00
|
|
|
if (tryInterproceduralAnalysis(CS, Targets))
|
2014-09-02 21:43:13 +00:00
|
|
|
return;
|
|
|
|
|
2015-08-28 00:16:18 +00:00
|
|
|
// Because the function is opaque, we need to note that anything
|
2016-06-14 18:12:28 +00:00
|
|
|
// could have happened to the arguments (unless the function is marked
|
|
|
|
// readonly or readnone), and that the result could alias just about
|
|
|
|
// anything, too (unless the result is marked noalias).
|
|
|
|
if (!CS.onlyReadsMemory())
|
|
|
|
for (Value *V : CS.args()) {
|
2016-06-15 20:43:41 +00:00
|
|
|
if (V->getType()->isPointerTy())
|
|
|
|
Escapes.insert(V);
|
2016-06-14 18:12:28 +00:00
|
|
|
}
|
2014-09-02 21:43:13 +00:00
|
|
|
|
2016-06-20 23:10:56 +00:00
|
|
|
if (Inst->getType()->isPointerTy()) {
|
2016-06-14 18:12:28 +00:00
|
|
|
auto *Fn = CS.getCalledFunction();
|
|
|
|
if (Fn == nullptr || !Fn->doesNotAlias(0))
|
2016-06-15 20:43:41 +00:00
|
|
|
Graph.addAttr(Inst, AttrUnknown);
|
2016-06-14 18:12:28 +00:00
|
|
|
}
|
|
|
|
}
|
2014-09-02 21:43:13 +00:00
|
|
|
|
2016-04-13 23:27:37 +00:00
|
|
|
/// Because vectors/aggregates are immutable and unaddressable, there's
|
|
|
|
/// nothing we can do to coax a value out of them, other than calling
|
|
|
|
/// Extract{Element,Value}. We can effectively treat them as pointers to
|
|
|
|
/// arbitrary memory locations we can store in and load from.
|
2014-09-02 21:43:13 +00:00
|
|
|
void visitExtractElementInst(ExtractElementInst &Inst) {
|
|
|
|
auto *Ptr = Inst.getVectorOperand();
|
|
|
|
auto *Val = &Inst;
|
2016-06-15 20:43:41 +00:00
|
|
|
addEdge(Val, Ptr, EdgeType::Reference);
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void visitInsertElementInst(InsertElementInst &Inst) {
|
|
|
|
auto *Vec = Inst.getOperand(0);
|
|
|
|
auto *Val = Inst.getOperand(1);
|
2016-06-15 20:43:41 +00:00
|
|
|
addEdge(Vec, &Inst, EdgeType::Assign);
|
|
|
|
addEdge(&Inst, Val, EdgeType::Dereference);
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void visitLandingPadInst(LandingPadInst &Inst) {
|
|
|
|
// Exceptions come from "nowhere", from our analysis' perspective.
|
|
|
|
// So we place the instruction its own group, noting that said group may
|
|
|
|
// alias externals
|
2016-06-15 20:43:41 +00:00
|
|
|
addNodeWithAttr(&Inst, AttrUnknown);
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void visitInsertValueInst(InsertValueInst &Inst) {
|
|
|
|
auto *Agg = Inst.getOperand(0);
|
|
|
|
auto *Val = Inst.getOperand(1);
|
2016-06-15 20:43:41 +00:00
|
|
|
addEdge(Agg, &Inst, EdgeType::Assign);
|
|
|
|
addEdge(&Inst, Val, EdgeType::Dereference);
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void visitExtractValueInst(ExtractValueInst &Inst) {
|
|
|
|
auto *Ptr = Inst.getAggregateOperand();
|
2016-06-15 20:43:41 +00:00
|
|
|
addEdge(&Inst, Ptr, EdgeType::Reference);
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void visitShuffleVectorInst(ShuffleVectorInst &Inst) {
|
|
|
|
auto *From1 = Inst.getOperand(0);
|
|
|
|
auto *From2 = Inst.getOperand(1);
|
2016-06-15 20:43:41 +00:00
|
|
|
addEdge(From1, &Inst, EdgeType::Assign);
|
|
|
|
addEdge(From2, &Inst, EdgeType::Assign);
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
2015-06-12 16:13:54 +00:00
|
|
|
|
|
|
|
void visitConstantExpr(ConstantExpr *CE) {
|
|
|
|
switch (CE->getOpcode()) {
|
|
|
|
default:
|
|
|
|
llvm_unreachable("Unknown instruction type encountered!");
|
|
|
|
// Build the switch statement using the Instruction.def file.
|
|
|
|
#define HANDLE_INST(NUM, OPCODE, CLASS) \
|
|
|
|
case Instruction::OPCODE: \
|
|
|
|
visit##OPCODE(*(CLASS *)CE); \
|
|
|
|
break;
|
|
|
|
#include "llvm/IR/Instruction.def"
|
|
|
|
}
|
|
|
|
}
|
2014-09-02 21:43:13 +00:00
|
|
|
};
|
|
|
|
|
2016-06-14 18:02:27 +00:00
|
|
|
class CFLGraphBuilder {
|
|
|
|
// Input of the builder
|
|
|
|
CFLAAResult &Analysis;
|
|
|
|
const TargetLibraryInfo &TLI;
|
|
|
|
|
|
|
|
// Output of the builder
|
|
|
|
CFLGraph Graph;
|
|
|
|
SmallVector<Value *, 4> ReturnedValues;
|
|
|
|
|
|
|
|
// Auxiliary structures used by the builder
|
2016-06-14 18:12:28 +00:00
|
|
|
SmallPtrSet<Value *, 8> ExternalValues;
|
|
|
|
SmallPtrSet<Value *, 8> EscapedValues;
|
2016-06-23 18:55:23 +00:00
|
|
|
SmallVector<InterprocEdge, 8> InterprocEdges;
|
2016-06-14 18:02:27 +00:00
|
|
|
|
|
|
|
// Helper functions
|
|
|
|
|
|
|
|
// Determines whether or not we an instruction is useless to us (e.g.
|
|
|
|
// FenceInst)
|
|
|
|
static bool hasUsefulEdges(Instruction *Inst) {
|
|
|
|
bool IsNonInvokeTerminator =
|
|
|
|
isa<TerminatorInst>(Inst) && !isa<InvokeInst>(Inst);
|
|
|
|
return !isa<CmpInst>(Inst) && !isa<FenceInst>(Inst) &&
|
|
|
|
!IsNonInvokeTerminator;
|
|
|
|
}
|
|
|
|
|
2016-06-14 18:12:28 +00:00
|
|
|
void addArgumentToGraph(Argument &Arg) {
|
2016-06-15 20:43:41 +00:00
|
|
|
if (Arg.getType()->isPointerTy()) {
|
|
|
|
Graph.addNode(&Arg);
|
|
|
|
ExternalValues.insert(&Arg);
|
|
|
|
}
|
2016-06-14 18:02:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Given an Instruction, this will add it to the graph, along with any
|
|
|
|
// Instructions that are potentially only available from said Instruction
|
|
|
|
// For example, given the following line:
|
|
|
|
// %0 = load i16* getelementptr ([1 x i16]* @a, 0, 0), align 2
|
|
|
|
// addInstructionToGraph would add both the `load` and `getelementptr`
|
|
|
|
// instructions to the graph appropriately.
|
|
|
|
void addInstructionToGraph(Instruction &Inst) {
|
|
|
|
// We don't want the edges of most "return" instructions, but we *do* want
|
|
|
|
// to know what can be returned.
|
2016-06-20 23:10:56 +00:00
|
|
|
if (auto RetInst = dyn_cast<ReturnInst>(&Inst))
|
|
|
|
if (auto RetVal = RetInst->getReturnValue())
|
|
|
|
if (RetVal->getType()->isPointerTy())
|
|
|
|
ReturnedValues.push_back(RetVal);
|
2016-06-14 18:02:27 +00:00
|
|
|
|
|
|
|
if (!hasUsefulEdges(&Inst))
|
|
|
|
return;
|
|
|
|
|
2016-06-23 18:55:23 +00:00
|
|
|
GetEdgesVisitor(Analysis, TLI, Graph, ExternalValues, EscapedValues,
|
|
|
|
InterprocEdges)
|
2016-06-14 18:12:28 +00:00
|
|
|
.visit(Inst);
|
|
|
|
}
|
2016-06-14 18:02:27 +00:00
|
|
|
|
2016-06-14 18:12:28 +00:00
|
|
|
// Builds the graph needed for constructing the StratifiedSets for the given
|
|
|
|
// function
|
|
|
|
void buildGraphFrom(Function &Fn) {
|
|
|
|
for (auto &Bb : Fn.getBasicBlockList())
|
|
|
|
for (auto &Inst : Bb.getInstList())
|
|
|
|
addInstructionToGraph(Inst);
|
2016-06-14 18:02:27 +00:00
|
|
|
|
2016-06-14 18:12:28 +00:00
|
|
|
for (auto &Arg : Fn.args())
|
|
|
|
addArgumentToGraph(Arg);
|
2016-06-14 18:02:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
public:
|
|
|
|
CFLGraphBuilder(CFLAAResult &Analysis, const TargetLibraryInfo &TLI,
|
|
|
|
Function &Fn)
|
|
|
|
: Analysis(Analysis), TLI(TLI) {
|
|
|
|
buildGraphFrom(Fn);
|
|
|
|
}
|
|
|
|
|
2016-06-20 23:10:56 +00:00
|
|
|
const CFLGraph &getCFLGraph() const { return Graph; }
|
|
|
|
const SmallVector<Value *, 4> &getReturnValues() const {
|
|
|
|
return ReturnedValues;
|
|
|
|
}
|
|
|
|
const SmallPtrSet<Value *, 8> &getExternalValues() const {
|
|
|
|
return ExternalValues;
|
|
|
|
}
|
|
|
|
const SmallPtrSet<Value *, 8> &getEscapedValues() const {
|
|
|
|
return EscapedValues;
|
2016-06-14 18:02:27 +00:00
|
|
|
}
|
2016-06-23 18:55:23 +00:00
|
|
|
const SmallVector<InterprocEdge, 8> &getInterprocEdges() const {
|
|
|
|
return InterprocEdges;
|
|
|
|
}
|
2016-06-14 18:02:27 +00:00
|
|
|
};
|
2015-06-23 09:49:53 +00:00
|
|
|
}
|
2014-09-02 21:43:13 +00:00
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Function declarations that require types defined in the namespace above
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2016-06-07 18:35:37 +00:00
|
|
|
/// Given a StratifiedAttrs, returns true if it marks the corresponding values
|
|
|
|
/// as globals or arguments
|
|
|
|
static bool isGlobalOrArgAttr(StratifiedAttrs Attr);
|
|
|
|
|
2016-06-09 23:15:04 +00:00
|
|
|
/// Given a StratifiedAttrs, returns true if the corresponding values come from
|
|
|
|
/// an unknown source (such as opaque memory or an integer cast)
|
|
|
|
static bool isUnknownAttr(StratifiedAttrs Attr);
|
|
|
|
|
2016-06-07 18:35:37 +00:00
|
|
|
/// Given an argument number, returns the appropriate StratifiedAttr to set.
|
|
|
|
static StratifiedAttr argNumberToAttr(unsigned ArgNum);
|
2014-09-02 21:43:13 +00:00
|
|
|
|
2016-06-07 18:35:37 +00:00
|
|
|
/// Given a Value, potentially return which StratifiedAttr it maps to.
|
|
|
|
static Optional<StratifiedAttr> valueToAttr(Value *Val);
|
2014-09-02 21:43:13 +00:00
|
|
|
|
2016-04-13 23:27:37 +00:00
|
|
|
/// Gets the "Level" that one should travel in StratifiedSets
|
|
|
|
/// given an EdgeType.
|
2014-09-02 21:43:13 +00:00
|
|
|
static Level directionOfEdgeType(EdgeType);
|
|
|
|
|
2016-04-13 23:27:37 +00:00
|
|
|
/// Determines whether it would be pointless to add the given Value to our sets.
|
2015-03-10 02:58:15 +00:00
|
|
|
static bool canSkipAddingToSets(Value *Val);
|
|
|
|
|
2014-09-02 21:43:13 +00:00
|
|
|
static Optional<Function *> parentFunctionOfValue(Value *Val) {
|
|
|
|
if (auto *Inst = dyn_cast<Instruction>(Val)) {
|
|
|
|
auto *Bb = Inst->getParent();
|
|
|
|
return Bb->getParent();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (auto *Arg = dyn_cast<Argument>(Val))
|
|
|
|
return Arg->getParent();
|
2016-01-28 00:54:01 +00:00
|
|
|
return None;
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
|
|
|
|
2016-06-14 18:12:28 +00:00
|
|
|
static bool getPossibleTargets(CallSite CS,
|
2014-09-02 21:43:13 +00:00
|
|
|
SmallVectorImpl<Function *> &Output) {
|
2016-06-14 18:12:28 +00:00
|
|
|
if (auto *Fn = CS.getCalledFunction()) {
|
2014-09-02 21:43:13 +00:00
|
|
|
Output.push_back(Fn);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// TODO: If the call is indirect, we might be able to enumerate all potential
|
|
|
|
// targets of the call and return them, rather than just failing.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-06-07 18:35:37 +00:00
|
|
|
static bool isGlobalOrArgAttr(StratifiedAttrs Attr) {
|
|
|
|
return Attr.reset(AttrEscapedIndex).reset(AttrUnknownIndex).any();
|
|
|
|
}
|
|
|
|
|
2016-06-09 23:15:04 +00:00
|
|
|
static bool isUnknownAttr(StratifiedAttrs Attr) {
|
|
|
|
return Attr.test(AttrUnknownIndex);
|
|
|
|
}
|
|
|
|
|
2016-06-07 18:35:37 +00:00
|
|
|
static Optional<StratifiedAttr> valueToAttr(Value *Val) {
|
2014-09-02 21:43:13 +00:00
|
|
|
if (isa<GlobalValue>(Val))
|
2016-06-07 18:35:37 +00:00
|
|
|
return AttrGlobal;
|
2014-09-02 21:43:13 +00:00
|
|
|
|
|
|
|
if (auto *Arg = dyn_cast<Argument>(Val))
|
2015-01-26 17:31:17 +00:00
|
|
|
// Only pointer arguments should have the argument attribute,
|
|
|
|
// because things can't escape through scalars without us seeing a
|
|
|
|
// cast, and thus, interaction with them doesn't matter.
|
|
|
|
if (!Arg->hasNoAliasAttr() && Arg->getType()->isPointerTy())
|
2016-06-07 18:35:37 +00:00
|
|
|
return argNumberToAttr(Arg->getArgNo());
|
2016-01-28 00:54:01 +00:00
|
|
|
return None;
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
|
|
|
|
2016-06-07 18:35:37 +00:00
|
|
|
static StratifiedAttr argNumberToAttr(unsigned ArgNum) {
|
2015-01-21 16:37:21 +00:00
|
|
|
if (ArgNum >= AttrMaxNumArgs)
|
2016-06-07 18:35:37 +00:00
|
|
|
return AttrUnknown;
|
|
|
|
return 1 << (ArgNum + AttrFirstArgIndex);
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static Level directionOfEdgeType(EdgeType Weight) {
|
|
|
|
switch (Weight) {
|
|
|
|
case EdgeType::Reference:
|
|
|
|
return Level::Above;
|
|
|
|
case EdgeType::Dereference:
|
|
|
|
return Level::Below;
|
|
|
|
case EdgeType::Assign:
|
|
|
|
return Level::Same;
|
|
|
|
}
|
|
|
|
llvm_unreachable("Incomplete switch coverage");
|
|
|
|
}
|
|
|
|
|
2015-03-10 02:58:15 +00:00
|
|
|
static bool canSkipAddingToSets(Value *Val) {
|
|
|
|
// Constants can share instances, which may falsely unify multiple
|
|
|
|
// sets, e.g. in
|
|
|
|
// store i32* null, i32** %ptr1
|
|
|
|
// store i32* null, i32** %ptr2
|
|
|
|
// clearly ptr1 and ptr2 should not be unified into the same set, so
|
|
|
|
// we should filter out the (potentially shared) instance to
|
|
|
|
// i32* null.
|
|
|
|
if (isa<Constant>(Val)) {
|
|
|
|
// TODO: Because all of these things are constant, we can determine whether
|
|
|
|
// the data is *actually* mutable at graph building time. This will probably
|
|
|
|
// come for free/cheap with offset awareness.
|
2016-04-05 21:10:45 +00:00
|
|
|
bool CanStoreMutableData = isa<GlobalValue>(Val) ||
|
|
|
|
isa<ConstantExpr>(Val) ||
|
|
|
|
isa<ConstantAggregate>(Val);
|
2015-03-10 02:58:15 +00:00
|
|
|
return !CanStoreMutableData;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-06-20 23:10:56 +00:00
|
|
|
CFLAAResult::FunctionInfo::FunctionInfo(Function &Fn,
|
|
|
|
const SmallVectorImpl<Value *> &RetVals,
|
|
|
|
StratifiedSets<Value *> S)
|
|
|
|
: Sets(std::move(S)) {
|
2016-06-23 18:55:23 +00:00
|
|
|
// Historically, an arbitrary upper-bound of 50 args was selected. We may want
|
|
|
|
// to remove this if it doesn't really matter in practice.
|
|
|
|
if (Fn.arg_size() > MaxSupportedArgsInSummary)
|
|
|
|
return;
|
|
|
|
|
|
|
|
DenseMap<StratifiedIndex, InterfaceValue> InterfaceMap;
|
|
|
|
|
|
|
|
// Our intention here is to record all InterfaceValues that share the same
|
|
|
|
// StratifiedIndex in RetParamRelations. For each valid InterfaceValue, we
|
|
|
|
// have its StratifiedIndex scanned here and check if the index is presented
|
|
|
|
// in InterfaceMap: if it is not, we add the correspondence to the map;
|
|
|
|
// otherwise, an aliasing relation is found and we add it to
|
|
|
|
// RetParamRelations.
|
|
|
|
auto AddToRetParamRelations = [this, &InterfaceMap](
|
|
|
|
unsigned InterfaceIndex, StratifiedIndex SetIndex) {
|
|
|
|
unsigned Level = 0;
|
|
|
|
while (true) {
|
|
|
|
InterfaceValue CurrValue{InterfaceIndex, Level};
|
|
|
|
|
|
|
|
auto Itr = InterfaceMap.find(SetIndex);
|
|
|
|
if (Itr != InterfaceMap.end()) {
|
|
|
|
if (CurrValue != Itr->second)
|
|
|
|
RetParamRelations.push_back(ExternalRelation{CurrValue, Itr->second});
|
|
|
|
break;
|
|
|
|
} else
|
|
|
|
InterfaceMap.insert(std::make_pair(SetIndex, CurrValue));
|
2016-06-20 23:10:56 +00:00
|
|
|
|
2016-06-23 18:55:23 +00:00
|
|
|
auto &Link = Sets.getLink(SetIndex);
|
|
|
|
if (!Link.hasBelow())
|
|
|
|
break;
|
2016-06-20 23:10:56 +00:00
|
|
|
|
2016-06-23 18:55:23 +00:00
|
|
|
++Level;
|
|
|
|
SetIndex = Link.Below;
|
|
|
|
}
|
|
|
|
};
|
2016-06-20 23:10:56 +00:00
|
|
|
|
2016-06-23 18:55:23 +00:00
|
|
|
// Populate RetParamRelations for return values
|
|
|
|
for (auto *RetVal : RetVals) {
|
|
|
|
auto RetInfo = Sets.find(RetVal);
|
|
|
|
if (RetInfo.hasValue())
|
|
|
|
AddToRetParamRelations(0, RetInfo->Index);
|
|
|
|
}
|
2016-06-20 23:10:56 +00:00
|
|
|
|
2016-06-23 18:55:23 +00:00
|
|
|
// Populate RetParamRelations for parameters
|
|
|
|
unsigned I = 0;
|
|
|
|
for (auto &Param : Fn.args()) {
|
|
|
|
if (Param.getType()->isPointerTy()) {
|
|
|
|
auto ParamInfo = Sets.find(&Param);
|
|
|
|
if (ParamInfo.hasValue())
|
|
|
|
AddToRetParamRelations(I + 1, ParamInfo->Index);
|
2016-06-20 23:10:56 +00:00
|
|
|
}
|
2016-06-23 18:55:23 +00:00
|
|
|
++I;
|
2016-06-20 23:10:56 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-08-14 02:42:20 +00:00
|
|
|
// Builds the graph + StratifiedSets for a function.
|
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
with the new pass manager, and no longer relying on analysis groups.
This builds essentially a ground-up new AA infrastructure stack for
LLVM. The core ideas are the same that are used throughout the new pass
manager: type erased polymorphism and direct composition. The design is
as follows:
- FunctionAAResults is a type-erasing alias analysis results aggregation
interface to walk a single query across a range of results from
different alias analyses. Currently this is function-specific as we
always assume that aliasing queries are *within* a function.
- AAResultBase is a CRTP utility providing stub implementations of
various parts of the alias analysis result concept, notably in several
cases in terms of other more general parts of the interface. This can
be used to implement only a narrow part of the interface rather than
the entire interface. This isn't really ideal, this logic should be
hoisted into FunctionAAResults as currently it will cause
a significant amount of redundant work, but it faithfully models the
behavior of the prior infrastructure.
- All the alias analysis passes are ported to be wrapper passes for the
legacy PM and new-style analysis passes for the new PM with a shared
result object. In some cases (most notably CFL), this is an extremely
naive approach that we should revisit when we can specialize for the
new pass manager.
- BasicAA has been restructured to reflect that it is much more
fundamentally a function analysis because it uses dominator trees and
loop info that need to be constructed for each function.
All of the references to getting alias analysis results have been
updated to use the new aggregation interface. All the preservation and
other pass management code has been updated accordingly.
The way the FunctionAAResultsWrapperPass works is to detect the
available alias analyses when run, and add them to the results object.
This means that we should be able to continue to respect when various
passes are added to the pipeline, for example adding CFL or adding TBAA
passes should just cause their results to be available and to get folded
into this. The exception to this rule is BasicAA which really needs to
be a function pass due to using dominator trees and loop info. As
a consequence, the FunctionAAResultsWrapperPass directly depends on
BasicAA and always includes it in the aggregation.
This has significant implications for preserving analyses. Generally,
most passes shouldn't bother preserving FunctionAAResultsWrapperPass
because rebuilding the results just updates the set of known AA passes.
The exception to this rule are LoopPass instances which need to preserve
all the function analyses that the loop pass manager will end up
needing. This means preserving both BasicAAWrapperPass and the
aggregating FunctionAAResultsWrapperPass.
Now, when preserving an alias analysis, you do so by directly preserving
that analysis. This is only necessary for non-immutable-pass-provided
alias analyses though, and there are only three of interest: BasicAA,
GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
preserved when needed because it (like DominatorTree and LoopInfo) is
marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
set everywhere we previously were preserving all of AliasAnalysis, and
I've added SCEVAA in the intersection of that with where we preserve
SCEV itself.
One significant challenge to all of this is that the CGSCC passes were
actually using the alias analysis implementations by taking advantage of
a pretty amazing set of loop holes in the old pass manager's analysis
management code which allowed analysis groups to slide through in many
cases. Moving away from analysis groups makes this problem much more
obvious. To fix it, I've leveraged the flexibility the design of the new
PM components provides to just directly construct the relevant alias
analyses for the relevant functions in the IPO passes that need them.
This is a bit hacky, but should go away with the new pass manager, and
is already in many ways cleaner than the prior state.
Another significant challenge is that various facilities of the old
alias analysis infrastructure just don't fit any more. The most
significant of these is the alias analysis 'counter' pass. That pass
relied on the ability to snoop on AA queries at different points in the
analysis group chain. Instead, I'm planning to build printing
functionality directly into the aggregation layer. I've not included
that in this patch merely to keep it smaller.
Note that all of this needs a nearly complete rewrite of the AA
documentation. I'm planning to do that, but I'd like to make sure the
new design settles, and to flesh out a bit more of what it looks like in
the new pass manager first.
Differential Revision: http://reviews.llvm.org/D12080
llvm-svn: 247167
2015-09-09 17:55:00 +00:00
|
|
|
CFLAAResult::FunctionInfo CFLAAResult::buildSetsFrom(Function *Fn) {
|
2016-06-14 18:02:27 +00:00
|
|
|
CFLGraphBuilder GraphBuilder(*this, TLI, *Fn);
|
|
|
|
StratifiedSetsBuilder<Value *> SetBuilder;
|
2014-09-02 21:43:13 +00:00
|
|
|
|
2016-06-14 18:02:27 +00:00
|
|
|
auto &Graph = GraphBuilder.getCFLGraph();
|
2016-06-13 19:21:18 +00:00
|
|
|
SmallVector<Value *, 16> Worklist;
|
|
|
|
for (auto Node : Graph.nodes())
|
|
|
|
Worklist.push_back(Node);
|
2014-09-02 21:43:13 +00:00
|
|
|
|
2016-06-13 19:21:18 +00:00
|
|
|
while (!Worklist.empty()) {
|
|
|
|
auto *CurValue = Worklist.pop_back_val();
|
2016-06-14 18:02:27 +00:00
|
|
|
SetBuilder.add(CurValue);
|
2016-06-13 19:21:18 +00:00
|
|
|
if (canSkipAddingToSets(CurValue))
|
|
|
|
continue;
|
|
|
|
|
2016-06-15 20:43:41 +00:00
|
|
|
auto Attr = Graph.attrFor(CurValue);
|
|
|
|
SetBuilder.noteAttributes(CurValue, Attr);
|
|
|
|
|
2016-06-13 19:21:18 +00:00
|
|
|
for (const auto &Edge : Graph.edgesFor(CurValue)) {
|
|
|
|
auto Label = Edge.Type;
|
|
|
|
auto *OtherValue = Edge.Other;
|
2015-03-10 02:40:06 +00:00
|
|
|
|
2016-06-13 19:21:18 +00:00
|
|
|
if (canSkipAddingToSets(OtherValue))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
bool Added;
|
|
|
|
switch (directionOfEdgeType(Label)) {
|
|
|
|
case Level::Above:
|
2016-06-14 18:02:27 +00:00
|
|
|
Added = SetBuilder.addAbove(CurValue, OtherValue);
|
2016-06-13 19:21:18 +00:00
|
|
|
break;
|
|
|
|
case Level::Below:
|
2016-06-14 18:02:27 +00:00
|
|
|
Added = SetBuilder.addBelow(CurValue, OtherValue);
|
2016-06-13 19:21:18 +00:00
|
|
|
break;
|
|
|
|
case Level::Same:
|
2016-06-14 18:02:27 +00:00
|
|
|
Added = SetBuilder.addWith(CurValue, OtherValue);
|
2016-06-13 19:21:18 +00:00
|
|
|
break;
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
2016-06-13 19:21:18 +00:00
|
|
|
|
|
|
|
if (Added)
|
|
|
|
Worklist.push_back(OtherValue);
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-06-09 23:15:04 +00:00
|
|
|
// Special handling for globals and arguments
|
2016-06-14 18:12:28 +00:00
|
|
|
for (auto *External : GraphBuilder.getExternalValues()) {
|
|
|
|
SetBuilder.add(External);
|
|
|
|
auto Attr = valueToAttr(External);
|
2016-06-09 23:15:04 +00:00
|
|
|
if (Attr.hasValue()) {
|
2016-06-14 18:12:28 +00:00
|
|
|
SetBuilder.noteAttributes(External, *Attr);
|
|
|
|
SetBuilder.addAttributesBelow(External, AttrUnknown);
|
2016-06-09 23:15:04 +00:00
|
|
|
}
|
2016-06-14 18:12:28 +00:00
|
|
|
}
|
2015-03-10 02:58:15 +00:00
|
|
|
|
2016-06-23 18:55:23 +00:00
|
|
|
// Special handling for interprocedural aliases
|
|
|
|
for (auto &Edge : GraphBuilder.getInterprocEdges()) {
|
|
|
|
auto FromVal = Edge.From.Value;
|
|
|
|
auto ToVal = Edge.To.Value;
|
|
|
|
SetBuilder.add(FromVal);
|
|
|
|
SetBuilder.add(ToVal);
|
|
|
|
SetBuilder.addBelowWith(FromVal, Edge.From.DerefLevel, ToVal,
|
|
|
|
Edge.To.DerefLevel);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Special handling for opaque external functions
|
2016-06-14 18:12:28 +00:00
|
|
|
for (auto *Escape : GraphBuilder.getEscapedValues()) {
|
|
|
|
SetBuilder.add(Escape);
|
|
|
|
SetBuilder.noteAttributes(Escape, AttrEscaped);
|
|
|
|
SetBuilder.addAttributesBelow(Escape, AttrUnknown);
|
|
|
|
}
|
2014-09-02 21:43:13 +00:00
|
|
|
|
2016-06-20 23:10:56 +00:00
|
|
|
return FunctionInfo(*Fn, GraphBuilder.getReturnValues(), SetBuilder.build());
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
|
|
|
|
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
with the new pass manager, and no longer relying on analysis groups.
This builds essentially a ground-up new AA infrastructure stack for
LLVM. The core ideas are the same that are used throughout the new pass
manager: type erased polymorphism and direct composition. The design is
as follows:
- FunctionAAResults is a type-erasing alias analysis results aggregation
interface to walk a single query across a range of results from
different alias analyses. Currently this is function-specific as we
always assume that aliasing queries are *within* a function.
- AAResultBase is a CRTP utility providing stub implementations of
various parts of the alias analysis result concept, notably in several
cases in terms of other more general parts of the interface. This can
be used to implement only a narrow part of the interface rather than
the entire interface. This isn't really ideal, this logic should be
hoisted into FunctionAAResults as currently it will cause
a significant amount of redundant work, but it faithfully models the
behavior of the prior infrastructure.
- All the alias analysis passes are ported to be wrapper passes for the
legacy PM and new-style analysis passes for the new PM with a shared
result object. In some cases (most notably CFL), this is an extremely
naive approach that we should revisit when we can specialize for the
new pass manager.
- BasicAA has been restructured to reflect that it is much more
fundamentally a function analysis because it uses dominator trees and
loop info that need to be constructed for each function.
All of the references to getting alias analysis results have been
updated to use the new aggregation interface. All the preservation and
other pass management code has been updated accordingly.
The way the FunctionAAResultsWrapperPass works is to detect the
available alias analyses when run, and add them to the results object.
This means that we should be able to continue to respect when various
passes are added to the pipeline, for example adding CFL or adding TBAA
passes should just cause their results to be available and to get folded
into this. The exception to this rule is BasicAA which really needs to
be a function pass due to using dominator trees and loop info. As
a consequence, the FunctionAAResultsWrapperPass directly depends on
BasicAA and always includes it in the aggregation.
This has significant implications for preserving analyses. Generally,
most passes shouldn't bother preserving FunctionAAResultsWrapperPass
because rebuilding the results just updates the set of known AA passes.
The exception to this rule are LoopPass instances which need to preserve
all the function analyses that the loop pass manager will end up
needing. This means preserving both BasicAAWrapperPass and the
aggregating FunctionAAResultsWrapperPass.
Now, when preserving an alias analysis, you do so by directly preserving
that analysis. This is only necessary for non-immutable-pass-provided
alias analyses though, and there are only three of interest: BasicAA,
GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
preserved when needed because it (like DominatorTree and LoopInfo) is
marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
set everywhere we previously were preserving all of AliasAnalysis, and
I've added SCEVAA in the intersection of that with where we preserve
SCEV itself.
One significant challenge to all of this is that the CGSCC passes were
actually using the alias analysis implementations by taking advantage of
a pretty amazing set of loop holes in the old pass manager's analysis
management code which allowed analysis groups to slide through in many
cases. Moving away from analysis groups makes this problem much more
obvious. To fix it, I've leveraged the flexibility the design of the new
PM components provides to just directly construct the relevant alias
analyses for the relevant functions in the IPO passes that need them.
This is a bit hacky, but should go away with the new pass manager, and
is already in many ways cleaner than the prior state.
Another significant challenge is that various facilities of the old
alias analysis infrastructure just don't fit any more. The most
significant of these is the alias analysis 'counter' pass. That pass
relied on the ability to snoop on AA queries at different points in the
analysis group chain. Instead, I'm planning to build printing
functionality directly into the aggregation layer. I've not included
that in this patch merely to keep it smaller.
Note that all of this needs a nearly complete rewrite of the AA
documentation. I'm planning to do that, but I'd like to make sure the
new design settles, and to flesh out a bit more of what it looks like in
the new pass manager first.
Differential Revision: http://reviews.llvm.org/D12080
llvm-svn: 247167
2015-09-09 17:55:00 +00:00
|
|
|
void CFLAAResult::scan(Function *Fn) {
|
2014-09-02 22:52:30 +00:00
|
|
|
auto InsertPair = Cache.insert(std::make_pair(Fn, Optional<FunctionInfo>()));
|
2014-09-02 21:43:13 +00:00
|
|
|
(void)InsertPair;
|
|
|
|
assert(InsertPair.second &&
|
|
|
|
"Trying to scan a function that has already been cached");
|
|
|
|
|
2016-05-02 18:09:19 +00:00
|
|
|
// Note that we can't do Cache[Fn] = buildSetsFrom(Fn) here: the function call
|
|
|
|
// may get evaluated after operator[], potentially triggering a DenseMap
|
|
|
|
// resize and invalidating the reference returned by operator[]
|
|
|
|
auto FunInfo = buildSetsFrom(Fn);
|
|
|
|
Cache[Fn] = std::move(FunInfo);
|
|
|
|
|
2014-09-02 21:43:13 +00:00
|
|
|
Handles.push_front(FunctionHandle(Fn, this));
|
|
|
|
}
|
|
|
|
|
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
with the new pass manager, and no longer relying on analysis groups.
This builds essentially a ground-up new AA infrastructure stack for
LLVM. The core ideas are the same that are used throughout the new pass
manager: type erased polymorphism and direct composition. The design is
as follows:
- FunctionAAResults is a type-erasing alias analysis results aggregation
interface to walk a single query across a range of results from
different alias analyses. Currently this is function-specific as we
always assume that aliasing queries are *within* a function.
- AAResultBase is a CRTP utility providing stub implementations of
various parts of the alias analysis result concept, notably in several
cases in terms of other more general parts of the interface. This can
be used to implement only a narrow part of the interface rather than
the entire interface. This isn't really ideal, this logic should be
hoisted into FunctionAAResults as currently it will cause
a significant amount of redundant work, but it faithfully models the
behavior of the prior infrastructure.
- All the alias analysis passes are ported to be wrapper passes for the
legacy PM and new-style analysis passes for the new PM with a shared
result object. In some cases (most notably CFL), this is an extremely
naive approach that we should revisit when we can specialize for the
new pass manager.
- BasicAA has been restructured to reflect that it is much more
fundamentally a function analysis because it uses dominator trees and
loop info that need to be constructed for each function.
All of the references to getting alias analysis results have been
updated to use the new aggregation interface. All the preservation and
other pass management code has been updated accordingly.
The way the FunctionAAResultsWrapperPass works is to detect the
available alias analyses when run, and add them to the results object.
This means that we should be able to continue to respect when various
passes are added to the pipeline, for example adding CFL or adding TBAA
passes should just cause their results to be available and to get folded
into this. The exception to this rule is BasicAA which really needs to
be a function pass due to using dominator trees and loop info. As
a consequence, the FunctionAAResultsWrapperPass directly depends on
BasicAA and always includes it in the aggregation.
This has significant implications for preserving analyses. Generally,
most passes shouldn't bother preserving FunctionAAResultsWrapperPass
because rebuilding the results just updates the set of known AA passes.
The exception to this rule are LoopPass instances which need to preserve
all the function analyses that the loop pass manager will end up
needing. This means preserving both BasicAAWrapperPass and the
aggregating FunctionAAResultsWrapperPass.
Now, when preserving an alias analysis, you do so by directly preserving
that analysis. This is only necessary for non-immutable-pass-provided
alias analyses though, and there are only three of interest: BasicAA,
GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
preserved when needed because it (like DominatorTree and LoopInfo) is
marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
set everywhere we previously were preserving all of AliasAnalysis, and
I've added SCEVAA in the intersection of that with where we preserve
SCEV itself.
One significant challenge to all of this is that the CGSCC passes were
actually using the alias analysis implementations by taking advantage of
a pretty amazing set of loop holes in the old pass manager's analysis
management code which allowed analysis groups to slide through in many
cases. Moving away from analysis groups makes this problem much more
obvious. To fix it, I've leveraged the flexibility the design of the new
PM components provides to just directly construct the relevant alias
analyses for the relevant functions in the IPO passes that need them.
This is a bit hacky, but should go away with the new pass manager, and
is already in many ways cleaner than the prior state.
Another significant challenge is that various facilities of the old
alias analysis infrastructure just don't fit any more. The most
significant of these is the alias analysis 'counter' pass. That pass
relied on the ability to snoop on AA queries at different points in the
analysis group chain. Instead, I'm planning to build printing
functionality directly into the aggregation layer. I've not included
that in this patch merely to keep it smaller.
Note that all of this needs a nearly complete rewrite of the AA
documentation. I'm planning to do that, but I'd like to make sure the
new design settles, and to flesh out a bit more of what it looks like in
the new pass manager first.
Differential Revision: http://reviews.llvm.org/D12080
llvm-svn: 247167
2015-09-09 17:55:00 +00:00
|
|
|
void CFLAAResult::evict(Function *Fn) { Cache.erase(Fn); }
|
2015-08-14 02:42:20 +00:00
|
|
|
|
2016-04-13 23:27:37 +00:00
|
|
|
/// Ensures that the given function is available in the cache, and returns the
|
|
|
|
/// entry.
|
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
with the new pass manager, and no longer relying on analysis groups.
This builds essentially a ground-up new AA infrastructure stack for
LLVM. The core ideas are the same that are used throughout the new pass
manager: type erased polymorphism and direct composition. The design is
as follows:
- FunctionAAResults is a type-erasing alias analysis results aggregation
interface to walk a single query across a range of results from
different alias analyses. Currently this is function-specific as we
always assume that aliasing queries are *within* a function.
- AAResultBase is a CRTP utility providing stub implementations of
various parts of the alias analysis result concept, notably in several
cases in terms of other more general parts of the interface. This can
be used to implement only a narrow part of the interface rather than
the entire interface. This isn't really ideal, this logic should be
hoisted into FunctionAAResults as currently it will cause
a significant amount of redundant work, but it faithfully models the
behavior of the prior infrastructure.
- All the alias analysis passes are ported to be wrapper passes for the
legacy PM and new-style analysis passes for the new PM with a shared
result object. In some cases (most notably CFL), this is an extremely
naive approach that we should revisit when we can specialize for the
new pass manager.
- BasicAA has been restructured to reflect that it is much more
fundamentally a function analysis because it uses dominator trees and
loop info that need to be constructed for each function.
All of the references to getting alias analysis results have been
updated to use the new aggregation interface. All the preservation and
other pass management code has been updated accordingly.
The way the FunctionAAResultsWrapperPass works is to detect the
available alias analyses when run, and add them to the results object.
This means that we should be able to continue to respect when various
passes are added to the pipeline, for example adding CFL or adding TBAA
passes should just cause their results to be available and to get folded
into this. The exception to this rule is BasicAA which really needs to
be a function pass due to using dominator trees and loop info. As
a consequence, the FunctionAAResultsWrapperPass directly depends on
BasicAA and always includes it in the aggregation.
This has significant implications for preserving analyses. Generally,
most passes shouldn't bother preserving FunctionAAResultsWrapperPass
because rebuilding the results just updates the set of known AA passes.
The exception to this rule are LoopPass instances which need to preserve
all the function analyses that the loop pass manager will end up
needing. This means preserving both BasicAAWrapperPass and the
aggregating FunctionAAResultsWrapperPass.
Now, when preserving an alias analysis, you do so by directly preserving
that analysis. This is only necessary for non-immutable-pass-provided
alias analyses though, and there are only three of interest: BasicAA,
GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
preserved when needed because it (like DominatorTree and LoopInfo) is
marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
set everywhere we previously were preserving all of AliasAnalysis, and
I've added SCEVAA in the intersection of that with where we preserve
SCEV itself.
One significant challenge to all of this is that the CGSCC passes were
actually using the alias analysis implementations by taking advantage of
a pretty amazing set of loop holes in the old pass manager's analysis
management code which allowed analysis groups to slide through in many
cases. Moving away from analysis groups makes this problem much more
obvious. To fix it, I've leveraged the flexibility the design of the new
PM components provides to just directly construct the relevant alias
analyses for the relevant functions in the IPO passes that need them.
This is a bit hacky, but should go away with the new pass manager, and
is already in many ways cleaner than the prior state.
Another significant challenge is that various facilities of the old
alias analysis infrastructure just don't fit any more. The most
significant of these is the alias analysis 'counter' pass. That pass
relied on the ability to snoop on AA queries at different points in the
analysis group chain. Instead, I'm planning to build printing
functionality directly into the aggregation layer. I've not included
that in this patch merely to keep it smaller.
Note that all of this needs a nearly complete rewrite of the AA
documentation. I'm planning to do that, but I'd like to make sure the
new design settles, and to flesh out a bit more of what it looks like in
the new pass manager first.
Differential Revision: http://reviews.llvm.org/D12080
llvm-svn: 247167
2015-09-09 17:55:00 +00:00
|
|
|
const Optional<CFLAAResult::FunctionInfo> &
|
|
|
|
CFLAAResult::ensureCached(Function *Fn) {
|
2015-08-14 02:42:20 +00:00
|
|
|
auto Iter = Cache.find(Fn);
|
|
|
|
if (Iter == Cache.end()) {
|
|
|
|
scan(Fn);
|
|
|
|
Iter = Cache.find(Fn);
|
|
|
|
assert(Iter != Cache.end());
|
|
|
|
assert(Iter->second.hasValue());
|
|
|
|
}
|
|
|
|
return Iter->second;
|
|
|
|
}
|
|
|
|
|
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
with the new pass manager, and no longer relying on analysis groups.
This builds essentially a ground-up new AA infrastructure stack for
LLVM. The core ideas are the same that are used throughout the new pass
manager: type erased polymorphism and direct composition. The design is
as follows:
- FunctionAAResults is a type-erasing alias analysis results aggregation
interface to walk a single query across a range of results from
different alias analyses. Currently this is function-specific as we
always assume that aliasing queries are *within* a function.
- AAResultBase is a CRTP utility providing stub implementations of
various parts of the alias analysis result concept, notably in several
cases in terms of other more general parts of the interface. This can
be used to implement only a narrow part of the interface rather than
the entire interface. This isn't really ideal, this logic should be
hoisted into FunctionAAResults as currently it will cause
a significant amount of redundant work, but it faithfully models the
behavior of the prior infrastructure.
- All the alias analysis passes are ported to be wrapper passes for the
legacy PM and new-style analysis passes for the new PM with a shared
result object. In some cases (most notably CFL), this is an extremely
naive approach that we should revisit when we can specialize for the
new pass manager.
- BasicAA has been restructured to reflect that it is much more
fundamentally a function analysis because it uses dominator trees and
loop info that need to be constructed for each function.
All of the references to getting alias analysis results have been
updated to use the new aggregation interface. All the preservation and
other pass management code has been updated accordingly.
The way the FunctionAAResultsWrapperPass works is to detect the
available alias analyses when run, and add them to the results object.
This means that we should be able to continue to respect when various
passes are added to the pipeline, for example adding CFL or adding TBAA
passes should just cause their results to be available and to get folded
into this. The exception to this rule is BasicAA which really needs to
be a function pass due to using dominator trees and loop info. As
a consequence, the FunctionAAResultsWrapperPass directly depends on
BasicAA and always includes it in the aggregation.
This has significant implications for preserving analyses. Generally,
most passes shouldn't bother preserving FunctionAAResultsWrapperPass
because rebuilding the results just updates the set of known AA passes.
The exception to this rule are LoopPass instances which need to preserve
all the function analyses that the loop pass manager will end up
needing. This means preserving both BasicAAWrapperPass and the
aggregating FunctionAAResultsWrapperPass.
Now, when preserving an alias analysis, you do so by directly preserving
that analysis. This is only necessary for non-immutable-pass-provided
alias analyses though, and there are only three of interest: BasicAA,
GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
preserved when needed because it (like DominatorTree and LoopInfo) is
marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
set everywhere we previously were preserving all of AliasAnalysis, and
I've added SCEVAA in the intersection of that with where we preserve
SCEV itself.
One significant challenge to all of this is that the CGSCC passes were
actually using the alias analysis implementations by taking advantage of
a pretty amazing set of loop holes in the old pass manager's analysis
management code which allowed analysis groups to slide through in many
cases. Moving away from analysis groups makes this problem much more
obvious. To fix it, I've leveraged the flexibility the design of the new
PM components provides to just directly construct the relevant alias
analyses for the relevant functions in the IPO passes that need them.
This is a bit hacky, but should go away with the new pass manager, and
is already in many ways cleaner than the prior state.
Another significant challenge is that various facilities of the old
alias analysis infrastructure just don't fit any more. The most
significant of these is the alias analysis 'counter' pass. That pass
relied on the ability to snoop on AA queries at different points in the
analysis group chain. Instead, I'm planning to build printing
functionality directly into the aggregation layer. I've not included
that in this patch merely to keep it smaller.
Note that all of this needs a nearly complete rewrite of the AA
documentation. I'm planning to do that, but I'd like to make sure the
new design settles, and to flesh out a bit more of what it looks like in
the new pass manager first.
Differential Revision: http://reviews.llvm.org/D12080
llvm-svn: 247167
2015-09-09 17:55:00 +00:00
|
|
|
AliasResult CFLAAResult::query(const MemoryLocation &LocA,
|
|
|
|
const MemoryLocation &LocB) {
|
2014-09-02 21:43:13 +00:00
|
|
|
auto *ValA = const_cast<Value *>(LocA.Ptr);
|
|
|
|
auto *ValB = const_cast<Value *>(LocB.Ptr);
|
|
|
|
|
2016-06-15 20:43:41 +00:00
|
|
|
if (!ValA->getType()->isPointerTy() || !ValB->getType()->isPointerTy())
|
|
|
|
return NoAlias;
|
|
|
|
|
2014-09-02 21:43:13 +00:00
|
|
|
Function *Fn = nullptr;
|
|
|
|
auto MaybeFnA = parentFunctionOfValue(ValA);
|
|
|
|
auto MaybeFnB = parentFunctionOfValue(ValB);
|
|
|
|
if (!MaybeFnA.hasValue() && !MaybeFnB.hasValue()) {
|
2016-04-13 23:27:37 +00:00
|
|
|
// The only times this is known to happen are when globals + InlineAsm are
|
|
|
|
// involved
|
2015-02-12 03:07:07 +00:00
|
|
|
DEBUG(dbgs() << "CFLAA: could not extract parent function information.\n");
|
2015-06-22 02:16:51 +00:00
|
|
|
return MayAlias;
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (MaybeFnA.hasValue()) {
|
|
|
|
Fn = *MaybeFnA;
|
|
|
|
assert((!MaybeFnB.hasValue() || *MaybeFnB == *MaybeFnA) &&
|
|
|
|
"Interprocedural queries not supported");
|
|
|
|
} else {
|
|
|
|
Fn = *MaybeFnB;
|
|
|
|
}
|
|
|
|
|
|
|
|
assert(Fn != nullptr);
|
|
|
|
auto &MaybeInfo = ensureCached(Fn);
|
|
|
|
assert(MaybeInfo.hasValue());
|
|
|
|
|
2016-06-20 23:10:56 +00:00
|
|
|
auto &Sets = MaybeInfo->getStratifiedSets();
|
2014-09-02 21:43:13 +00:00
|
|
|
auto MaybeA = Sets.find(ValA);
|
|
|
|
if (!MaybeA.hasValue())
|
2015-06-22 02:16:51 +00:00
|
|
|
return MayAlias;
|
2014-09-02 21:43:13 +00:00
|
|
|
|
|
|
|
auto MaybeB = Sets.find(ValB);
|
|
|
|
if (!MaybeB.hasValue())
|
2015-06-22 02:16:51 +00:00
|
|
|
return MayAlias;
|
2014-09-02 21:43:13 +00:00
|
|
|
|
|
|
|
auto SetA = *MaybeA;
|
|
|
|
auto SetB = *MaybeB;
|
|
|
|
auto AttrsA = Sets.getLink(SetA.Index).Attrs;
|
|
|
|
auto AttrsB = Sets.getLink(SetB.Index).Attrs;
|
2015-02-12 03:07:07 +00:00
|
|
|
|
2016-06-07 18:35:37 +00:00
|
|
|
// If both values are local (meaning the corresponding set has attribute
|
|
|
|
// AttrNone or AttrEscaped), then we know that CFLAA fully models them: they
|
|
|
|
// may-alias each other if and only if they are in the same set
|
|
|
|
// If at least one value is non-local (meaning it either is global/argument or
|
|
|
|
// it comes from unknown sources like integer cast), the situation becomes a
|
|
|
|
// bit more interesting. We follow three general rules described below:
|
|
|
|
// - Non-local values may alias each other
|
|
|
|
// - AttrNone values do not alias any non-local values
|
2016-06-09 23:15:04 +00:00
|
|
|
// - AttrEscaped do not alias globals/arguments, but they may alias
|
2016-06-07 18:35:37 +00:00
|
|
|
// AttrUnknown values
|
|
|
|
if (SetA.Index == SetB.Index)
|
2015-06-22 02:16:51 +00:00
|
|
|
return MayAlias;
|
2016-06-07 18:35:37 +00:00
|
|
|
if (AttrsA.none() || AttrsB.none())
|
|
|
|
return NoAlias;
|
2016-06-09 23:15:04 +00:00
|
|
|
if (isUnknownAttr(AttrsA) || isUnknownAttr(AttrsB))
|
2016-06-07 18:35:37 +00:00
|
|
|
return MayAlias;
|
|
|
|
if (isGlobalOrArgAttr(AttrsA) && isGlobalOrArgAttr(AttrsB))
|
|
|
|
return MayAlias;
|
|
|
|
return NoAlias;
|
2014-09-02 21:43:13 +00:00
|
|
|
}
|
2015-03-04 18:43:29 +00:00
|
|
|
|
2016-03-11 10:22:49 +00:00
|
|
|
char CFLAA::PassID;
|
|
|
|
|
2016-03-11 11:05:24 +00:00
|
|
|
CFLAAResult CFLAA::run(Function &F, AnalysisManager<Function> &AM) {
|
2016-06-01 18:39:54 +00:00
|
|
|
return CFLAAResult(AM.getResult<TargetLibraryAnalysis>(F));
|
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
with the new pass manager, and no longer relying on analysis groups.
This builds essentially a ground-up new AA infrastructure stack for
LLVM. The core ideas are the same that are used throughout the new pass
manager: type erased polymorphism and direct composition. The design is
as follows:
- FunctionAAResults is a type-erasing alias analysis results aggregation
interface to walk a single query across a range of results from
different alias analyses. Currently this is function-specific as we
always assume that aliasing queries are *within* a function.
- AAResultBase is a CRTP utility providing stub implementations of
various parts of the alias analysis result concept, notably in several
cases in terms of other more general parts of the interface. This can
be used to implement only a narrow part of the interface rather than
the entire interface. This isn't really ideal, this logic should be
hoisted into FunctionAAResults as currently it will cause
a significant amount of redundant work, but it faithfully models the
behavior of the prior infrastructure.
- All the alias analysis passes are ported to be wrapper passes for the
legacy PM and new-style analysis passes for the new PM with a shared
result object. In some cases (most notably CFL), this is an extremely
naive approach that we should revisit when we can specialize for the
new pass manager.
- BasicAA has been restructured to reflect that it is much more
fundamentally a function analysis because it uses dominator trees and
loop info that need to be constructed for each function.
All of the references to getting alias analysis results have been
updated to use the new aggregation interface. All the preservation and
other pass management code has been updated accordingly.
The way the FunctionAAResultsWrapperPass works is to detect the
available alias analyses when run, and add them to the results object.
This means that we should be able to continue to respect when various
passes are added to the pipeline, for example adding CFL or adding TBAA
passes should just cause their results to be available and to get folded
into this. The exception to this rule is BasicAA which really needs to
be a function pass due to using dominator trees and loop info. As
a consequence, the FunctionAAResultsWrapperPass directly depends on
BasicAA and always includes it in the aggregation.
This has significant implications for preserving analyses. Generally,
most passes shouldn't bother preserving FunctionAAResultsWrapperPass
because rebuilding the results just updates the set of known AA passes.
The exception to this rule are LoopPass instances which need to preserve
all the function analyses that the loop pass manager will end up
needing. This means preserving both BasicAAWrapperPass and the
aggregating FunctionAAResultsWrapperPass.
Now, when preserving an alias analysis, you do so by directly preserving
that analysis. This is only necessary for non-immutable-pass-provided
alias analyses though, and there are only three of interest: BasicAA,
GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
preserved when needed because it (like DominatorTree and LoopInfo) is
marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
set everywhere we previously were preserving all of AliasAnalysis, and
I've added SCEVAA in the intersection of that with where we preserve
SCEV itself.
One significant challenge to all of this is that the CGSCC passes were
actually using the alias analysis implementations by taking advantage of
a pretty amazing set of loop holes in the old pass manager's analysis
management code which allowed analysis groups to slide through in many
cases. Moving away from analysis groups makes this problem much more
obvious. To fix it, I've leveraged the flexibility the design of the new
PM components provides to just directly construct the relevant alias
analyses for the relevant functions in the IPO passes that need them.
This is a bit hacky, but should go away with the new pass manager, and
is already in many ways cleaner than the prior state.
Another significant challenge is that various facilities of the old
alias analysis infrastructure just don't fit any more. The most
significant of these is the alias analysis 'counter' pass. That pass
relied on the ability to snoop on AA queries at different points in the
analysis group chain. Instead, I'm planning to build printing
functionality directly into the aggregation layer. I've not included
that in this patch merely to keep it smaller.
Note that all of this needs a nearly complete rewrite of the AA
documentation. I'm planning to do that, but I'd like to make sure the
new design settles, and to flesh out a bit more of what it looks like in
the new pass manager first.
Differential Revision: http://reviews.llvm.org/D12080
llvm-svn: 247167
2015-09-09 17:55:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
char CFLAAWrapperPass::ID = 0;
|
[AA] Hoist the logic to reformulate various AA queries in terms of other
parts of the AA interface out of the base class of every single AA
result object.
Because this logic reformulates the query in terms of some other aspect
of the API, it would easily cause O(n^2) query patterns in alias
analysis. These could in turn be magnified further based on the number
of call arguments, and then further based on the number of AA queries
made for a particular call. This ended up causing problems for Rust that
were actually noticable enough to get a bug (PR26564) and probably other
places as well.
When originally re-working the AA infrastructure, the desire was to
regularize the pattern of refinement without losing any generality.
While I think it was successful, that is clearly proving to be too
costly. And the cost is needless: we gain no actual improvement for this
generality of making a direct query to tbaa actually be able to
re-use some other alias analysis's refinement logic for one of the other
APIs, or some such. In short, this is entirely wasted work.
To the extent possible, delegation to other API surfaces should be done
at the aggregation layer so that we can avoid re-walking the
aggregation. In fact, this significantly simplifies the logic as we no
longer need to smuggle the aggregation layer into each alias analysis
(or the TargetLibraryInfo into each alias analysis just so we can form
argument memory locations!).
However, we also have some delegation logic inside of BasicAA and some
of it even makes sense. When the delegation logic is baking in specific
knowledge of aliasing properties of the LLVM IR, as opposed to simply
reformulating the query to utilize a different alias analysis interface
entry point, it makes a lot of sense to restrict that logic to
a different layer such as BasicAA. So one aspect of the delegation that
was in every AA base class is that when we don't have operand bundles,
we re-use function AA results as a fallback for callsite alias results.
This relies on the IR properties of calls and functions w.r.t. aliasing,
and so seems a better fit to BasicAA. I've lifted the logic up to that
point where it seems to be a natural fit. This still does a bit of
redundant work (we query function attributes twice, once via the
callsite and once via the function AA query) but it is *exactly* twice
here, no more.
The end result is that all of the delegation logic is hoisted out of the
base class and into either the aggregation layer when it is a pure
retargeting to a different API surface, or into BasicAA when it relies
on the IR's aliasing properties. This should fix the quadratic query
pattern reported in PR26564, although I don't have a stand-alone test
case to reproduce it.
It also seems general goodness. Now the numerous AAs that don't need
target library info don't carry it around and depend on it. I think
I can even rip out the general access to the aggregation layer and only
expose that in BasicAA as it is the only place where we re-query in that
manner.
However, this is a non-trivial change to the AA infrastructure so I want
to get some additional eyes on this before it lands. Sadly, it can't
wait long because we should really cherry pick this into 3.8 if we're
going to go this route.
Differential Revision: http://reviews.llvm.org/D17329
llvm-svn: 262490
2016-03-02 15:56:53 +00:00
|
|
|
INITIALIZE_PASS(CFLAAWrapperPass, "cfl-aa", "CFL-Based Alias Analysis", false,
|
|
|
|
true)
|
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
with the new pass manager, and no longer relying on analysis groups.
This builds essentially a ground-up new AA infrastructure stack for
LLVM. The core ideas are the same that are used throughout the new pass
manager: type erased polymorphism and direct composition. The design is
as follows:
- FunctionAAResults is a type-erasing alias analysis results aggregation
interface to walk a single query across a range of results from
different alias analyses. Currently this is function-specific as we
always assume that aliasing queries are *within* a function.
- AAResultBase is a CRTP utility providing stub implementations of
various parts of the alias analysis result concept, notably in several
cases in terms of other more general parts of the interface. This can
be used to implement only a narrow part of the interface rather than
the entire interface. This isn't really ideal, this logic should be
hoisted into FunctionAAResults as currently it will cause
a significant amount of redundant work, but it faithfully models the
behavior of the prior infrastructure.
- All the alias analysis passes are ported to be wrapper passes for the
legacy PM and new-style analysis passes for the new PM with a shared
result object. In some cases (most notably CFL), this is an extremely
naive approach that we should revisit when we can specialize for the
new pass manager.
- BasicAA has been restructured to reflect that it is much more
fundamentally a function analysis because it uses dominator trees and
loop info that need to be constructed for each function.
All of the references to getting alias analysis results have been
updated to use the new aggregation interface. All the preservation and
other pass management code has been updated accordingly.
The way the FunctionAAResultsWrapperPass works is to detect the
available alias analyses when run, and add them to the results object.
This means that we should be able to continue to respect when various
passes are added to the pipeline, for example adding CFL or adding TBAA
passes should just cause their results to be available and to get folded
into this. The exception to this rule is BasicAA which really needs to
be a function pass due to using dominator trees and loop info. As
a consequence, the FunctionAAResultsWrapperPass directly depends on
BasicAA and always includes it in the aggregation.
This has significant implications for preserving analyses. Generally,
most passes shouldn't bother preserving FunctionAAResultsWrapperPass
because rebuilding the results just updates the set of known AA passes.
The exception to this rule are LoopPass instances which need to preserve
all the function analyses that the loop pass manager will end up
needing. This means preserving both BasicAAWrapperPass and the
aggregating FunctionAAResultsWrapperPass.
Now, when preserving an alias analysis, you do so by directly preserving
that analysis. This is only necessary for non-immutable-pass-provided
alias analyses though, and there are only three of interest: BasicAA,
GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
preserved when needed because it (like DominatorTree and LoopInfo) is
marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
set everywhere we previously were preserving all of AliasAnalysis, and
I've added SCEVAA in the intersection of that with where we preserve
SCEV itself.
One significant challenge to all of this is that the CGSCC passes were
actually using the alias analysis implementations by taking advantage of
a pretty amazing set of loop holes in the old pass manager's analysis
management code which allowed analysis groups to slide through in many
cases. Moving away from analysis groups makes this problem much more
obvious. To fix it, I've leveraged the flexibility the design of the new
PM components provides to just directly construct the relevant alias
analyses for the relevant functions in the IPO passes that need them.
This is a bit hacky, but should go away with the new pass manager, and
is already in many ways cleaner than the prior state.
Another significant challenge is that various facilities of the old
alias analysis infrastructure just don't fit any more. The most
significant of these is the alias analysis 'counter' pass. That pass
relied on the ability to snoop on AA queries at different points in the
analysis group chain. Instead, I'm planning to build printing
functionality directly into the aggregation layer. I've not included
that in this patch merely to keep it smaller.
Note that all of this needs a nearly complete rewrite of the AA
documentation. I'm planning to do that, but I'd like to make sure the
new design settles, and to flesh out a bit more of what it looks like in
the new pass manager first.
Differential Revision: http://reviews.llvm.org/D12080
llvm-svn: 247167
2015-09-09 17:55:00 +00:00
|
|
|
|
|
|
|
ImmutablePass *llvm::createCFLAAWrapperPass() { return new CFLAAWrapperPass(); }
|
|
|
|
|
|
|
|
CFLAAWrapperPass::CFLAAWrapperPass() : ImmutablePass(ID) {
|
|
|
|
initializeCFLAAWrapperPassPass(*PassRegistry::getPassRegistry());
|
|
|
|
}
|
|
|
|
|
2016-06-01 18:39:54 +00:00
|
|
|
void CFLAAWrapperPass::initializePass() {
|
|
|
|
auto &TLIWP = getAnalysis<TargetLibraryInfoWrapperPass>();
|
|
|
|
Result.reset(new CFLAAResult(TLIWP.getTLI()));
|
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
with the new pass manager, and no longer relying on analysis groups.
This builds essentially a ground-up new AA infrastructure stack for
LLVM. The core ideas are the same that are used throughout the new pass
manager: type erased polymorphism and direct composition. The design is
as follows:
- FunctionAAResults is a type-erasing alias analysis results aggregation
interface to walk a single query across a range of results from
different alias analyses. Currently this is function-specific as we
always assume that aliasing queries are *within* a function.
- AAResultBase is a CRTP utility providing stub implementations of
various parts of the alias analysis result concept, notably in several
cases in terms of other more general parts of the interface. This can
be used to implement only a narrow part of the interface rather than
the entire interface. This isn't really ideal, this logic should be
hoisted into FunctionAAResults as currently it will cause
a significant amount of redundant work, but it faithfully models the
behavior of the prior infrastructure.
- All the alias analysis passes are ported to be wrapper passes for the
legacy PM and new-style analysis passes for the new PM with a shared
result object. In some cases (most notably CFL), this is an extremely
naive approach that we should revisit when we can specialize for the
new pass manager.
- BasicAA has been restructured to reflect that it is much more
fundamentally a function analysis because it uses dominator trees and
loop info that need to be constructed for each function.
All of the references to getting alias analysis results have been
updated to use the new aggregation interface. All the preservation and
other pass management code has been updated accordingly.
The way the FunctionAAResultsWrapperPass works is to detect the
available alias analyses when run, and add them to the results object.
This means that we should be able to continue to respect when various
passes are added to the pipeline, for example adding CFL or adding TBAA
passes should just cause their results to be available and to get folded
into this. The exception to this rule is BasicAA which really needs to
be a function pass due to using dominator trees and loop info. As
a consequence, the FunctionAAResultsWrapperPass directly depends on
BasicAA and always includes it in the aggregation.
This has significant implications for preserving analyses. Generally,
most passes shouldn't bother preserving FunctionAAResultsWrapperPass
because rebuilding the results just updates the set of known AA passes.
The exception to this rule are LoopPass instances which need to preserve
all the function analyses that the loop pass manager will end up
needing. This means preserving both BasicAAWrapperPass and the
aggregating FunctionAAResultsWrapperPass.
Now, when preserving an alias analysis, you do so by directly preserving
that analysis. This is only necessary for non-immutable-pass-provided
alias analyses though, and there are only three of interest: BasicAA,
GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
preserved when needed because it (like DominatorTree and LoopInfo) is
marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
set everywhere we previously were preserving all of AliasAnalysis, and
I've added SCEVAA in the intersection of that with where we preserve
SCEV itself.
One significant challenge to all of this is that the CGSCC passes were
actually using the alias analysis implementations by taking advantage of
a pretty amazing set of loop holes in the old pass manager's analysis
management code which allowed analysis groups to slide through in many
cases. Moving away from analysis groups makes this problem much more
obvious. To fix it, I've leveraged the flexibility the design of the new
PM components provides to just directly construct the relevant alias
analyses for the relevant functions in the IPO passes that need them.
This is a bit hacky, but should go away with the new pass manager, and
is already in many ways cleaner than the prior state.
Another significant challenge is that various facilities of the old
alias analysis infrastructure just don't fit any more. The most
significant of these is the alias analysis 'counter' pass. That pass
relied on the ability to snoop on AA queries at different points in the
analysis group chain. Instead, I'm planning to build printing
functionality directly into the aggregation layer. I've not included
that in this patch merely to keep it smaller.
Note that all of this needs a nearly complete rewrite of the AA
documentation. I'm planning to do that, but I'd like to make sure the
new design settles, and to flesh out a bit more of what it looks like in
the new pass manager first.
Differential Revision: http://reviews.llvm.org/D12080
llvm-svn: 247167
2015-09-09 17:55:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void CFLAAWrapperPass::getAnalysisUsage(AnalysisUsage &AU) const {
|
|
|
|
AU.setPreservesAll();
|
2016-06-01 18:39:54 +00:00
|
|
|
AU.addRequired<TargetLibraryInfoWrapperPass>();
|
2015-03-04 18:43:29 +00:00
|
|
|
}
|