2017-08-12 05:30:02 +08:00
|
|
|
//===- CFLSteensAliasAnalysis.cpp - Unification-based Alias Analysis ------===//
|
2014-09-03 05:43:13 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2014-09-03 05:43:13 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2016-07-06 08:26:41 +08:00
|
|
|
// This file implements a CFL-base, summary-based 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 location. The "actions"
|
|
|
|
// can be one of Dereference, Reference, or Assign. The precision of this
|
|
|
|
// analysis is roughly the same as that of an one level context-sensitive
|
|
|
|
// Steensgaard's algorithm.
|
2014-09-03 05:43:13 +08: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 08:54:01 +08:00
|
|
|
// ~nlogn time (n = number of variables), which makes queries take constant
|
2014-09-03 05:43:13 +08:00
|
|
|
// time.
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2016-01-28 08:54:01 +08:00
|
|
|
// N.B. AliasAnalysis as a whole is phrased as a FunctionPass at the moment, and
|
2016-07-06 08:26:41 +08:00
|
|
|
// CFLSteensAA is interprocedural. This is *technically* A Bad Thing, because
|
2016-01-28 08:54:01 +08:00
|
|
|
// 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.
|
|
|
|
|
2016-07-06 08:26:41 +08:00
|
|
|
#include "llvm/Analysis/CFLSteensAliasAnalysis.h"
|
2017-08-12 05:30:02 +08:00
|
|
|
#include "AliasAnalysisSummary.h"
|
2016-07-06 08:36:12 +08:00
|
|
|
#include "CFLGraph.h"
|
2016-07-06 08:47:21 +08:00
|
|
|
#include "StratifiedSets.h"
|
2014-09-03 05:43:13 +08:00
|
|
|
#include "llvm/ADT/DenseMap.h"
|
2015-01-14 19:23:27 +08:00
|
|
|
#include "llvm/ADT/Optional.h"
|
2017-08-12 05:30:02 +08:00
|
|
|
#include "llvm/ADT/SmallVector.h"
|
2016-06-02 02:39:54 +08:00
|
|
|
#include "llvm/Analysis/TargetLibraryInfo.h"
|
2014-09-03 05:43:13 +08:00
|
|
|
#include "llvm/IR/Constants.h"
|
|
|
|
#include "llvm/IR/Function.h"
|
2017-08-12 05:30:02 +08:00
|
|
|
#include "llvm/IR/Type.h"
|
|
|
|
#include "llvm/IR/Value.h"
|
Sink all InitializePasses.h includes
This file lists every pass in LLVM, and is included by Pass.h, which is
very popular. Every time we add, remove, or rename a pass in LLVM, it
caused lots of recompilation.
I found this fact by looking at this table, which is sorted by the
number of times a file was changed over the last 100,000 git commits
multiplied by the number of object files that depend on it in the
current checkout:
recompiles touches affected_files header
342380 95 3604 llvm/include/llvm/ADT/STLExtras.h
314730 234 1345 llvm/include/llvm/InitializePasses.h
307036 118 2602 llvm/include/llvm/ADT/APInt.h
213049 59 3611 llvm/include/llvm/Support/MathExtras.h
170422 47 3626 llvm/include/llvm/Support/Compiler.h
162225 45 3605 llvm/include/llvm/ADT/Optional.h
158319 63 2513 llvm/include/llvm/ADT/Triple.h
140322 39 3598 llvm/include/llvm/ADT/StringRef.h
137647 59 2333 llvm/include/llvm/Support/Error.h
131619 73 1803 llvm/include/llvm/Support/FileSystem.h
Before this change, touching InitializePasses.h would cause 1345 files
to recompile. After this change, touching it only causes 550 compiles in
an incremental rebuild.
Reviewers: bkramer, asbirlea, bollu, jdoerfert
Differential Revision: https://reviews.llvm.org/D70211
2019-11-14 05:15:01 +08:00
|
|
|
#include "llvm/InitializePasses.h"
|
2014-09-03 05:43:13 +08:00
|
|
|
#include "llvm/Pass.h"
|
2015-02-12 11:07:07 +08:00
|
|
|
#include "llvm/Support/Debug.h"
|
2015-03-24 03:32:43 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2014-09-03 05:43:13 +08:00
|
|
|
#include <algorithm>
|
|
|
|
#include <cassert>
|
2017-08-12 05:30:02 +08:00
|
|
|
#include <limits>
|
2015-03-24 03:32:43 +08:00
|
|
|
#include <memory>
|
2017-08-12 05:30:02 +08:00
|
|
|
#include <utility>
|
2014-09-03 05:43:13 +08:00
|
|
|
|
|
|
|
using namespace llvm;
|
2016-07-06 08:36:12 +08:00
|
|
|
using namespace llvm::cflaa;
|
2014-09-03 05:43:13 +08:00
|
|
|
|
2016-07-06 08:26:41 +08:00
|
|
|
#define DEBUG_TYPE "cfl-steens-aa"
|
2015-02-12 11:07:07 +08:00
|
|
|
|
Change TargetLibraryInfo analysis passes to always require Function
Summary:
This is the first change to enable the TLI to be built per-function so
that -fno-builtin* handling can be migrated to use function attributes.
See discussion on D61634 for background. This is an enabler for fixing
handling of these options for LTO, for example.
This change should not affect behavior, as the provided function is not
yet used to build a specifically per-function TLI, but rather enables
that migration.
Most of the changes were very mechanical, e.g. passing a Function to the
legacy analysis pass's getTLI interface, or in Module level cases,
adding a callback. This is similar to the way the per-function TTI
analysis works.
There was one place where we were looking for builtins but not in the
context of a specific function. See FindCXAAtExit in
lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround
could provide the wrong behavior in some corner cases. Suggestions
welcome.
Reviewers: chandlerc, hfinkel
Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66428
llvm-svn: 371284
2019-09-07 11:09:36 +08:00
|
|
|
CFLSteensAAResult::CFLSteensAAResult(
|
|
|
|
std::function<const TargetLibraryInfo &(Function &F)> GetTLI)
|
|
|
|
: AAResultBase(), GetTLI(std::move(GetTLI)) {}
|
2016-07-06 08:26:41 +08:00
|
|
|
CFLSteensAAResult::CFLSteensAAResult(CFLSteensAAResult &&Arg)
|
Change TargetLibraryInfo analysis passes to always require Function
Summary:
This is the first change to enable the TLI to be built per-function so
that -fno-builtin* handling can be migrated to use function attributes.
See discussion on D61634 for background. This is an enabler for fixing
handling of these options for LTO, for example.
This change should not affect behavior, as the provided function is not
yet used to build a specifically per-function TLI, but rather enables
that migration.
Most of the changes were very mechanical, e.g. passing a Function to the
legacy analysis pass's getTLI interface, or in Module level cases,
adding a callback. This is similar to the way the per-function TTI
analysis works.
There was one place where we were looking for builtins but not in the
context of a specific function. See FindCXAAtExit in
lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround
could provide the wrong behavior in some corner cases. Suggestions
welcome.
Reviewers: chandlerc, hfinkel
Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66428
llvm-svn: 371284
2019-09-07 11:09:36 +08:00
|
|
|
: AAResultBase(std::move(Arg)), GetTLI(std::move(Arg.GetTLI)) {}
|
2017-08-12 05:30:02 +08:00
|
|
|
CFLSteensAAResult::~CFLSteensAAResult() = default;
|
2015-08-14 10:42:20 +08:00
|
|
|
|
2016-04-14 07:27:37 +08:00
|
|
|
/// Information we have about a function and would like to keep around.
|
2016-07-06 08:26:41 +08:00
|
|
|
class CFLSteensAAResult::FunctionInfo {
|
2016-07-12 06:59:09 +08:00
|
|
|
StratifiedSets<InstantiatedValue> Sets;
|
2016-07-09 10:54:42 +08:00
|
|
|
AliasSummary Summary;
|
2016-06-24 09:00:03 +08:00
|
|
|
|
2016-06-21 07:10:56 +08:00
|
|
|
public:
|
|
|
|
FunctionInfo(Function &Fn, const SmallVectorImpl<Value *> &RetVals,
|
2016-07-12 06:59:09 +08:00
|
|
|
StratifiedSets<InstantiatedValue> S);
|
2016-06-21 07:10:56 +08:00
|
|
|
|
2016-07-12 06:59:09 +08:00
|
|
|
const StratifiedSets<InstantiatedValue> &getStratifiedSets() const {
|
|
|
|
return Sets;
|
|
|
|
}
|
2017-08-12 05:30:02 +08:00
|
|
|
|
2016-07-09 10:54:42 +08:00
|
|
|
const AliasSummary &getAliasSummary() const { return Summary; }
|
2015-08-14 10:42:20 +08:00
|
|
|
};
|
|
|
|
|
2014-09-03 07:50:01 +08:00
|
|
|
const StratifiedIndex StratifiedLink::SetSentinel =
|
2015-03-15 08:52:21 +08:00
|
|
|
std::numeric_limits<StratifiedIndex>::max();
|
2014-09-03 07:50:01 +08:00
|
|
|
|
2014-09-03 05:43:13 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Function declarations that require types defined in the namespace above
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2016-04-14 07:27:37 +08:00
|
|
|
/// Determines whether it would be pointless to add the given Value to our sets.
|
2015-03-10 10:58:15 +08: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-06 05:10:45 +08:00
|
|
|
bool CanStoreMutableData = isa<GlobalValue>(Val) ||
|
|
|
|
isa<ConstantExpr>(Val) ||
|
|
|
|
isa<ConstantAggregate>(Val);
|
2015-03-10 10:58:15 +08:00
|
|
|
return !CanStoreMutableData;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-07-06 08:26:41 +08:00
|
|
|
CFLSteensAAResult::FunctionInfo::FunctionInfo(
|
|
|
|
Function &Fn, const SmallVectorImpl<Value *> &RetVals,
|
2016-07-12 06:59:09 +08:00
|
|
|
StratifiedSets<InstantiatedValue> S)
|
2016-06-21 07:10:56 +08:00
|
|
|
: Sets(std::move(S)) {
|
2016-06-24 02:55:23 +08: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.
|
2016-06-24 09:00:03 +08:00
|
|
|
|
2016-06-24 04:59:13 +08:00
|
|
|
auto AddToRetParamRelations = [&](unsigned InterfaceIndex,
|
|
|
|
StratifiedIndex SetIndex) {
|
2016-06-24 02:55:23 +08:00
|
|
|
unsigned Level = 0;
|
|
|
|
while (true) {
|
|
|
|
InterfaceValue CurrValue{InterfaceIndex, Level};
|
|
|
|
|
|
|
|
auto Itr = InterfaceMap.find(SetIndex);
|
|
|
|
if (Itr != InterfaceMap.end()) {
|
|
|
|
if (CurrValue != Itr->second)
|
2016-07-09 10:54:42 +08:00
|
|
|
Summary.RetParamRelations.push_back(
|
2016-07-23 06:30:48 +08:00
|
|
|
ExternalRelation{CurrValue, Itr->second, UnknownOffset});
|
2016-06-24 02:55:23 +08:00
|
|
|
break;
|
2016-06-24 09:00:03 +08:00
|
|
|
}
|
2016-06-21 07:10:56 +08:00
|
|
|
|
2016-06-24 02:55:23 +08:00
|
|
|
auto &Link = Sets.getLink(SetIndex);
|
2016-06-24 09:00:03 +08:00
|
|
|
InterfaceMap.insert(std::make_pair(SetIndex, CurrValue));
|
2016-07-06 08:47:21 +08:00
|
|
|
auto ExternalAttrs = getExternallyVisibleAttrs(Link.Attrs);
|
2016-06-24 09:00:03 +08:00
|
|
|
if (ExternalAttrs.any())
|
2016-07-09 10:54:42 +08:00
|
|
|
Summary.RetParamAttributes.push_back(
|
2016-06-24 09:00:03 +08:00
|
|
|
ExternalAttribute{CurrValue, ExternalAttrs});
|
|
|
|
|
2016-06-24 02:55:23 +08:00
|
|
|
if (!Link.hasBelow())
|
|
|
|
break;
|
2016-06-21 07:10:56 +08:00
|
|
|
|
2016-06-24 02:55:23 +08:00
|
|
|
++Level;
|
|
|
|
SetIndex = Link.Below;
|
|
|
|
}
|
|
|
|
};
|
2016-06-21 07:10:56 +08:00
|
|
|
|
2016-06-24 02:55:23 +08:00
|
|
|
// Populate RetParamRelations for return values
|
|
|
|
for (auto *RetVal : RetVals) {
|
2016-06-24 09:00:03 +08:00
|
|
|
assert(RetVal != nullptr);
|
|
|
|
assert(RetVal->getType()->isPointerTy());
|
2016-07-12 06:59:09 +08:00
|
|
|
auto RetInfo = Sets.find(InstantiatedValue{RetVal, 0});
|
2016-06-24 02:55:23 +08:00
|
|
|
if (RetInfo.hasValue())
|
|
|
|
AddToRetParamRelations(0, RetInfo->Index);
|
|
|
|
}
|
2016-06-21 07:10:56 +08:00
|
|
|
|
2016-06-24 02:55:23 +08:00
|
|
|
// Populate RetParamRelations for parameters
|
|
|
|
unsigned I = 0;
|
|
|
|
for (auto &Param : Fn.args()) {
|
|
|
|
if (Param.getType()->isPointerTy()) {
|
2016-07-12 06:59:09 +08:00
|
|
|
auto ParamInfo = Sets.find(InstantiatedValue{&Param, 0});
|
2016-06-24 02:55:23 +08:00
|
|
|
if (ParamInfo.hasValue())
|
|
|
|
AddToRetParamRelations(I + 1, ParamInfo->Index);
|
2016-06-21 07:10:56 +08:00
|
|
|
}
|
2016-06-24 02:55:23 +08:00
|
|
|
++I;
|
2016-06-21 07:10:56 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-08-14 10:42:20 +08:00
|
|
|
// Builds the graph + StratifiedSets for a function.
|
2016-07-06 08:26:41 +08:00
|
|
|
CFLSteensAAResult::FunctionInfo CFLSteensAAResult::buildSetsFrom(Function *Fn) {
|
Change TargetLibraryInfo analysis passes to always require Function
Summary:
This is the first change to enable the TLI to be built per-function so
that -fno-builtin* handling can be migrated to use function attributes.
See discussion on D61634 for background. This is an enabler for fixing
handling of these options for LTO, for example.
This change should not affect behavior, as the provided function is not
yet used to build a specifically per-function TLI, but rather enables
that migration.
Most of the changes were very mechanical, e.g. passing a Function to the
legacy analysis pass's getTLI interface, or in Module level cases,
adding a callback. This is similar to the way the per-function TTI
analysis works.
There was one place where we were looking for builtins but not in the
context of a specific function. See FindCXAAtExit in
lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround
could provide the wrong behavior in some corner cases. Suggestions
welcome.
Reviewers: chandlerc, hfinkel
Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66428
llvm-svn: 371284
2019-09-07 11:09:36 +08:00
|
|
|
CFLGraphBuilder<CFLSteensAAResult> GraphBuilder(*this, GetTLI(*Fn), *Fn);
|
2016-07-12 06:59:09 +08:00
|
|
|
StratifiedSetsBuilder<InstantiatedValue> SetBuilder;
|
2014-09-03 05:43:13 +08:00
|
|
|
|
2016-07-12 06:59:09 +08:00
|
|
|
// Add all CFLGraph nodes and all Dereference edges to StratifiedSets
|
2016-06-15 02:02:27 +08:00
|
|
|
auto &Graph = GraphBuilder.getCFLGraph();
|
2016-07-12 06:59:09 +08:00
|
|
|
for (const auto &Mapping : Graph.value_mappings()) {
|
|
|
|
auto Val = Mapping.first;
|
|
|
|
if (canSkipAddingToSets(Val))
|
2016-06-14 03:21:18 +08:00
|
|
|
continue;
|
2016-07-12 06:59:09 +08:00
|
|
|
auto &ValueInfo = Mapping.second;
|
|
|
|
|
|
|
|
assert(ValueInfo.getNumLevels() > 0);
|
|
|
|
SetBuilder.add(InstantiatedValue{Val, 0});
|
|
|
|
SetBuilder.noteAttributes(InstantiatedValue{Val, 0},
|
|
|
|
ValueInfo.getNodeInfoAtLevel(0).Attr);
|
|
|
|
for (unsigned I = 0, E = ValueInfo.getNumLevels() - 1; I < E; ++I) {
|
|
|
|
SetBuilder.add(InstantiatedValue{Val, I + 1});
|
|
|
|
SetBuilder.noteAttributes(InstantiatedValue{Val, I + 1},
|
|
|
|
ValueInfo.getNodeInfoAtLevel(I + 1).Attr);
|
|
|
|
SetBuilder.addBelow(InstantiatedValue{Val, I},
|
|
|
|
InstantiatedValue{Val, I + 1});
|
2014-09-03 05:43:13 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-07-12 06:59:09 +08:00
|
|
|
// Add all assign edges to StratifiedSets
|
|
|
|
for (const auto &Mapping : Graph.value_mappings()) {
|
|
|
|
auto Val = Mapping.first;
|
|
|
|
if (canSkipAddingToSets(Val))
|
|
|
|
continue;
|
|
|
|
auto &ValueInfo = Mapping.second;
|
2016-06-24 02:55:23 +08:00
|
|
|
|
2016-07-12 06:59:09 +08:00
|
|
|
for (unsigned I = 0, E = ValueInfo.getNumLevels(); I < E; ++I) {
|
|
|
|
auto Src = InstantiatedValue{Val, I};
|
|
|
|
for (auto &Edge : ValueInfo.getNodeInfoAtLevel(I).Edges)
|
|
|
|
SetBuilder.addWith(Src, Edge.Other);
|
|
|
|
}
|
2016-06-24 09:00:03 +08:00
|
|
|
}
|
|
|
|
|
2016-06-21 07:10:56 +08:00
|
|
|
return FunctionInfo(*Fn, GraphBuilder.getReturnValues(), SetBuilder.build());
|
2014-09-03 05:43:13 +08:00
|
|
|
}
|
|
|
|
|
2016-07-06 08:26:41 +08:00
|
|
|
void CFLSteensAAResult::scan(Function *Fn) {
|
2014-09-03 06:52:30 +08:00
|
|
|
auto InsertPair = Cache.insert(std::make_pair(Fn, Optional<FunctionInfo>()));
|
2014-09-03 05:43:13 +08:00
|
|
|
(void)InsertPair;
|
|
|
|
assert(InsertPair.second &&
|
|
|
|
"Trying to scan a function that has already been cached");
|
|
|
|
|
2016-05-03 02:09:19 +08: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);
|
|
|
|
|
2017-06-27 07:59:14 +08:00
|
|
|
Handles.emplace_front(Fn, this);
|
2014-09-03 05:43:13 +08:00
|
|
|
}
|
|
|
|
|
2016-07-06 08:26:41 +08:00
|
|
|
void CFLSteensAAResult::evict(Function *Fn) { Cache.erase(Fn); }
|
2015-08-14 10:42:20 +08:00
|
|
|
|
2016-04-14 07:27:37 +08:00
|
|
|
/// Ensures that the given function is available in the cache, and returns the
|
|
|
|
/// entry.
|
2016-07-06 08:26:41 +08:00
|
|
|
const Optional<CFLSteensAAResult::FunctionInfo> &
|
|
|
|
CFLSteensAAResult::ensureCached(Function *Fn) {
|
2015-08-14 10:42:20 +08: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;
|
|
|
|
}
|
|
|
|
|
2016-07-09 10:54:42 +08:00
|
|
|
const AliasSummary *CFLSteensAAResult::getAliasSummary(Function &Fn) {
|
|
|
|
auto &FunInfo = ensureCached(&Fn);
|
|
|
|
if (FunInfo.hasValue())
|
|
|
|
return &FunInfo->getAliasSummary();
|
|
|
|
else
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
2016-07-06 08:26:41 +08:00
|
|
|
AliasResult CFLSteensAAResult::query(const MemoryLocation &LocA,
|
|
|
|
const MemoryLocation &LocB) {
|
2014-09-03 05:43:13 +08:00
|
|
|
auto *ValA = const_cast<Value *>(LocA.Ptr);
|
|
|
|
auto *ValB = const_cast<Value *>(LocB.Ptr);
|
|
|
|
|
2016-06-16 04:43:41 +08:00
|
|
|
if (!ValA->getType()->isPointerTy() || !ValB->getType()->isPointerTy())
|
2021-03-05 18:58:13 +08:00
|
|
|
return AliasResult::NoAlias;
|
2016-06-16 04:43:41 +08:00
|
|
|
|
2014-09-03 05:43:13 +08:00
|
|
|
Function *Fn = nullptr;
|
2017-06-27 10:25:06 +08:00
|
|
|
Function *MaybeFnA = const_cast<Function *>(parentFunctionOfValue(ValA));
|
|
|
|
Function *MaybeFnB = const_cast<Function *>(parentFunctionOfValue(ValB));
|
2017-06-27 08:33:37 +08:00
|
|
|
if (!MaybeFnA && !MaybeFnB) {
|
2016-04-14 07:27:37 +08:00
|
|
|
// The only times this is known to happen are when globals + InlineAsm are
|
|
|
|
// involved
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(
|
|
|
|
dbgs()
|
|
|
|
<< "CFLSteensAA: could not extract parent function information.\n");
|
2021-03-05 18:58:13 +08:00
|
|
|
return AliasResult::MayAlias;
|
2014-09-03 05:43:13 +08:00
|
|
|
}
|
|
|
|
|
2017-06-27 08:33:37 +08:00
|
|
|
if (MaybeFnA) {
|
|
|
|
Fn = MaybeFnA;
|
|
|
|
assert((!MaybeFnB || MaybeFnB == MaybeFnA) &&
|
2014-09-03 05:43:13 +08:00
|
|
|
"Interprocedural queries not supported");
|
|
|
|
} else {
|
2017-06-27 08:33:37 +08:00
|
|
|
Fn = MaybeFnB;
|
2014-09-03 05:43:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
assert(Fn != nullptr);
|
|
|
|
auto &MaybeInfo = ensureCached(Fn);
|
|
|
|
assert(MaybeInfo.hasValue());
|
|
|
|
|
2016-06-21 07:10:56 +08:00
|
|
|
auto &Sets = MaybeInfo->getStratifiedSets();
|
2016-07-12 06:59:09 +08:00
|
|
|
auto MaybeA = Sets.find(InstantiatedValue{ValA, 0});
|
2014-09-03 05:43:13 +08:00
|
|
|
if (!MaybeA.hasValue())
|
2021-03-05 18:58:13 +08:00
|
|
|
return AliasResult::MayAlias;
|
2014-09-03 05:43:13 +08:00
|
|
|
|
2016-07-12 06:59:09 +08:00
|
|
|
auto MaybeB = Sets.find(InstantiatedValue{ValB, 0});
|
2014-09-03 05:43:13 +08:00
|
|
|
if (!MaybeB.hasValue())
|
2021-03-05 18:58:13 +08:00
|
|
|
return AliasResult::MayAlias;
|
2014-09-03 05:43:13 +08:00
|
|
|
|
|
|
|
auto SetA = *MaybeA;
|
|
|
|
auto SetB = *MaybeB;
|
|
|
|
auto AttrsA = Sets.getLink(SetA.Index).Attrs;
|
|
|
|
auto AttrsB = Sets.getLink(SetB.Index).Attrs;
|
2015-02-12 11:07:07 +08:00
|
|
|
|
2016-06-08 02:35:37 +08:00
|
|
|
// If both values are local (meaning the corresponding set has attribute
|
2016-07-06 08:26:41 +08:00
|
|
|
// AttrNone or AttrEscaped), then we know that CFLSteensAA fully models them:
|
|
|
|
// they may-alias each other if and only if they are in the same set.
|
2016-06-08 02:35:37 +08:00
|
|
|
// 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-10 07:15:04 +08:00
|
|
|
// - AttrEscaped do not alias globals/arguments, but they may alias
|
2016-06-08 02:35:37 +08:00
|
|
|
// AttrUnknown values
|
|
|
|
if (SetA.Index == SetB.Index)
|
2021-03-05 18:58:13 +08:00
|
|
|
return AliasResult::MayAlias;
|
2016-06-08 02:35:37 +08:00
|
|
|
if (AttrsA.none() || AttrsB.none())
|
2021-03-05 18:58:13 +08:00
|
|
|
return AliasResult::NoAlias;
|
2016-07-06 08:47:21 +08:00
|
|
|
if (hasUnknownOrCallerAttr(AttrsA) || hasUnknownOrCallerAttr(AttrsB))
|
2021-03-05 18:58:13 +08:00
|
|
|
return AliasResult::MayAlias;
|
2016-06-08 02:35:37 +08:00
|
|
|
if (isGlobalOrArgAttr(AttrsA) && isGlobalOrArgAttr(AttrsB))
|
2021-03-05 18:58:13 +08:00
|
|
|
return AliasResult::MayAlias;
|
|
|
|
return AliasResult::NoAlias;
|
2014-09-03 05:43:13 +08:00
|
|
|
}
|
2015-03-05 02:43:29 +08:00
|
|
|
|
2016-11-24 01:53:26 +08:00
|
|
|
AnalysisKey CFLSteensAA::Key;
|
2016-03-11 18:22:49 +08:00
|
|
|
|
2016-08-09 08:28:15 +08:00
|
|
|
CFLSteensAAResult CFLSteensAA::run(Function &F, FunctionAnalysisManager &AM) {
|
Change TargetLibraryInfo analysis passes to always require Function
Summary:
This is the first change to enable the TLI to be built per-function so
that -fno-builtin* handling can be migrated to use function attributes.
See discussion on D61634 for background. This is an enabler for fixing
handling of these options for LTO, for example.
This change should not affect behavior, as the provided function is not
yet used to build a specifically per-function TLI, but rather enables
that migration.
Most of the changes were very mechanical, e.g. passing a Function to the
legacy analysis pass's getTLI interface, or in Module level cases,
adding a callback. This is similar to the way the per-function TTI
analysis works.
There was one place where we were looking for builtins but not in the
context of a specific function. See FindCXAAtExit in
lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround
could provide the wrong behavior in some corner cases. Suggestions
welcome.
Reviewers: chandlerc, hfinkel
Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66428
llvm-svn: 371284
2019-09-07 11:09:36 +08:00
|
|
|
auto GetTLI = [&AM](Function &F) -> const TargetLibraryInfo & {
|
|
|
|
return AM.getResult<TargetLibraryAnalysis>(F);
|
|
|
|
};
|
|
|
|
return CFLSteensAAResult(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-10 01:55:00 +08:00
|
|
|
}
|
|
|
|
|
2016-07-06 08:26:41 +08:00
|
|
|
char CFLSteensAAWrapperPass::ID = 0;
|
|
|
|
INITIALIZE_PASS(CFLSteensAAWrapperPass, "cfl-steens-aa",
|
|
|
|
"Unification-Based CFL 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-10 01:55:00 +08:00
|
|
|
|
2016-07-06 08:26:41 +08:00
|
|
|
ImmutablePass *llvm::createCFLSteensAAWrapperPass() {
|
|
|
|
return new CFLSteensAAWrapperPass();
|
|
|
|
}
|
[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-10 01:55:00 +08:00
|
|
|
|
2016-07-06 08:26:41 +08:00
|
|
|
CFLSteensAAWrapperPass::CFLSteensAAWrapperPass() : ImmutablePass(ID) {
|
|
|
|
initializeCFLSteensAAWrapperPassPass(*PassRegistry::getPassRegistry());
|
[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-10 01:55:00 +08:00
|
|
|
}
|
|
|
|
|
2016-07-06 08:26:41 +08:00
|
|
|
void CFLSteensAAWrapperPass::initializePass() {
|
Change TargetLibraryInfo analysis passes to always require Function
Summary:
This is the first change to enable the TLI to be built per-function so
that -fno-builtin* handling can be migrated to use function attributes.
See discussion on D61634 for background. This is an enabler for fixing
handling of these options for LTO, for example.
This change should not affect behavior, as the provided function is not
yet used to build a specifically per-function TLI, but rather enables
that migration.
Most of the changes were very mechanical, e.g. passing a Function to the
legacy analysis pass's getTLI interface, or in Module level cases,
adding a callback. This is similar to the way the per-function TTI
analysis works.
There was one place where we were looking for builtins but not in the
context of a specific function. See FindCXAAtExit in
lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround
could provide the wrong behavior in some corner cases. Suggestions
welcome.
Reviewers: chandlerc, hfinkel
Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66428
llvm-svn: 371284
2019-09-07 11:09:36 +08:00
|
|
|
auto GetTLI = [this](Function &F) -> const TargetLibraryInfo & {
|
|
|
|
return this->getAnalysis<TargetLibraryInfoWrapperPass>().getTLI(F);
|
|
|
|
};
|
|
|
|
Result.reset(new CFLSteensAAResult(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-10 01:55:00 +08:00
|
|
|
}
|
|
|
|
|
2016-07-06 08:26:41 +08:00
|
|
|
void CFLSteensAAWrapperPass::getAnalysisUsage(AnalysisUsage &AU) const {
|
[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-10 01:55:00 +08:00
|
|
|
AU.setPreservesAll();
|
2016-06-02 02:39:54 +08:00
|
|
|
AU.addRequired<TargetLibraryInfoWrapperPass>();
|
2015-03-05 02:43:29 +08:00
|
|
|
}
|