2004-06-28 14:33:13 +08:00
|
|
|
//===- GlobalsModRef.cpp - Simple Mod/Ref Analysis for Globals ------------===//
|
2005-04-22 05:13:18 +08:00
|
|
|
//
|
2004-06-28 14:33:13 +08:00
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
2007-12-30 04:36:04 +08:00
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
2005-04-22 05:13:18 +08:00
|
|
|
//
|
2004-06-28 14:33:13 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This simple pass provides alias and mod/ref information for global values
|
2004-07-27 14:40:37 +08:00
|
|
|
// that do not have their address taken, and keeps track of whether functions
|
|
|
|
// read or write memory (are "pure"). For this simple (but very common) case,
|
|
|
|
// we can provide pretty accurate and useful information.
|
2004-06-28 14:33:13 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2015-08-14 11:48:20 +08:00
|
|
|
#include "llvm/Analysis/GlobalsModRef.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/ADT/SCCIterator.h"
|
2015-07-22 19:47:54 +08:00
|
|
|
#include "llvm/ADT/SmallPtrSet.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/ADT/Statistic.h"
|
2009-10-28 04:05:49 +08:00
|
|
|
#include "llvm/Analysis/MemoryBuiltins.h"
|
[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
|
|
|
#include "llvm/Analysis/TargetLibraryInfo.h"
|
2010-12-16 04:02:24 +08:00
|
|
|
#include "llvm/Analysis/ValueTracking.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/DerivedTypes.h"
|
2014-03-04 18:30:26 +08:00
|
|
|
#include "llvm/IR/InstIterator.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/Instructions.h"
|
|
|
|
#include "llvm/IR/IntrinsicInst.h"
|
|
|
|
#include "llvm/IR/Module.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/Pass.h"
|
2004-09-02 06:55:40 +08:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
2004-06-28 14:33:13 +08:00
|
|
|
using namespace llvm;
|
|
|
|
|
2014-04-22 10:48:03 +08:00
|
|
|
#define DEBUG_TYPE "globalsmodref-aa"
|
|
|
|
|
2006-12-20 06:30:33 +08:00
|
|
|
STATISTIC(NumNonAddrTakenGlobalVars,
|
|
|
|
"Number of global vars without address taken");
|
|
|
|
STATISTIC(NumNonAddrTakenFunctions,"Number of functions without address taken");
|
|
|
|
STATISTIC(NumNoMemFunctions, "Number of functions that do not access memory");
|
|
|
|
STATISTIC(NumReadMemFunctions, "Number of functions that only read memory");
|
|
|
|
STATISTIC(NumIndirectGlobalVars, "Number of indirect global objects");
|
|
|
|
|
[PM/AA] Disable the core unsafe aspect of GlobalsModRef in the face of
basic changes to the IR such as folding pointers through PHIs, Selects,
integer casts, store/load pairs, or outlining.
This leaves the feature available behind a flag. This flag's default
could be flipped if necessary, but the real-world performance impact of
this particular feature of GMR may not be sufficiently significant for
many folks to want to run the risk.
Currently, the risk here is somewhat mitigated by half-hearted attempts
to update GlobalsModRef when the rest of the optimizer changes
something. However, I am currently trying to remove that update
mechanism as it makes migrating the AA infrastructure to a form that can
be readily shared between new and old pass managers very challenging.
Without this update mechanism, it is possible that this still unlikely
failure mode will start to trip people, and so I wanted to try to
proactively avoid that.
There is a lengthy discussion on the mailing list about why the core
approach here is flawed, and likely would need to look totally different
to be both reasonably effective and resilient to basic IR changes
occuring. This patch is essentially the first of two which will enact
the result of that discussion. The next patch will remove the current
update mechanism.
Thanks to lots of folks that helped look at this from different angles.
Especial thanks to Michael Zolotukhin for doing some very prelimanary
benchmarking of LTO without GlobalsModRef to get a rough idea of the
impact we could be facing here. So far, it looks very small, but there
are some concerns lingering from other benchmarking. The default here
may get flipped if performance results end up pointing at this as a more
significant issue.
Also thanks to Pete and Gerolf for reviewing!
Differential Revision: http://reviews.llvm.org/D11213
llvm-svn: 242512
2015-07-17 14:58:24 +08:00
|
|
|
// An option to enable unsafe alias results from the GlobalsModRef analysis.
|
|
|
|
// When enabled, GlobalsModRef will provide no-alias results which in extremely
|
|
|
|
// rare cases may not be conservatively correct. In particular, in the face of
|
|
|
|
// transforms which cause assymetry between how effective GetUnderlyingObject
|
|
|
|
// is for two pointers, it may produce incorrect results.
|
|
|
|
//
|
|
|
|
// These unsafe results have been returned by GMR for many years without
|
|
|
|
// causing significant issues in the wild and so we provide a mechanism to
|
|
|
|
// re-enable them for users of LLVM that have a particular performance
|
|
|
|
// sensitivity and no known issues. The option also makes it easy to evaluate
|
|
|
|
// the performance impact of these results.
|
|
|
|
static cl::opt<bool> EnableUnsafeGlobalsModRefAliasResults(
|
|
|
|
"enable-unsafe-globalsmodref-alias-results", cl::init(false), cl::Hidden);
|
|
|
|
|
2015-07-23 07:56:31 +08:00
|
|
|
/// The mod/ref information collected for a particular function.
|
|
|
|
///
|
|
|
|
/// We collect information about mod/ref behavior of a function here, both in
|
|
|
|
/// general and as pertains to specific globals. We only have this detailed
|
|
|
|
/// information when we know *something* useful about the behavior. If we
|
|
|
|
/// saturate to fully general mod/ref, we remove the info for the 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-10 01:55:00 +08:00
|
|
|
class GlobalsAAResult::FunctionInfo {
|
2015-07-23 15:50:52 +08:00
|
|
|
typedef SmallDenseMap<const GlobalValue *, ModRefInfo, 16> GlobalInfoMapType;
|
|
|
|
|
|
|
|
/// Build a wrapper struct that has 8-byte alignment. All heap allocations
|
|
|
|
/// should provide this much alignment at least, but this makes it clear we
|
|
|
|
/// specifically rely on this amount of alignment.
|
|
|
|
struct LLVM_ALIGNAS(8) AlignedMap {
|
|
|
|
AlignedMap() {}
|
|
|
|
AlignedMap(const AlignedMap &Arg) : Map(Arg.Map) {}
|
|
|
|
GlobalInfoMapType Map;
|
|
|
|
};
|
|
|
|
|
|
|
|
/// Pointer traits for our aligned map.
|
|
|
|
struct AlignedMapPointerTraits {
|
|
|
|
static inline void *getAsVoidPointer(AlignedMap *P) { return P; }
|
|
|
|
static inline AlignedMap *getFromVoidPointer(void *P) {
|
|
|
|
return (AlignedMap *)P;
|
|
|
|
}
|
|
|
|
enum { NumLowBitsAvailable = 3 };
|
2016-10-20 23:02:18 +08:00
|
|
|
static_assert(alignof(AlignedMap) >= (1 << NumLowBitsAvailable),
|
2015-07-23 15:50:52 +08:00
|
|
|
"AlignedMap insufficiently aligned to have enough low bits.");
|
|
|
|
};
|
|
|
|
|
|
|
|
/// The bit that flags that this function may read any global. This is
|
|
|
|
/// chosen to mix together with ModRefInfo bits.
|
2017-12-06 04:12:23 +08:00
|
|
|
/// FIXME: This assumes ModRefInfo lattice will remain 4 bits!
|
2015-07-23 15:50:52 +08:00
|
|
|
enum { MayReadAnyGlobal = 4 };
|
|
|
|
|
|
|
|
/// Checks to document the invariants of the bit packing here.
|
2017-12-08 06:41:34 +08:00
|
|
|
static_assert((MayReadAnyGlobal & static_cast<int>(ModRefInfo::ModRef)) == 0,
|
2015-07-23 15:50:52 +08:00
|
|
|
"ModRef and the MayReadAnyGlobal flag bits overlap.");
|
2017-12-08 06:41:34 +08:00
|
|
|
static_assert(((MayReadAnyGlobal | static_cast<int>(ModRefInfo::ModRef)) >>
|
2015-07-23 15:50:52 +08:00
|
|
|
AlignedMapPointerTraits::NumLowBitsAvailable) == 0,
|
|
|
|
"Insufficient low bits to store our flag and ModRef info.");
|
|
|
|
|
2015-07-23 07:56:31 +08:00
|
|
|
public:
|
2015-07-23 15:50:52 +08:00
|
|
|
FunctionInfo() : Info() {}
|
|
|
|
~FunctionInfo() {
|
|
|
|
delete Info.getPointer();
|
|
|
|
}
|
|
|
|
// Spell out the copy ond move constructors and assignment operators to get
|
|
|
|
// deep copy semantics and correct move semantics in the face of the
|
|
|
|
// pointer-int pair.
|
|
|
|
FunctionInfo(const FunctionInfo &Arg)
|
|
|
|
: Info(nullptr, Arg.Info.getInt()) {
|
|
|
|
if (const auto *ArgPtr = Arg.Info.getPointer())
|
|
|
|
Info.setPointer(new AlignedMap(*ArgPtr));
|
|
|
|
}
|
|
|
|
FunctionInfo(FunctionInfo &&Arg)
|
|
|
|
: Info(Arg.Info.getPointer(), Arg.Info.getInt()) {
|
|
|
|
Arg.Info.setPointerAndInt(nullptr, 0);
|
|
|
|
}
|
|
|
|
FunctionInfo &operator=(const FunctionInfo &RHS) {
|
|
|
|
delete Info.getPointer();
|
|
|
|
Info.setPointerAndInt(nullptr, RHS.Info.getInt());
|
|
|
|
if (const auto *RHSPtr = RHS.Info.getPointer())
|
|
|
|
Info.setPointer(new AlignedMap(*RHSPtr));
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
FunctionInfo &operator=(FunctionInfo &&RHS) {
|
|
|
|
delete Info.getPointer();
|
|
|
|
Info.setPointerAndInt(RHS.Info.getPointer(), RHS.Info.getInt());
|
|
|
|
RHS.Info.setPointerAndInt(nullptr, 0);
|
|
|
|
return *this;
|
|
|
|
}
|
2015-07-23 07:56:31 +08:00
|
|
|
|
|
|
|
/// Returns the \c ModRefInfo info for this function.
|
2015-07-23 15:50:52 +08:00
|
|
|
ModRefInfo getModRefInfo() const {
|
2017-12-08 06:41:34 +08:00
|
|
|
return ModRefInfo(Info.getInt() & static_cast<int>(ModRefInfo::ModRef));
|
2015-07-23 15:50:52 +08:00
|
|
|
}
|
2015-07-14 16:42:39 +08:00
|
|
|
|
2015-07-23 07:56:31 +08:00
|
|
|
/// Adds new \c ModRefInfo for this function to its state.
|
2015-07-23 15:50:52 +08:00
|
|
|
void addModRefInfo(ModRefInfo NewMRI) {
|
2017-12-08 06:41:34 +08:00
|
|
|
Info.setInt(Info.getInt() | static_cast<int>(NewMRI));
|
2015-07-23 15:50:52 +08:00
|
|
|
}
|
2015-07-23 07:56:31 +08:00
|
|
|
|
|
|
|
/// Returns whether this function may read any global variable, and we don't
|
|
|
|
/// know which global.
|
2015-07-23 15:50:52 +08:00
|
|
|
bool mayReadAnyGlobal() const { return Info.getInt() & MayReadAnyGlobal; }
|
2015-07-23 07:56:31 +08:00
|
|
|
|
|
|
|
/// Sets this function as potentially reading from any global.
|
2015-07-23 15:50:52 +08:00
|
|
|
void setMayReadAnyGlobal() { Info.setInt(Info.getInt() | MayReadAnyGlobal); }
|
2015-07-23 07:56:31 +08:00
|
|
|
|
|
|
|
/// Returns the \c ModRefInfo info for this function w.r.t. a particular
|
|
|
|
/// global, which may be more precise than the general information above.
|
|
|
|
ModRefInfo getModRefInfoForGlobal(const GlobalValue &GV) const {
|
2017-12-08 06:41:34 +08:00
|
|
|
ModRefInfo GlobalMRI =
|
|
|
|
mayReadAnyGlobal() ? ModRefInfo::Ref : ModRefInfo::NoModRef;
|
2015-07-23 15:50:52 +08:00
|
|
|
if (AlignedMap *P = Info.getPointer()) {
|
|
|
|
auto I = P->Map.find(&GV);
|
|
|
|
if (I != P->Map.end())
|
2017-12-07 08:43:19 +08:00
|
|
|
GlobalMRI = unionModRef(GlobalMRI, I->second);
|
2015-07-23 15:50:52 +08:00
|
|
|
}
|
2015-07-23 07:56:31 +08:00
|
|
|
return GlobalMRI;
|
2015-07-14 16:42:39 +08:00
|
|
|
}
|
2005-04-22 05:13:18 +08:00
|
|
|
|
2015-07-23 08:12:32 +08:00
|
|
|
/// Add mod/ref info from another function into ours, saturating towards
|
2017-12-08 06:41:34 +08:00
|
|
|
/// ModRef.
|
2015-07-23 08:12:32 +08:00
|
|
|
void addFunctionInfo(const FunctionInfo &FI) {
|
|
|
|
addModRefInfo(FI.getModRefInfo());
|
|
|
|
|
|
|
|
if (FI.mayReadAnyGlobal())
|
|
|
|
setMayReadAnyGlobal();
|
|
|
|
|
2015-07-23 15:50:52 +08:00
|
|
|
if (AlignedMap *P = FI.Info.getPointer())
|
|
|
|
for (const auto &G : P->Map)
|
|
|
|
addModRefInfoForGlobal(*G.first, G.second);
|
2015-07-23 07:56:31 +08:00
|
|
|
}
|
2004-07-27 15:46:26 +08:00
|
|
|
|
2015-07-23 07:56:31 +08:00
|
|
|
void addModRefInfoForGlobal(const GlobalValue &GV, ModRefInfo NewMRI) {
|
2015-07-23 15:50:52 +08:00
|
|
|
AlignedMap *P = Info.getPointer();
|
|
|
|
if (!P) {
|
|
|
|
P = new AlignedMap();
|
|
|
|
Info.setPointer(P);
|
|
|
|
}
|
|
|
|
auto &GlobalMRI = P->Map[&GV];
|
2017-12-07 08:43:19 +08:00
|
|
|
GlobalMRI = unionModRef(GlobalMRI, NewMRI);
|
2015-07-23 07:56:31 +08:00
|
|
|
}
|
|
|
|
|
2015-07-28 14:01:57 +08:00
|
|
|
/// Clear a global's ModRef info. Should be used when a global is being
|
|
|
|
/// deleted.
|
|
|
|
void eraseModRefInfoForGlobal(const GlobalValue &GV) {
|
|
|
|
if (AlignedMap *P = Info.getPointer())
|
|
|
|
P->Map.erase(&GV);
|
|
|
|
}
|
|
|
|
|
2015-07-23 07:56:31 +08:00
|
|
|
private:
|
2015-07-23 15:50:52 +08:00
|
|
|
/// All of the information is encoded into a single pointer, with a three bit
|
|
|
|
/// integer in the low three bits. The high bit provides a flag for when this
|
|
|
|
/// function may read any global. The low two bits are the ModRefInfo. And
|
|
|
|
/// the pointer, when non-null, points to a map from GlobalValue to
|
|
|
|
/// ModRefInfo specific to that GlobalValue.
|
|
|
|
PointerIntPair<AlignedMap *, 3, unsigned, AlignedMapPointerTraits> Info;
|
2015-07-14 16:42:39 +08:00
|
|
|
};
|
2004-06-28 14:33:13 +08: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-10 01:55:00 +08:00
|
|
|
void GlobalsAAResult::DeletionCallbackHandle::deleted() {
|
2015-08-14 11:48:20 +08:00
|
|
|
Value *V = getValPtr();
|
|
|
|
if (auto *F = dyn_cast<Function>(V))
|
2015-09-14 14:16:44 +08:00
|
|
|
GAR->FunctionInfos.erase(F);
|
2015-08-14 11:48:20 +08:00
|
|
|
|
|
|
|
if (GlobalValue *GV = dyn_cast<GlobalValue>(V)) {
|
2015-09-14 14:16:44 +08:00
|
|
|
if (GAR->NonAddressTakenGlobals.erase(GV)) {
|
2015-08-14 11:48:20 +08:00
|
|
|
// This global might be an indirect global. If so, remove it and
|
|
|
|
// remove any AllocRelatedValues for it.
|
2015-09-14 14:16:44 +08:00
|
|
|
if (GAR->IndirectGlobals.erase(GV)) {
|
2015-08-14 11:48:20 +08:00
|
|
|
// Remove any entries in AllocsForIndirectGlobals for this global.
|
2015-09-14 14:16:44 +08:00
|
|
|
for (auto I = GAR->AllocsForIndirectGlobals.begin(),
|
|
|
|
E = GAR->AllocsForIndirectGlobals.end();
|
2015-08-14 11:48:20 +08:00
|
|
|
I != E; ++I)
|
|
|
|
if (I->second == GV)
|
2015-09-14 14:16:44 +08:00
|
|
|
GAR->AllocsForIndirectGlobals.erase(I);
|
2015-07-22 19:10:41 +08:00
|
|
|
}
|
|
|
|
|
2015-08-14 11:48:20 +08:00
|
|
|
// Scan the function info we have collected and remove this global
|
|
|
|
// from all of them.
|
2015-09-14 14:16:44 +08:00
|
|
|
for (auto &FIPair : GAR->FunctionInfos)
|
2015-08-14 11:48:20 +08:00
|
|
|
FIPair.second.eraseModRefInfoForGlobal(*GV);
|
2015-07-22 19:10:41 +08:00
|
|
|
}
|
2015-08-14 11:48:20 +08:00
|
|
|
}
|
2015-07-22 17:27:58 +08:00
|
|
|
|
2015-08-14 11:48:20 +08:00
|
|
|
// If this is an allocation related to an indirect global, remove it.
|
2015-09-14 14:16:44 +08:00
|
|
|
GAR->AllocsForIndirectGlobals.erase(V);
|
2015-07-22 17:27:58 +08:00
|
|
|
|
2015-08-14 11:48:20 +08:00
|
|
|
// And clear out the handle.
|
|
|
|
setValPtr(nullptr);
|
2015-09-14 14:16:44 +08:00
|
|
|
GAR->Handles.erase(I);
|
2015-08-14 11:48:20 +08:00
|
|
|
// This object is now destroyed!
|
|
|
|
}
|
2008-03-18 08:39:19 +08: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-10 01:55:00 +08:00
|
|
|
FunctionModRefBehavior GlobalsAAResult::getModRefBehavior(const Function *F) {
|
2015-08-14 11:48:20 +08:00
|
|
|
FunctionModRefBehavior Min = FMRB_UnknownModRefBehavior;
|
2015-07-14 16:42:39 +08:00
|
|
|
|
2015-08-14 11:48:20 +08:00
|
|
|
if (FunctionInfo *FI = getFunctionInfo(F)) {
|
2017-12-06 04:12:23 +08:00
|
|
|
if (!isModOrRefSet(FI->getModRefInfo()))
|
2015-08-14 11:48:20 +08:00
|
|
|
Min = FMRB_DoesNotAccessMemory;
|
2017-12-06 04:12:23 +08:00
|
|
|
else if (!isModSet(FI->getModRefInfo()))
|
2015-08-14 11:48:20 +08:00
|
|
|
Min = FMRB_OnlyReadsMemory;
|
2015-07-23 07:15:57 +08: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-10 01:55:00 +08:00
|
|
|
return FunctionModRefBehavior(AAResultBase::getModRefBehavior(F) & Min);
|
2015-08-14 11:48:20 +08:00
|
|
|
}
|
2004-06-28 14:33:13 +08: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-10 01:55:00 +08:00
|
|
|
FunctionModRefBehavior
|
|
|
|
GlobalsAAResult::getModRefBehavior(ImmutableCallSite CS) {
|
2015-08-14 11:48:20 +08:00
|
|
|
FunctionModRefBehavior Min = FMRB_UnknownModRefBehavior;
|
2015-07-14 16:42:39 +08:00
|
|
|
|
2016-02-09 10:31:47 +08:00
|
|
|
if (!CS.hasOperandBundles())
|
|
|
|
if (const Function *F = CS.getCalledFunction())
|
|
|
|
if (FunctionInfo *FI = getFunctionInfo(F)) {
|
2017-12-06 04:12:23 +08:00
|
|
|
if (!isModOrRefSet(FI->getModRefInfo()))
|
2016-02-09 10:31:47 +08:00
|
|
|
Min = FMRB_DoesNotAccessMemory;
|
2017-12-06 04:12:23 +08:00
|
|
|
else if (!isModSet(FI->getModRefInfo()))
|
2016-02-09 10:31:47 +08:00
|
|
|
Min = FMRB_OnlyReadsMemory;
|
|
|
|
}
|
2004-06-28 14:33:13 +08: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-10 01:55:00 +08:00
|
|
|
return FunctionModRefBehavior(AAResultBase::getModRefBehavior(CS) & Min);
|
2015-06-23 17:49:53 +08:00
|
|
|
}
|
2004-06-28 14:33:13 +08:00
|
|
|
|
2015-08-14 11:48:20 +08:00
|
|
|
/// Returns the function info for the function, or null if we don't have
|
|
|
|
/// anything useful to say about it.
|
[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
|
|
|
GlobalsAAResult::FunctionInfo *
|
|
|
|
GlobalsAAResult::getFunctionInfo(const Function *F) {
|
2015-08-14 11:48:20 +08:00
|
|
|
auto I = FunctionInfos.find(F);
|
|
|
|
if (I != FunctionInfos.end())
|
|
|
|
return &I->second;
|
|
|
|
return nullptr;
|
|
|
|
}
|
2004-06-28 14:33:13 +08:00
|
|
|
|
2006-10-02 06:36:45 +08:00
|
|
|
/// AnalyzeGlobals - Scan through the users of all of the internal
|
2008-09-03 20:55:42 +08:00
|
|
|
/// GlobalValue's in the program. If none of them have their "address taken"
|
2004-06-28 14:33:13 +08:00
|
|
|
/// (really, their address passed to something nontrivial), record this fact,
|
|
|
|
/// and record the functions that they are used directly in.
|
[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
|
|
|
void GlobalsAAResult::AnalyzeGlobals(Module &M) {
|
2016-01-30 09:24:31 +08:00
|
|
|
SmallPtrSet<Function *, 32> TrackedFunctions;
|
2015-07-15 16:09:23 +08:00
|
|
|
for (Function &F : M)
|
2015-07-23 06:10:05 +08:00
|
|
|
if (F.hasLocalLinkage())
|
|
|
|
if (!AnalyzeUsesOfPointer(&F)) {
|
2004-07-27 14:40:37 +08:00
|
|
|
// Remember that we are tracking this global.
|
2015-07-15 16:09:23 +08:00
|
|
|
NonAddressTakenGlobals.insert(&F);
|
2015-07-28 14:01:57 +08:00
|
|
|
TrackedFunctions.insert(&F);
|
2015-07-22 17:27:58 +08:00
|
|
|
Handles.emplace_front(*this, &F);
|
|
|
|
Handles.front().I = Handles.begin();
|
2004-06-28 14:33:13 +08:00
|
|
|
++NumNonAddrTakenFunctions;
|
|
|
|
}
|
|
|
|
|
2016-01-30 09:24:31 +08:00
|
|
|
SmallPtrSet<Function *, 16> Readers, Writers;
|
2015-07-15 16:09:23 +08:00
|
|
|
for (GlobalVariable &GV : M.globals())
|
|
|
|
if (GV.hasLocalLinkage()) {
|
2015-07-23 06:10:05 +08:00
|
|
|
if (!AnalyzeUsesOfPointer(&GV, &Readers,
|
|
|
|
GV.isConstant() ? nullptr : &Writers)) {
|
2004-06-28 14:33:13 +08:00
|
|
|
// Remember that we are tracking this global, and the mod/ref fns
|
2015-07-15 16:09:23 +08:00
|
|
|
NonAddressTakenGlobals.insert(&GV);
|
2015-07-22 17:27:58 +08:00
|
|
|
Handles.emplace_front(*this, &GV);
|
|
|
|
Handles.front().I = Handles.begin();
|
2008-09-03 20:55:42 +08:00
|
|
|
|
2015-07-28 14:01:57 +08:00
|
|
|
for (Function *Reader : Readers) {
|
|
|
|
if (TrackedFunctions.insert(Reader).second) {
|
|
|
|
Handles.emplace_front(*this, Reader);
|
|
|
|
Handles.front().I = Handles.begin();
|
|
|
|
}
|
2017-12-08 06:41:34 +08:00
|
|
|
FunctionInfos[Reader].addModRefInfoForGlobal(GV, ModRefInfo::Ref);
|
2015-07-28 14:01:57 +08:00
|
|
|
}
|
2004-07-27 14:40:37 +08:00
|
|
|
|
2015-07-15 16:09:23 +08:00
|
|
|
if (!GV.isConstant()) // No need to keep track of writers to constants
|
2015-07-28 14:01:57 +08:00
|
|
|
for (Function *Writer : Writers) {
|
|
|
|
if (TrackedFunctions.insert(Writer).second) {
|
|
|
|
Handles.emplace_front(*this, Writer);
|
|
|
|
Handles.front().I = Handles.begin();
|
|
|
|
}
|
2017-12-08 06:41:34 +08:00
|
|
|
FunctionInfos[Writer].addModRefInfoForGlobal(GV, ModRefInfo::Mod);
|
2015-07-28 14:01:57 +08:00
|
|
|
}
|
2004-06-28 14:33:13 +08:00
|
|
|
++NumNonAddrTakenGlobalVars;
|
2008-09-03 20:55:42 +08:00
|
|
|
|
2006-10-02 06:36:45 +08:00
|
|
|
// If this global holds a pointer type, see if it is an indirect global.
|
2016-01-17 04:30:46 +08:00
|
|
|
if (GV.getValueType()->isPointerTy() &&
|
2015-07-15 16:09:23 +08:00
|
|
|
AnalyzeIndirectGlobalMemory(&GV))
|
2006-10-02 06:36:45 +08:00
|
|
|
++NumIndirectGlobalVars;
|
2004-06-28 14:33:13 +08:00
|
|
|
}
|
2015-07-14 16:42:39 +08:00
|
|
|
Readers.clear();
|
|
|
|
Writers.clear();
|
2004-06-28 14:33:13 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-10-02 06:36:45 +08:00
|
|
|
/// AnalyzeUsesOfPointer - Look at all of the users of the specified pointer.
|
|
|
|
/// If this is used by anything complex (i.e., the address escapes), return
|
|
|
|
/// true. Also, while we are at it, keep track of those functions that read and
|
|
|
|
/// write to the value.
|
|
|
|
///
|
|
|
|
/// If OkayStoreDest is non-null, stores into this global are allowed.
|
[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
|
|
|
bool GlobalsAAResult::AnalyzeUsesOfPointer(Value *V,
|
|
|
|
SmallPtrSetImpl<Function *> *Readers,
|
|
|
|
SmallPtrSetImpl<Function *> *Writers,
|
|
|
|
GlobalValue *OkayStoreDest) {
|
2015-07-14 16:42:39 +08:00
|
|
|
if (!V->getType()->isPointerTy())
|
|
|
|
return true;
|
2004-06-28 14:33:13 +08:00
|
|
|
|
2014-03-09 11:16:01 +08:00
|
|
|
for (Use &U : V->uses()) {
|
|
|
|
User *I = U.getUser();
|
|
|
|
if (LoadInst *LI = dyn_cast<LoadInst>(I)) {
|
2015-07-23 06:10:05 +08:00
|
|
|
if (Readers)
|
|
|
|
Readers->insert(LI->getParent()->getParent());
|
2014-03-09 11:16:01 +08:00
|
|
|
} else if (StoreInst *SI = dyn_cast<StoreInst>(I)) {
|
2006-10-02 06:36:45 +08:00
|
|
|
if (V == SI->getOperand(1)) {
|
2015-07-23 06:10:05 +08:00
|
|
|
if (Writers)
|
|
|
|
Writers->insert(SI->getParent()->getParent());
|
2006-10-02 06:36:45 +08:00
|
|
|
} else if (SI->getOperand(1) != OkayStoreDest) {
|
2015-07-14 16:42:39 +08:00
|
|
|
return true; // Storing the pointer
|
2006-10-02 06:36:45 +08:00
|
|
|
}
|
2014-03-09 11:16:01 +08:00
|
|
|
} else if (Operator::getOpcode(I) == Instruction::GetElementPtr) {
|
|
|
|
if (AnalyzeUsesOfPointer(I, Readers, Writers))
|
2009-09-19 05:34:51 +08:00
|
|
|
return true;
|
2014-03-09 11:16:01 +08:00
|
|
|
} else if (Operator::getOpcode(I) == Instruction::BitCast) {
|
|
|
|
if (AnalyzeUsesOfPointer(I, Readers, Writers, OkayStoreDest))
|
2014-02-10 22:17:30 +08:00
|
|
|
return true;
|
2015-04-10 22:50:08 +08:00
|
|
|
} else if (auto CS = CallSite(I)) {
|
2004-06-28 14:33:13 +08:00
|
|
|
// Make sure that this is just the function being called, not that it is
|
|
|
|
// passing into the function.
|
2015-12-23 17:58:46 +08:00
|
|
|
if (CS.isDataOperand(&U)) {
|
2014-02-10 22:17:30 +08:00
|
|
|
// Detect calls to free.
|
2015-12-23 17:58:46 +08:00
|
|
|
if (CS.isArgOperand(&U) && isFreeCall(I, &TLI)) {
|
2015-07-23 06:10:05 +08:00
|
|
|
if (Writers)
|
|
|
|
Writers->insert(CS->getParent()->getParent());
|
|
|
|
} else {
|
2014-02-10 22:17:30 +08:00
|
|
|
return true; // Argument of an unknown call.
|
2015-07-23 06:10:05 +08:00
|
|
|
}
|
2005-04-22 05:13:18 +08:00
|
|
|
}
|
2014-03-09 11:16:01 +08:00
|
|
|
} else if (ICmpInst *ICI = dyn_cast<ICmpInst>(I)) {
|
2006-12-23 14:05:41 +08:00
|
|
|
if (!isa<ConstantPointerNull>(ICI->getOperand(1)))
|
2015-07-14 16:42:39 +08:00
|
|
|
return true; // Allow comparison against null.
|
2016-10-04 08:03:55 +08:00
|
|
|
} else if (Constant *C = dyn_cast<Constant>(I)) {
|
2016-10-25 05:47:44 +08:00
|
|
|
// Ignore constants which don't have any live uses.
|
|
|
|
if (isa<GlobalValue>(C) || C->isConstantUsed())
|
|
|
|
return true;
|
2004-06-28 14:33:13 +08:00
|
|
|
} else {
|
|
|
|
return true;
|
|
|
|
}
|
2010-07-09 23:53:42 +08:00
|
|
|
}
|
|
|
|
|
2004-06-28 14:33:13 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2006-10-02 06:36:45 +08:00
|
|
|
/// AnalyzeIndirectGlobalMemory - We found an non-address-taken global variable
|
|
|
|
/// which holds a pointer type. See if the global always points to non-aliased
|
|
|
|
/// heap memory: that is, all initializers of the globals are allocations, and
|
|
|
|
/// those allocations have no use other than initialization of the global.
|
|
|
|
/// Further, all loads out of GV must directly use the memory, not store the
|
|
|
|
/// pointer somewhere. If this is true, we consider the memory pointed to by
|
|
|
|
/// GV to be owned by GV and can disambiguate other pointers from it.
|
2015-10-28 18:41:29 +08:00
|
|
|
bool GlobalsAAResult::AnalyzeIndirectGlobalMemory(GlobalVariable *GV) {
|
2006-10-02 06:36:45 +08:00
|
|
|
// Keep track of values related to the allocation of the memory, f.e. the
|
|
|
|
// value produced by the malloc call and any casts.
|
2015-07-14 16:42:39 +08:00
|
|
|
std::vector<Value *> AllocRelatedValues;
|
2008-09-03 20:55:42 +08:00
|
|
|
|
2015-10-28 18:41:29 +08:00
|
|
|
// If the initializer is a valid pointer, bail.
|
|
|
|
if (Constant *C = GV->getInitializer())
|
|
|
|
if (!C->isNullValue())
|
|
|
|
return false;
|
|
|
|
|
2006-10-02 06:36:45 +08:00
|
|
|
// Walk the user list of the global. If we find anything other than a direct
|
|
|
|
// load or store, bail out.
|
2014-03-09 11:16:01 +08:00
|
|
|
for (User *U : GV->users()) {
|
2010-07-10 00:22:36 +08:00
|
|
|
if (LoadInst *LI = dyn_cast<LoadInst>(U)) {
|
2006-10-02 06:36:45 +08:00
|
|
|
// The pointer loaded from the global can only be used in simple ways:
|
|
|
|
// we allow addressing of it and loading storing to it. We do *not* allow
|
|
|
|
// storing the loaded pointer somewhere else or passing to a function.
|
2015-07-23 06:10:05 +08:00
|
|
|
if (AnalyzeUsesOfPointer(LI))
|
2015-07-14 16:42:39 +08:00
|
|
|
return false; // Loaded pointer escapes.
|
2006-10-02 06:36:45 +08:00
|
|
|
// TODO: Could try some IP mod/ref of the loaded pointer.
|
2010-07-10 00:22:36 +08:00
|
|
|
} else if (StoreInst *SI = dyn_cast<StoreInst>(U)) {
|
2006-10-02 06:36:45 +08:00
|
|
|
// Storing the global itself.
|
2015-07-14 16:42:39 +08:00
|
|
|
if (SI->getOperand(0) == GV)
|
|
|
|
return false;
|
2008-09-03 20:55:42 +08:00
|
|
|
|
2006-10-02 06:36:45 +08:00
|
|
|
// If storing the null pointer, ignore it.
|
|
|
|
if (isa<ConstantPointerNull>(SI->getOperand(0)))
|
|
|
|
continue;
|
2008-09-03 20:55:42 +08:00
|
|
|
|
2006-10-02 06:36:45 +08:00
|
|
|
// Check the value being stored.
|
2015-03-10 10:37:25 +08:00
|
|
|
Value *Ptr = GetUnderlyingObject(SI->getOperand(0),
|
|
|
|
GV->getParent()->getDataLayout());
|
2006-10-02 06:36:45 +08: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-10 01:55:00 +08:00
|
|
|
if (!isAllocLikeFn(Ptr, &TLI))
|
2015-07-14 16:42:39 +08:00
|
|
|
return false; // Too hard to analyze.
|
2008-09-03 20:55:42 +08:00
|
|
|
|
2006-10-02 06:36:45 +08:00
|
|
|
// Analyze all uses of the allocation. If any of them are used in a
|
|
|
|
// non-simple way (e.g. stored to another global) bail out.
|
2015-07-23 06:10:05 +08:00
|
|
|
if (AnalyzeUsesOfPointer(Ptr, /*Readers*/ nullptr, /*Writers*/ nullptr,
|
|
|
|
GV))
|
2015-07-14 16:42:39 +08:00
|
|
|
return false; // Loaded pointer escapes.
|
2006-10-02 06:36:45 +08:00
|
|
|
|
|
|
|
// Remember that this allocation is related to the indirect global.
|
|
|
|
AllocRelatedValues.push_back(Ptr);
|
|
|
|
} else {
|
|
|
|
// Something complex, bail out.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
2008-09-03 20:55:42 +08:00
|
|
|
|
2006-10-02 06:36:45 +08:00
|
|
|
// Okay, this is an indirect global. Remember all of the allocations for
|
|
|
|
// this global in AllocsForIndirectGlobals.
|
|
|
|
while (!AllocRelatedValues.empty()) {
|
|
|
|
AllocsForIndirectGlobals[AllocRelatedValues.back()] = GV;
|
2015-07-22 17:27:58 +08:00
|
|
|
Handles.emplace_front(*this, AllocRelatedValues.back());
|
|
|
|
Handles.front().I = Handles.begin();
|
2006-10-02 06:36:45 +08:00
|
|
|
AllocRelatedValues.pop_back();
|
|
|
|
}
|
|
|
|
IndirectGlobals.insert(GV);
|
2015-07-22 17:27:58 +08:00
|
|
|
Handles.emplace_front(*this, GV);
|
|
|
|
Handles.front().I = Handles.begin();
|
2006-10-02 06:36:45 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
[GlobalsAA] Teach GlobalsAA about nocapture
Arguments to function calls marked "nocapture" can be marked as
non-escaping. However, nocapture is defined in terms of the lifetime
of the callee, and if the callee can directly or indirectly recurse to
the caller, the semantics of nocapture are invalid.
Therefore, we eagerly discover which SCC each function belongs to,
and later can check if callee and caller of a callsite belong to
the same SCC, in which case there could be recursion.
This means that we can't be so optimistic in
getModRefInfo(ImmutableCallsite) - previously we assumed all call
arguments never aliased with an escaping global. Now we need to check,
because a global could now be passed as an argument but still not
escape.
This also solves a related conformance problem: MemCpyOptimizer can
turn non-escaping stores of globals into calls to intrinsics like
llvm.memcpy/llvm/memset. This confuses GlobalsAA, which knows the
global can't escape and so returns NoModRef when queried, when
obviously a memcpy/memset call does indeed reference and modify its
arguments.
This fixes PR24800, PR24801, and PR24802.
llvm-svn: 248576
2015-09-25 23:39:29 +08:00
|
|
|
void GlobalsAAResult::CollectSCCMembership(CallGraph &CG) {
|
|
|
|
// We do a bottom-up SCC traversal of the call graph. In other words, we
|
|
|
|
// visit all callees before callers (leaf-first).
|
|
|
|
unsigned SCCID = 0;
|
|
|
|
for (scc_iterator<CallGraph *> I = scc_begin(&CG); !I.isAtEnd(); ++I) {
|
|
|
|
const std::vector<CallGraphNode *> &SCC = *I;
|
|
|
|
assert(!SCC.empty() && "SCC with no functions?");
|
|
|
|
|
|
|
|
for (auto *CGN : SCC)
|
|
|
|
if (Function *F = CGN->getFunction())
|
|
|
|
FunctionToSCCMap[F] = SCCID;
|
|
|
|
++SCCID;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2004-06-28 14:33:13 +08:00
|
|
|
/// AnalyzeCallGraph - At this point, we know the functions where globals are
|
|
|
|
/// immediately stored to and read from. Propagate this information up the call
|
2004-07-27 14:40:37 +08:00
|
|
|
/// graph to all callers and compute the mod/ref info for all memory for each
|
2005-04-22 05:13:18 +08:00
|
|
|
/// 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-10 01:55:00 +08:00
|
|
|
void GlobalsAAResult::AnalyzeCallGraph(CallGraph &CG, Module &M) {
|
2004-06-28 14:33:13 +08:00
|
|
|
// We do a bottom-up SCC traversal of the call graph. In other words, we
|
|
|
|
// visit all callees before callers (leaf-first).
|
2015-07-14 16:42:39 +08:00
|
|
|
for (scc_iterator<CallGraph *> I = scc_begin(&CG); !I.isAtEnd(); ++I) {
|
2014-04-26 02:24:50 +08:00
|
|
|
const std::vector<CallGraphNode *> &SCC = *I;
|
2008-09-05 03:16:20 +08:00
|
|
|
assert(!SCC.empty() && "SCC with no functions?");
|
2008-09-03 20:55:42 +08:00
|
|
|
|
2017-06-07 04:51:15 +08:00
|
|
|
Function *F = SCC[0]->getFunction();
|
|
|
|
|
2017-06-08 05:37:39 +08:00
|
|
|
if (!F || !F->isDefinitionExact()) {
|
Don't IPO over functions that can be de-refined
Summary:
Fixes PR26774.
If you're aware of the issue, feel free to skip the "Motivation"
section and jump directly to "This patch".
Motivation:
I define "refinement" as discarding behaviors from a program that the
optimizer has license to discard. So transforming:
```
void f(unsigned x) {
unsigned t = 5 / x;
(void)t;
}
```
to
```
void f(unsigned x) { }
```
is refinement, since the behavior went from "if x == 0 then undefined
else nothing" to "nothing" (the optimizer has license to discard
undefined behavior).
Refinement is a fundamental aspect of many mid-level optimizations done
by LLVM. For instance, transforming `x == (x + 1)` to `false` also
involves refinement since the expression's value went from "if x is
`undef` then { `true` or `false` } else { `false` }" to "`false`" (by
definition, the optimizer has license to fold `undef` to any non-`undef`
value).
Unfortunately, refinement implies that the optimizer cannot assume
that the implementation of a function it can see has all of the
behavior an unoptimized or a differently optimized version of the same
function can have. This is a problem for functions with comdat
linkage, where a function can be replaced by an unoptimized or a
differently optimized version of the same source level function.
For instance, FunctionAttrs cannot assume a comdat function is
actually `readnone` even if it does not have any loads or stores in
it; since there may have been loads and stores in the "original
function" that were refined out in the currently visible variant, and
at the link step the linker may in fact choose an implementation with
a load or a store. As an example, consider a function that does two
atomic loads from the same memory location, and writes to memory only
if the two values are not equal. The optimizer is allowed to refine
this function by first CSE'ing the two loads, and the folding the
comparision to always report that the two values are equal. Such a
refined variant will look like it is `readonly`. However, the
unoptimized version of the function can still write to memory (since
the two loads //can// result in different values), and selecting the
unoptimized version at link time will retroactively invalidate
transforms we may have done under the assumption that the function
does not write to memory.
Note: this is not just a problem with atomics or with linking
differently optimized object files. See PR26774 for more realistic
examples that involved neither.
This patch:
This change introduces a new set of linkage types, predicated as
`GlobalValue::mayBeDerefined` that returns true if the linkage type
allows a function to be replaced by a differently optimized variant at
link time. It then changes a set of IPO passes to bail out if they see
such a function.
Reviewers: chandlerc, hfinkel, dexonsmith, joker.eph, rnk
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D18634
llvm-svn: 265762
2016-04-08 08:48:30 +08:00
|
|
|
// Calls externally or not exact - can't say anything useful. Remove any
|
|
|
|
// existing function records (may have been created when scanning
|
|
|
|
// globals).
|
2015-07-15 16:09:23 +08:00
|
|
|
for (auto *Node : SCC)
|
2015-07-23 07:56:31 +08:00
|
|
|
FunctionInfos.erase(Node->getFunction());
|
2008-09-04 03:37:16 +08:00
|
|
|
continue;
|
2008-09-05 03:16:20 +08:00
|
|
|
}
|
|
|
|
|
2017-06-07 04:51:15 +08:00
|
|
|
FunctionInfo &FI = FunctionInfos[F];
|
2008-09-03 20:55:42 +08:00
|
|
|
bool KnowNothing = false;
|
|
|
|
|
|
|
|
// Collect the mod/ref properties due to called functions. We only compute
|
|
|
|
// one mod-ref set.
|
|
|
|
for (unsigned i = 0, e = SCC.size(); i != e && !KnowNothing; ++i) {
|
|
|
|
if (!F) {
|
|
|
|
KnowNothing = true;
|
2004-07-27 14:40:37 +08:00
|
|
|
break;
|
2004-06-28 14:33:13 +08:00
|
|
|
}
|
2004-07-27 14:40:37 +08:00
|
|
|
|
2017-06-08 05:37:39 +08:00
|
|
|
if (F->isDeclaration() || F->hasFnAttribute(Attribute::OptimizeNone)) {
|
2008-09-03 20:55:42 +08:00
|
|
|
// Try to get mod/ref behaviour from function attributes.
|
2016-01-06 21:23:52 +08:00
|
|
|
if (F->doesNotAccessMemory()) {
|
2008-09-03 23:31:24 +08:00
|
|
|
// Can't do better than that!
|
|
|
|
} else if (F->onlyReadsMemory()) {
|
2017-12-08 06:41:34 +08:00
|
|
|
FI.addModRefInfo(ModRefInfo::Ref);
|
2016-07-14 23:50:27 +08:00
|
|
|
if (!F->isIntrinsic() && !F->onlyAccessesArgMemory())
|
2008-09-11 23:43:12 +08:00
|
|
|
// This function might call back into the module and read a global -
|
2008-09-12 15:29:58 +08:00
|
|
|
// consider every global as possibly being read by this function.
|
2015-07-23 07:56:31 +08:00
|
|
|
FI.setMayReadAnyGlobal();
|
2008-09-03 23:31:24 +08:00
|
|
|
} else {
|
2017-12-08 06:41:34 +08:00
|
|
|
FI.addModRefInfo(ModRefInfo::ModRef);
|
2008-09-12 03:35:55 +08:00
|
|
|
// Can't say anything useful unless it's an intrinsic - they don't
|
|
|
|
// read or write global variables of the kind considered here.
|
|
|
|
KnowNothing = !F->isIntrinsic();
|
2008-09-03 20:55:42 +08:00
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (CallGraphNode::iterator CI = SCC[i]->begin(), E = SCC[i]->end();
|
2008-09-05 03:16:20 +08:00
|
|
|
CI != E && !KnowNothing; ++CI)
|
2008-09-03 20:55:42 +08:00
|
|
|
if (Function *Callee = CI->second->getFunction()) {
|
2015-07-23 07:56:31 +08:00
|
|
|
if (FunctionInfo *CalleeFI = getFunctionInfo(Callee)) {
|
2008-09-03 20:55:42 +08:00
|
|
|
// Propagate function effect up.
|
2015-07-23 08:12:32 +08:00
|
|
|
FI.addFunctionInfo(*CalleeFI);
|
2008-09-03 20:55:42 +08:00
|
|
|
} else {
|
|
|
|
// Can't say anything about it. However, if it is inside our SCC,
|
|
|
|
// then nothing needs to be done.
|
|
|
|
CallGraphNode *CalleeNode = CG[Callee];
|
2016-08-12 06:21:41 +08:00
|
|
|
if (!is_contained(SCC, CalleeNode))
|
2008-09-03 20:55:42 +08:00
|
|
|
KnowNothing = true;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
KnowNothing = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we can't say anything useful about this SCC, remove all SCC functions
|
2015-07-23 07:56:31 +08:00
|
|
|
// from the FunctionInfos map.
|
2008-09-03 20:55:42 +08:00
|
|
|
if (KnowNothing) {
|
2015-07-15 16:09:23 +08:00
|
|
|
for (auto *Node : SCC)
|
2015-07-23 07:56:31 +08:00
|
|
|
FunctionInfos.erase(Node->getFunction());
|
2008-09-04 00:10:55 +08:00
|
|
|
continue;
|
2008-09-03 20:55:42 +08:00
|
|
|
}
|
2005-04-22 05:13:18 +08:00
|
|
|
|
2008-09-03 20:55:42 +08:00
|
|
|
// Scan the function bodies for explicit loads or stores.
|
2015-07-15 16:53:29 +08:00
|
|
|
for (auto *Node : SCC) {
|
2017-12-06 04:12:23 +08:00
|
|
|
if (isModAndRefSet(FI.getModRefInfo()))
|
2015-07-15 16:53:29 +08:00
|
|
|
break; // The mod/ref lattice saturates here.
|
2017-06-07 04:51:15 +08:00
|
|
|
|
|
|
|
// Don't prove any properties based on the implementation of an optnone
|
2017-06-08 05:37:39 +08:00
|
|
|
// function. Function attributes were already used as a best approximation
|
|
|
|
// above.
|
|
|
|
if (Node->getFunction()->hasFnAttribute(Attribute::OptimizeNone))
|
2017-06-07 04:51:15 +08:00
|
|
|
continue;
|
|
|
|
|
2015-08-07 03:10:45 +08:00
|
|
|
for (Instruction &I : instructions(Node->getFunction())) {
|
2017-12-06 04:12:23 +08:00
|
|
|
if (isModAndRefSet(FI.getModRefInfo()))
|
2015-07-15 16:53:29 +08:00
|
|
|
break; // The mod/ref lattice saturates here.
|
|
|
|
|
|
|
|
// We handle calls specially because the graph-relevant aspects are
|
|
|
|
// handled above.
|
|
|
|
if (auto CS = CallSite(&I)) {
|
[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
|
|
|
if (isAllocationFn(&I, &TLI) || isFreeCall(&I, &TLI)) {
|
2015-07-15 16:53:29 +08:00
|
|
|
// FIXME: It is completely unclear why this is necessary and not
|
|
|
|
// handled by the above graph code.
|
2017-12-08 06:41:34 +08:00
|
|
|
FI.addModRefInfo(ModRefInfo::ModRef);
|
2015-07-15 16:53:29 +08:00
|
|
|
} else if (Function *Callee = CS.getCalledFunction()) {
|
|
|
|
// The callgraph doesn't include intrinsic calls.
|
|
|
|
if (Callee->isIntrinsic()) {
|
2015-07-23 07:15:57 +08:00
|
|
|
FunctionModRefBehavior Behaviour =
|
[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
|
|
|
AAResultBase::getModRefBehavior(Callee);
|
2017-12-07 08:43:19 +08:00
|
|
|
FI.addModRefInfo(createModRefInfo(Behaviour));
|
2015-07-15 16:53:29 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// All non-call instructions we use the primary predicates for whether
|
|
|
|
// thay read or write memory.
|
|
|
|
if (I.mayReadFromMemory())
|
2017-12-08 06:41:34 +08:00
|
|
|
FI.addModRefInfo(ModRefInfo::Ref);
|
2015-07-15 16:53:29 +08:00
|
|
|
if (I.mayWriteToMemory())
|
2017-12-08 06:41:34 +08:00
|
|
|
FI.addModRefInfo(ModRefInfo::Mod);
|
2015-07-15 16:53:29 +08:00
|
|
|
}
|
|
|
|
}
|
2004-07-27 14:40:37 +08:00
|
|
|
|
2017-12-06 04:12:23 +08:00
|
|
|
if (!isModSet(FI.getModRefInfo()))
|
2008-09-03 20:55:42 +08:00
|
|
|
++NumReadMemFunctions;
|
2017-12-06 04:12:23 +08:00
|
|
|
if (!isModOrRefSet(FI.getModRefInfo()))
|
2008-09-03 20:55:42 +08:00
|
|
|
++NumNoMemFunctions;
|
2004-07-27 14:40:37 +08:00
|
|
|
|
2008-09-03 20:55:42 +08:00
|
|
|
// Finally, now that we know the full effect on this SCC, clone the
|
|
|
|
// information to each function in the SCC.
|
2015-10-19 16:54:59 +08:00
|
|
|
// FI is a reference into FunctionInfos, so copy it now so that it doesn't
|
|
|
|
// get invalidated if DenseMap decides to re-hash.
|
|
|
|
FunctionInfo CachedFI = FI;
|
2008-09-03 20:55:42 +08:00
|
|
|
for (unsigned i = 1, e = SCC.size(); i != e; ++i)
|
2015-10-19 16:54:59 +08:00
|
|
|
FunctionInfos[SCC[i]->getFunction()] = CachedFI;
|
2008-09-03 20:55:42 +08:00
|
|
|
}
|
2004-06-28 14:33:13 +08:00
|
|
|
}
|
|
|
|
|
2015-10-22 21:44:26 +08:00
|
|
|
// GV is a non-escaping global. V is a pointer address that has been loaded from.
|
|
|
|
// If we can prove that V must escape, we can conclude that a load from V cannot
|
|
|
|
// alias GV.
|
|
|
|
static bool isNonEscapingGlobalNoAliasWithLoad(const GlobalValue *GV,
|
|
|
|
const Value *V,
|
|
|
|
int &Depth,
|
|
|
|
const DataLayout &DL) {
|
|
|
|
SmallPtrSet<const Value *, 8> Visited;
|
|
|
|
SmallVector<const Value *, 8> Inputs;
|
|
|
|
Visited.insert(V);
|
|
|
|
Inputs.push_back(V);
|
|
|
|
do {
|
|
|
|
const Value *Input = Inputs.pop_back_val();
|
|
|
|
|
|
|
|
if (isa<GlobalValue>(Input) || isa<Argument>(Input) || isa<CallInst>(Input) ||
|
|
|
|
isa<InvokeInst>(Input))
|
|
|
|
// Arguments to functions or returns from functions are inherently
|
|
|
|
// escaping, so we can immediately classify those as not aliasing any
|
|
|
|
// non-addr-taken globals.
|
|
|
|
//
|
|
|
|
// (Transitive) loads from a global are also safe - if this aliased
|
|
|
|
// another global, its address would escape, so no alias.
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Recurse through a limited number of selects, loads and PHIs. This is an
|
|
|
|
// arbitrary depth of 4, lower numbers could be used to fix compile time
|
|
|
|
// issues if needed, but this is generally expected to be only be important
|
|
|
|
// for small depths.
|
|
|
|
if (++Depth > 4)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (auto *LI = dyn_cast<LoadInst>(Input)) {
|
|
|
|
Inputs.push_back(GetUnderlyingObject(LI->getPointerOperand(), DL));
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (auto *SI = dyn_cast<SelectInst>(Input)) {
|
|
|
|
const Value *LHS = GetUnderlyingObject(SI->getTrueValue(), DL);
|
|
|
|
const Value *RHS = GetUnderlyingObject(SI->getFalseValue(), DL);
|
|
|
|
if (Visited.insert(LHS).second)
|
|
|
|
Inputs.push_back(LHS);
|
|
|
|
if (Visited.insert(RHS).second)
|
|
|
|
Inputs.push_back(RHS);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (auto *PN = dyn_cast<PHINode>(Input)) {
|
|
|
|
for (const Value *Op : PN->incoming_values()) {
|
|
|
|
Op = GetUnderlyingObject(Op, DL);
|
|
|
|
if (Visited.insert(Op).second)
|
|
|
|
Inputs.push_back(Op);
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
} while (!Inputs.empty());
|
|
|
|
|
|
|
|
// All inputs were known to be no-alias.
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-08-06 01:58:30 +08:00
|
|
|
// There are particular cases where we can conclude no-alias between
|
|
|
|
// a non-addr-taken global and some other underlying object. Specifically,
|
|
|
|
// a non-addr-taken global is known to not be escaped from any function. It is
|
|
|
|
// also incorrect for a transformation to introduce an escape of a global in
|
|
|
|
// a way that is observable when it was not there previously. One function
|
|
|
|
// being transformed to introduce an escape which could possibly be observed
|
|
|
|
// (via loading from a global or the return value for example) within another
|
|
|
|
// function is never safe. If the observation is made through non-atomic
|
|
|
|
// operations on different threads, it is a data-race and UB. If the
|
|
|
|
// observation is well defined, by being observed the transformation would have
|
|
|
|
// changed program behavior by introducing the observed escape, making it an
|
|
|
|
// invalid transform.
|
|
|
|
//
|
|
|
|
// This property does require that transformations which *temporarily* escape
|
|
|
|
// a global that was not previously escaped, prior to restoring it, cannot rely
|
|
|
|
// on the results of GMR::alias. This seems a reasonable restriction, although
|
|
|
|
// currently there is no way to enforce it. There is also no realistic
|
|
|
|
// optimization pass that would make this mistake. The closest example is
|
|
|
|
// a transformation pass which does reg2mem of SSA values but stores them into
|
|
|
|
// global variables temporarily before restoring the global variable's value.
|
|
|
|
// This could be useful to expose "benign" races for example. However, it seems
|
|
|
|
// reasonable to require that a pass which introduces escapes of global
|
|
|
|
// variables in this way to either not trust AA results while the escape is
|
|
|
|
// active, or to be forced to operate as a module pass that cannot co-exist
|
|
|
|
// with an alias analysis such as GMR.
|
[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
|
|
|
bool GlobalsAAResult::isNonEscapingGlobalNoAlias(const GlobalValue *GV,
|
|
|
|
const Value *V) {
|
2015-08-06 01:58:30 +08:00
|
|
|
// In order to know that the underlying object cannot alias the
|
|
|
|
// non-addr-taken global, we must know that it would have to be an escape.
|
|
|
|
// Thus if the underlying object is a function argument, a load from
|
|
|
|
// a global, or the return of a function, it cannot alias. We can also
|
|
|
|
// recurse through PHI nodes and select nodes provided all of their inputs
|
|
|
|
// resolve to one of these known-escaping roots.
|
|
|
|
SmallPtrSet<const Value *, 8> Visited;
|
|
|
|
SmallVector<const Value *, 8> Inputs;
|
|
|
|
Visited.insert(V);
|
|
|
|
Inputs.push_back(V);
|
|
|
|
int Depth = 0;
|
|
|
|
do {
|
|
|
|
const Value *Input = Inputs.pop_back_val();
|
|
|
|
|
|
|
|
if (auto *InputGV = dyn_cast<GlobalValue>(Input)) {
|
|
|
|
// If one input is the very global we're querying against, then we can't
|
|
|
|
// conclude no-alias.
|
|
|
|
if (InputGV == GV)
|
|
|
|
return false;
|
|
|
|
|
2015-08-11 16:06:44 +08:00
|
|
|
// Distinct GlobalVariables never alias, unless overriden or zero-sized.
|
|
|
|
// FIXME: The condition can be refined, but be conservative for now.
|
|
|
|
auto *GVar = dyn_cast<GlobalVariable>(GV);
|
|
|
|
auto *InputGVar = dyn_cast<GlobalVariable>(InputGV);
|
|
|
|
if (GVar && InputGVar &&
|
|
|
|
!GVar->isDeclaration() && !InputGVar->isDeclaration() &&
|
Don't IPO over functions that can be de-refined
Summary:
Fixes PR26774.
If you're aware of the issue, feel free to skip the "Motivation"
section and jump directly to "This patch".
Motivation:
I define "refinement" as discarding behaviors from a program that the
optimizer has license to discard. So transforming:
```
void f(unsigned x) {
unsigned t = 5 / x;
(void)t;
}
```
to
```
void f(unsigned x) { }
```
is refinement, since the behavior went from "if x == 0 then undefined
else nothing" to "nothing" (the optimizer has license to discard
undefined behavior).
Refinement is a fundamental aspect of many mid-level optimizations done
by LLVM. For instance, transforming `x == (x + 1)` to `false` also
involves refinement since the expression's value went from "if x is
`undef` then { `true` or `false` } else { `false` }" to "`false`" (by
definition, the optimizer has license to fold `undef` to any non-`undef`
value).
Unfortunately, refinement implies that the optimizer cannot assume
that the implementation of a function it can see has all of the
behavior an unoptimized or a differently optimized version of the same
function can have. This is a problem for functions with comdat
linkage, where a function can be replaced by an unoptimized or a
differently optimized version of the same source level function.
For instance, FunctionAttrs cannot assume a comdat function is
actually `readnone` even if it does not have any loads or stores in
it; since there may have been loads and stores in the "original
function" that were refined out in the currently visible variant, and
at the link step the linker may in fact choose an implementation with
a load or a store. As an example, consider a function that does two
atomic loads from the same memory location, and writes to memory only
if the two values are not equal. The optimizer is allowed to refine
this function by first CSE'ing the two loads, and the folding the
comparision to always report that the two values are equal. Such a
refined variant will look like it is `readonly`. However, the
unoptimized version of the function can still write to memory (since
the two loads //can// result in different values), and selecting the
unoptimized version at link time will retroactively invalidate
transforms we may have done under the assumption that the function
does not write to memory.
Note: this is not just a problem with atomics or with linking
differently optimized object files. See PR26774 for more realistic
examples that involved neither.
This patch:
This change introduces a new set of linkage types, predicated as
`GlobalValue::mayBeDerefined` that returns true if the linkage type
allows a function to be replaced by a differently optimized variant at
link time. It then changes a set of IPO passes to bail out if they see
such a function.
Reviewers: chandlerc, hfinkel, dexonsmith, joker.eph, rnk
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D18634
llvm-svn: 265762
2016-04-08 08:48:30 +08:00
|
|
|
!GVar->isInterposable() && !InputGVar->isInterposable()) {
|
2015-08-11 16:06:44 +08:00
|
|
|
Type *GVType = GVar->getInitializer()->getType();
|
|
|
|
Type *InputGVType = InputGVar->getInitializer()->getType();
|
|
|
|
if (GVType->isSized() && InputGVType->isSized() &&
|
[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
|
|
|
(DL.getTypeAllocSize(GVType) > 0) &&
|
|
|
|
(DL.getTypeAllocSize(InputGVType) > 0))
|
2015-08-11 16:06:44 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Conservatively return false, even though we could be smarter
|
|
|
|
// (e.g. look through GlobalAliases).
|
2015-08-06 01:58:30 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (isa<Argument>(Input) || isa<CallInst>(Input) ||
|
|
|
|
isa<InvokeInst>(Input)) {
|
|
|
|
// Arguments to functions or returns from functions are inherently
|
|
|
|
// escaping, so we can immediately classify those as not aliasing any
|
|
|
|
// non-addr-taken globals.
|
|
|
|
continue;
|
|
|
|
}
|
2015-10-22 21:44:26 +08:00
|
|
|
|
|
|
|
// Recurse through a limited number of selects, loads and PHIs. This is an
|
|
|
|
// arbitrary depth of 4, lower numbers could be used to fix compile time
|
|
|
|
// issues if needed, but this is generally expected to be only be important
|
|
|
|
// for small depths.
|
|
|
|
if (++Depth > 4)
|
|
|
|
return false;
|
|
|
|
|
2015-08-06 01:58:30 +08:00
|
|
|
if (auto *LI = dyn_cast<LoadInst>(Input)) {
|
|
|
|
// A pointer loaded from a global would have been captured, and we know
|
|
|
|
// that the global is non-escaping, so no alias.
|
2015-10-22 21:44:26 +08:00
|
|
|
const Value *Ptr = GetUnderlyingObject(LI->getPointerOperand(), DL);
|
|
|
|
if (isNonEscapingGlobalNoAliasWithLoad(GV, Ptr, Depth, DL))
|
|
|
|
// The load does not alias with GV.
|
2015-08-06 01:58:30 +08:00
|
|
|
continue;
|
|
|
|
// Otherwise, a load could come from anywhere, so bail.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (auto *SI = dyn_cast<SelectInst>(Input)) {
|
[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
|
|
|
const Value *LHS = GetUnderlyingObject(SI->getTrueValue(), DL);
|
|
|
|
const Value *RHS = GetUnderlyingObject(SI->getFalseValue(), DL);
|
2015-08-06 01:58:30 +08:00
|
|
|
if (Visited.insert(LHS).second)
|
|
|
|
Inputs.push_back(LHS);
|
|
|
|
if (Visited.insert(RHS).second)
|
|
|
|
Inputs.push_back(RHS);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (auto *PN = dyn_cast<PHINode>(Input)) {
|
|
|
|
for (const Value *Op : PN->incoming_values()) {
|
[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
|
|
|
Op = GetUnderlyingObject(Op, DL);
|
2015-08-06 01:58:30 +08:00
|
|
|
if (Visited.insert(Op).second)
|
|
|
|
Inputs.push_back(Op);
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2015-08-11 16:06:44 +08:00
|
|
|
// FIXME: It would be good to handle other obvious no-alias cases here, but
|
|
|
|
// it isn't clear how to do so reasonbly without building a small version
|
[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
|
|
|
// of BasicAA into this code. We could recurse into AAResultBase::alias
|
2015-08-11 16:06:44 +08:00
|
|
|
// here but that seems likely to go poorly as we're inside the
|
|
|
|
// implementation of such a query. Until then, just conservatievly retun
|
|
|
|
// false.
|
2015-08-06 01:58:30 +08:00
|
|
|
return false;
|
|
|
|
} while (!Inputs.empty());
|
|
|
|
|
|
|
|
// If all the inputs to V were definitively no-alias, then V is no-alias.
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2004-06-28 14:33:13 +08:00
|
|
|
/// alias - If one of the pointers is to a global that we are tracking, and the
|
|
|
|
/// other is some random pointer, we know there cannot be an alias, because the
|
|
|
|
/// address of the global isn't taken.
|
[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
|
|
|
AliasResult GlobalsAAResult::alias(const MemoryLocation &LocA,
|
|
|
|
const MemoryLocation &LocB) {
|
2006-10-02 06:36:45 +08:00
|
|
|
// Get the base object these pointers point to.
|
[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
|
|
|
const Value *UV1 = GetUnderlyingObject(LocA.Ptr, DL);
|
|
|
|
const Value *UV2 = GetUnderlyingObject(LocB.Ptr, DL);
|
2008-09-03 20:55:42 +08:00
|
|
|
|
2006-10-02 06:36:45 +08:00
|
|
|
// If either of the underlying values is a global, they may be non-addr-taken
|
|
|
|
// globals, which we can answer queries about.
|
2010-08-04 05:48:53 +08:00
|
|
|
const GlobalValue *GV1 = dyn_cast<GlobalValue>(UV1);
|
|
|
|
const GlobalValue *GV2 = dyn_cast<GlobalValue>(UV2);
|
2006-10-02 06:36:45 +08:00
|
|
|
if (GV1 || GV2) {
|
|
|
|
// If the global's address is taken, pretend we don't know it's a pointer to
|
|
|
|
// the global.
|
2015-07-14 16:42:39 +08:00
|
|
|
if (GV1 && !NonAddressTakenGlobals.count(GV1))
|
|
|
|
GV1 = nullptr;
|
|
|
|
if (GV2 && !NonAddressTakenGlobals.count(GV2))
|
|
|
|
GV2 = nullptr;
|
2006-10-02 06:36:45 +08:00
|
|
|
|
2010-02-11 00:03:48 +08:00
|
|
|
// If the two pointers are derived from two different non-addr-taken
|
[PM/AA] Disable the core unsafe aspect of GlobalsModRef in the face of
basic changes to the IR such as folding pointers through PHIs, Selects,
integer casts, store/load pairs, or outlining.
This leaves the feature available behind a flag. This flag's default
could be flipped if necessary, but the real-world performance impact of
this particular feature of GMR may not be sufficiently significant for
many folks to want to run the risk.
Currently, the risk here is somewhat mitigated by half-hearted attempts
to update GlobalsModRef when the rest of the optimizer changes
something. However, I am currently trying to remove that update
mechanism as it makes migrating the AA infrastructure to a form that can
be readily shared between new and old pass managers very challenging.
Without this update mechanism, it is possible that this still unlikely
failure mode will start to trip people, and so I wanted to try to
proactively avoid that.
There is a lengthy discussion on the mailing list about why the core
approach here is flawed, and likely would need to look totally different
to be both reasonably effective and resilient to basic IR changes
occuring. This patch is essentially the first of two which will enact
the result of that discussion. The next patch will remove the current
update mechanism.
Thanks to lots of folks that helped look at this from different angles.
Especial thanks to Michael Zolotukhin for doing some very prelimanary
benchmarking of LTO without GlobalsModRef to get a rough idea of the
impact we could be facing here. So far, it looks very small, but there
are some concerns lingering from other benchmarking. The default here
may get flipped if performance results end up pointing at this as a more
significant issue.
Also thanks to Pete and Gerolf for reviewing!
Differential Revision: http://reviews.llvm.org/D11213
llvm-svn: 242512
2015-07-17 14:58:24 +08:00
|
|
|
// globals we know these can't alias.
|
|
|
|
if (GV1 && GV2 && GV1 != GV2)
|
2006-10-02 06:36:45 +08:00
|
|
|
return NoAlias;
|
|
|
|
|
[PM/AA] Disable the core unsafe aspect of GlobalsModRef in the face of
basic changes to the IR such as folding pointers through PHIs, Selects,
integer casts, store/load pairs, or outlining.
This leaves the feature available behind a flag. This flag's default
could be flipped if necessary, but the real-world performance impact of
this particular feature of GMR may not be sufficiently significant for
many folks to want to run the risk.
Currently, the risk here is somewhat mitigated by half-hearted attempts
to update GlobalsModRef when the rest of the optimizer changes
something. However, I am currently trying to remove that update
mechanism as it makes migrating the AA infrastructure to a form that can
be readily shared between new and old pass managers very challenging.
Without this update mechanism, it is possible that this still unlikely
failure mode will start to trip people, and so I wanted to try to
proactively avoid that.
There is a lengthy discussion on the mailing list about why the core
approach here is flawed, and likely would need to look totally different
to be both reasonably effective and resilient to basic IR changes
occuring. This patch is essentially the first of two which will enact
the result of that discussion. The next patch will remove the current
update mechanism.
Thanks to lots of folks that helped look at this from different angles.
Especial thanks to Michael Zolotukhin for doing some very prelimanary
benchmarking of LTO without GlobalsModRef to get a rough idea of the
impact we could be facing here. So far, it looks very small, but there
are some concerns lingering from other benchmarking. The default here
may get flipped if performance results end up pointing at this as a more
significant issue.
Also thanks to Pete and Gerolf for reviewing!
Differential Revision: http://reviews.llvm.org/D11213
llvm-svn: 242512
2015-07-17 14:58:24 +08:00
|
|
|
// If one is and the other isn't, it isn't strictly safe but we can fake
|
|
|
|
// this result if necessary for performance. This does not appear to be
|
|
|
|
// a common problem in practice.
|
|
|
|
if (EnableUnsafeGlobalsModRefAliasResults)
|
|
|
|
if ((GV1 || GV2) && GV1 != GV2)
|
|
|
|
return NoAlias;
|
|
|
|
|
2015-08-06 01:58:30 +08:00
|
|
|
// Check for a special case where a non-escaping global can be used to
|
|
|
|
// conclude no-alias.
|
2015-07-28 19:11:11 +08:00
|
|
|
if ((GV1 || GV2) && GV1 != GV2) {
|
2015-08-06 01:58:30 +08:00
|
|
|
const GlobalValue *GV = GV1 ? GV1 : GV2;
|
2015-07-28 19:11:11 +08:00
|
|
|
const Value *UV = GV1 ? UV2 : UV1;
|
2015-08-06 01:58:30 +08:00
|
|
|
if (isNonEscapingGlobalNoAlias(GV, UV))
|
2015-07-28 19:11:11 +08:00
|
|
|
return NoAlias;
|
|
|
|
}
|
|
|
|
|
2006-10-02 06:36:45 +08:00
|
|
|
// Otherwise if they are both derived from the same addr-taken global, we
|
|
|
|
// can't know the two accesses don't overlap.
|
|
|
|
}
|
2008-09-03 20:55:42 +08:00
|
|
|
|
2006-10-02 06:36:45 +08:00
|
|
|
// These pointers may be based on the memory owned by an indirect global. If
|
|
|
|
// so, we may be able to handle this. First check to see if the base pointer
|
|
|
|
// is a direct load from an indirect global.
|
2014-04-24 14:44:33 +08:00
|
|
|
GV1 = GV2 = nullptr;
|
2010-08-04 05:48:53 +08:00
|
|
|
if (const LoadInst *LI = dyn_cast<LoadInst>(UV1))
|
2006-10-02 06:36:45 +08:00
|
|
|
if (GlobalVariable *GV = dyn_cast<GlobalVariable>(LI->getOperand(0)))
|
|
|
|
if (IndirectGlobals.count(GV))
|
|
|
|
GV1 = GV;
|
2010-08-04 05:48:53 +08:00
|
|
|
if (const LoadInst *LI = dyn_cast<LoadInst>(UV2))
|
|
|
|
if (const GlobalVariable *GV = dyn_cast<GlobalVariable>(LI->getOperand(0)))
|
2006-10-02 06:36:45 +08:00
|
|
|
if (IndirectGlobals.count(GV))
|
|
|
|
GV2 = GV;
|
2008-09-03 20:55:42 +08:00
|
|
|
|
2006-10-02 06:36:45 +08:00
|
|
|
// These pointers may also be from an allocation for the indirect global. If
|
|
|
|
// so, also handle them.
|
2015-07-22 19:43:24 +08:00
|
|
|
if (!GV1)
|
|
|
|
GV1 = AllocsForIndirectGlobals.lookup(UV1);
|
|
|
|
if (!GV2)
|
|
|
|
GV2 = AllocsForIndirectGlobals.lookup(UV2);
|
2008-09-03 20:55:42 +08:00
|
|
|
|
2006-10-02 06:36:45 +08:00
|
|
|
// Now that we know whether the two pointers are related to indirect globals,
|
[PM/AA] Disable the core unsafe aspect of GlobalsModRef in the face of
basic changes to the IR such as folding pointers through PHIs, Selects,
integer casts, store/load pairs, or outlining.
This leaves the feature available behind a flag. This flag's default
could be flipped if necessary, but the real-world performance impact of
this particular feature of GMR may not be sufficiently significant for
many folks to want to run the risk.
Currently, the risk here is somewhat mitigated by half-hearted attempts
to update GlobalsModRef when the rest of the optimizer changes
something. However, I am currently trying to remove that update
mechanism as it makes migrating the AA infrastructure to a form that can
be readily shared between new and old pass managers very challenging.
Without this update mechanism, it is possible that this still unlikely
failure mode will start to trip people, and so I wanted to try to
proactively avoid that.
There is a lengthy discussion on the mailing list about why the core
approach here is flawed, and likely would need to look totally different
to be both reasonably effective and resilient to basic IR changes
occuring. This patch is essentially the first of two which will enact
the result of that discussion. The next patch will remove the current
update mechanism.
Thanks to lots of folks that helped look at this from different angles.
Especial thanks to Michael Zolotukhin for doing some very prelimanary
benchmarking of LTO without GlobalsModRef to get a rough idea of the
impact we could be facing here. So far, it looks very small, but there
are some concerns lingering from other benchmarking. The default here
may get flipped if performance results end up pointing at this as a more
significant issue.
Also thanks to Pete and Gerolf for reviewing!
Differential Revision: http://reviews.llvm.org/D11213
llvm-svn: 242512
2015-07-17 14:58:24 +08:00
|
|
|
// use this to disambiguate the pointers. If the pointers are based on
|
|
|
|
// different indirect globals they cannot alias.
|
|
|
|
if (GV1 && GV2 && GV1 != GV2)
|
2004-06-28 14:33:13 +08:00
|
|
|
return NoAlias;
|
2008-09-03 20:55:42 +08:00
|
|
|
|
[PM/AA] Disable the core unsafe aspect of GlobalsModRef in the face of
basic changes to the IR such as folding pointers through PHIs, Selects,
integer casts, store/load pairs, or outlining.
This leaves the feature available behind a flag. This flag's default
could be flipped if necessary, but the real-world performance impact of
this particular feature of GMR may not be sufficiently significant for
many folks to want to run the risk.
Currently, the risk here is somewhat mitigated by half-hearted attempts
to update GlobalsModRef when the rest of the optimizer changes
something. However, I am currently trying to remove that update
mechanism as it makes migrating the AA infrastructure to a form that can
be readily shared between new and old pass managers very challenging.
Without this update mechanism, it is possible that this still unlikely
failure mode will start to trip people, and so I wanted to try to
proactively avoid that.
There is a lengthy discussion on the mailing list about why the core
approach here is flawed, and likely would need to look totally different
to be both reasonably effective and resilient to basic IR changes
occuring. This patch is essentially the first of two which will enact
the result of that discussion. The next patch will remove the current
update mechanism.
Thanks to lots of folks that helped look at this from different angles.
Especial thanks to Michael Zolotukhin for doing some very prelimanary
benchmarking of LTO without GlobalsModRef to get a rough idea of the
impact we could be facing here. So far, it looks very small, but there
are some concerns lingering from other benchmarking. The default here
may get flipped if performance results end up pointing at this as a more
significant issue.
Also thanks to Pete and Gerolf for reviewing!
Differential Revision: http://reviews.llvm.org/D11213
llvm-svn: 242512
2015-07-17 14:58:24 +08:00
|
|
|
// If one is based on an indirect global and the other isn't, it isn't
|
|
|
|
// strictly safe but we can fake this result if necessary for performance.
|
|
|
|
// This does not appear to be a common problem in practice.
|
|
|
|
if (EnableUnsafeGlobalsModRefAliasResults)
|
|
|
|
if ((GV1 || GV2) && GV1 != GV2)
|
|
|
|
return NoAlias;
|
|
|
|
|
[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
|
|
|
return AAResultBase::alias(LocA, LocB);
|
2004-06-28 14:33:13 +08:00
|
|
|
}
|
|
|
|
|
[GlobalsAA] Teach GlobalsAA about nocapture
Arguments to function calls marked "nocapture" can be marked as
non-escaping. However, nocapture is defined in terms of the lifetime
of the callee, and if the callee can directly or indirectly recurse to
the caller, the semantics of nocapture are invalid.
Therefore, we eagerly discover which SCC each function belongs to,
and later can check if callee and caller of a callsite belong to
the same SCC, in which case there could be recursion.
This means that we can't be so optimistic in
getModRefInfo(ImmutableCallsite) - previously we assumed all call
arguments never aliased with an escaping global. Now we need to check,
because a global could now be passed as an argument but still not
escape.
This also solves a related conformance problem: MemCpyOptimizer can
turn non-escaping stores of globals into calls to intrinsics like
llvm.memcpy/llvm/memset. This confuses GlobalsAA, which knows the
global can't escape and so returns NoModRef when queried, when
obviously a memcpy/memset call does indeed reference and modify its
arguments.
This fixes PR24800, PR24801, and PR24802.
llvm-svn: 248576
2015-09-25 23:39:29 +08:00
|
|
|
ModRefInfo GlobalsAAResult::getModRefInfoForArgument(ImmutableCallSite CS,
|
|
|
|
const GlobalValue *GV) {
|
|
|
|
if (CS.doesNotAccessMemory())
|
2017-12-08 06:41:34 +08:00
|
|
|
return ModRefInfo::NoModRef;
|
|
|
|
ModRefInfo ConservativeResult =
|
|
|
|
CS.onlyReadsMemory() ? ModRefInfo::Ref : ModRefInfo::ModRef;
|
2016-08-12 05:15:00 +08:00
|
|
|
|
[GlobalsAA] Teach GlobalsAA about nocapture
Arguments to function calls marked "nocapture" can be marked as
non-escaping. However, nocapture is defined in terms of the lifetime
of the callee, and if the callee can directly or indirectly recurse to
the caller, the semantics of nocapture are invalid.
Therefore, we eagerly discover which SCC each function belongs to,
and later can check if callee and caller of a callsite belong to
the same SCC, in which case there could be recursion.
This means that we can't be so optimistic in
getModRefInfo(ImmutableCallsite) - previously we assumed all call
arguments never aliased with an escaping global. Now we need to check,
because a global could now be passed as an argument but still not
escape.
This also solves a related conformance problem: MemCpyOptimizer can
turn non-escaping stores of globals into calls to intrinsics like
llvm.memcpy/llvm/memset. This confuses GlobalsAA, which knows the
global can't escape and so returns NoModRef when queried, when
obviously a memcpy/memset call does indeed reference and modify its
arguments.
This fixes PR24800, PR24801, and PR24802.
llvm-svn: 248576
2015-09-25 23:39:29 +08:00
|
|
|
// Iterate through all the arguments to the called function. If any argument
|
|
|
|
// is based on GV, return the conservative result.
|
|
|
|
for (auto &A : CS.args()) {
|
|
|
|
SmallVector<Value*, 4> Objects;
|
|
|
|
GetUnderlyingObjects(A, Objects, DL);
|
2016-08-12 05:15:00 +08:00
|
|
|
|
[GlobalsAA] Teach GlobalsAA about nocapture
Arguments to function calls marked "nocapture" can be marked as
non-escaping. However, nocapture is defined in terms of the lifetime
of the callee, and if the callee can directly or indirectly recurse to
the caller, the semantics of nocapture are invalid.
Therefore, we eagerly discover which SCC each function belongs to,
and later can check if callee and caller of a callsite belong to
the same SCC, in which case there could be recursion.
This means that we can't be so optimistic in
getModRefInfo(ImmutableCallsite) - previously we assumed all call
arguments never aliased with an escaping global. Now we need to check,
because a global could now be passed as an argument but still not
escape.
This also solves a related conformance problem: MemCpyOptimizer can
turn non-escaping stores of globals into calls to intrinsics like
llvm.memcpy/llvm/memset. This confuses GlobalsAA, which knows the
global can't escape and so returns NoModRef when queried, when
obviously a memcpy/memset call does indeed reference and modify its
arguments.
This fixes PR24800, PR24801, and PR24802.
llvm-svn: 248576
2015-09-25 23:39:29 +08:00
|
|
|
// All objects must be identified.
|
2016-08-12 05:15:00 +08:00
|
|
|
if (!all_of(Objects, isIdentifiedObject) &&
|
2016-01-14 16:46:45 +08:00
|
|
|
// Try ::alias to see if all objects are known not to alias GV.
|
2016-08-12 05:15:00 +08:00
|
|
|
!all_of(Objects, [&](Value *V) {
|
2016-01-14 16:46:45 +08:00
|
|
|
return this->alias(MemoryLocation(V), MemoryLocation(GV)) == NoAlias;
|
2016-08-12 05:15:00 +08:00
|
|
|
}))
|
[GlobalsAA] Teach GlobalsAA about nocapture
Arguments to function calls marked "nocapture" can be marked as
non-escaping. However, nocapture is defined in terms of the lifetime
of the callee, and if the callee can directly or indirectly recurse to
the caller, the semantics of nocapture are invalid.
Therefore, we eagerly discover which SCC each function belongs to,
and later can check if callee and caller of a callsite belong to
the same SCC, in which case there could be recursion.
This means that we can't be so optimistic in
getModRefInfo(ImmutableCallsite) - previously we assumed all call
arguments never aliased with an escaping global. Now we need to check,
because a global could now be passed as an argument but still not
escape.
This also solves a related conformance problem: MemCpyOptimizer can
turn non-escaping stores of globals into calls to intrinsics like
llvm.memcpy/llvm/memset. This confuses GlobalsAA, which knows the
global can't escape and so returns NoModRef when queried, when
obviously a memcpy/memset call does indeed reference and modify its
arguments.
This fixes PR24800, PR24801, and PR24802.
llvm-svn: 248576
2015-09-25 23:39:29 +08:00
|
|
|
return ConservativeResult;
|
|
|
|
|
2016-08-12 05:15:00 +08:00
|
|
|
if (is_contained(Objects, GV))
|
[GlobalsAA] Teach GlobalsAA about nocapture
Arguments to function calls marked "nocapture" can be marked as
non-escaping. However, nocapture is defined in terms of the lifetime
of the callee, and if the callee can directly or indirectly recurse to
the caller, the semantics of nocapture are invalid.
Therefore, we eagerly discover which SCC each function belongs to,
and later can check if callee and caller of a callsite belong to
the same SCC, in which case there could be recursion.
This means that we can't be so optimistic in
getModRefInfo(ImmutableCallsite) - previously we assumed all call
arguments never aliased with an escaping global. Now we need to check,
because a global could now be passed as an argument but still not
escape.
This also solves a related conformance problem: MemCpyOptimizer can
turn non-escaping stores of globals into calls to intrinsics like
llvm.memcpy/llvm/memset. This confuses GlobalsAA, which knows the
global can't escape and so returns NoModRef when queried, when
obviously a memcpy/memset call does indeed reference and modify its
arguments.
This fixes PR24800, PR24801, and PR24802.
llvm-svn: 248576
2015-09-25 23:39:29 +08:00
|
|
|
return ConservativeResult;
|
|
|
|
}
|
|
|
|
|
|
|
|
// We identified all objects in the argument list, and none of them were GV.
|
2017-12-08 06:41:34 +08:00
|
|
|
return ModRefInfo::NoModRef;
|
[GlobalsAA] Teach GlobalsAA about nocapture
Arguments to function calls marked "nocapture" can be marked as
non-escaping. However, nocapture is defined in terms of the lifetime
of the callee, and if the callee can directly or indirectly recurse to
the caller, the semantics of nocapture are invalid.
Therefore, we eagerly discover which SCC each function belongs to,
and later can check if callee and caller of a callsite belong to
the same SCC, in which case there could be recursion.
This means that we can't be so optimistic in
getModRefInfo(ImmutableCallsite) - previously we assumed all call
arguments never aliased with an escaping global. Now we need to check,
because a global could now be passed as an argument but still not
escape.
This also solves a related conformance problem: MemCpyOptimizer can
turn non-escaping stores of globals into calls to intrinsics like
llvm.memcpy/llvm/memset. This confuses GlobalsAA, which knows the
global can't escape and so returns NoModRef when queried, when
obviously a memcpy/memset call does indeed reference and modify its
arguments.
This fixes PR24800, PR24801, and PR24802.
llvm-svn: 248576
2015-09-25 23:39:29 +08: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-10 01:55:00 +08:00
|
|
|
ModRefInfo GlobalsAAResult::getModRefInfo(ImmutableCallSite CS,
|
|
|
|
const MemoryLocation &Loc) {
|
2017-12-08 06:41:34 +08:00
|
|
|
ModRefInfo Known = ModRefInfo::ModRef;
|
2004-06-28 14:33:13 +08:00
|
|
|
|
|
|
|
// If we are asking for mod/ref info of a direct call with a pointer to a
|
2004-07-27 14:40:37 +08:00
|
|
|
// global we are tracking, return information if we have it.
|
2010-09-15 05:25:10 +08:00
|
|
|
if (const GlobalValue *GV =
|
2015-03-10 10:37:25 +08:00
|
|
|
dyn_cast<GlobalValue>(GetUnderlyingObject(Loc.Ptr, DL)))
|
2009-01-16 04:18:42 +08:00
|
|
|
if (GV->hasLocalLinkage())
|
2010-08-04 05:48:53 +08:00
|
|
|
if (const Function *F = CS.getCalledFunction())
|
2004-07-27 14:40:37 +08:00
|
|
|
if (NonAddressTakenGlobals.count(GV))
|
2015-07-23 07:56:31 +08:00
|
|
|
if (const FunctionInfo *FI = getFunctionInfo(F))
|
2017-12-06 04:12:23 +08:00
|
|
|
Known = unionModRef(FI->getModRefInfoForGlobal(*GV),
|
|
|
|
getModRefInfoForArgument(CS, GV));
|
2004-06-28 14:33:13 +08:00
|
|
|
|
2017-12-06 04:12:23 +08:00
|
|
|
if (!isModOrRefSet(Known))
|
2017-12-08 06:41:34 +08:00
|
|
|
return ModRefInfo::NoModRef; // No need to query other mod/ref analyses
|
2017-12-06 04:12:23 +08:00
|
|
|
return intersectModRef(Known, AAResultBase::getModRefInfo(CS, Loc));
|
[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
|
|
|
}
|
|
|
|
|
|
|
|
GlobalsAAResult::GlobalsAAResult(const DataLayout &DL,
|
|
|
|
const TargetLibraryInfo &TLI)
|
[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 23:56:53 +08:00
|
|
|
: AAResultBase(), DL(DL), TLI(TLI) {}
|
[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
|
|
|
|
|
|
|
GlobalsAAResult::GlobalsAAResult(GlobalsAAResult &&Arg)
|
[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 23:56:53 +08:00
|
|
|
: AAResultBase(std::move(Arg)), DL(Arg.DL), TLI(Arg.TLI),
|
2015-09-10 15:16:42 +08:00
|
|
|
NonAddressTakenGlobals(std::move(Arg.NonAddressTakenGlobals)),
|
|
|
|
IndirectGlobals(std::move(Arg.IndirectGlobals)),
|
|
|
|
AllocsForIndirectGlobals(std::move(Arg.AllocsForIndirectGlobals)),
|
|
|
|
FunctionInfos(std::move(Arg.FunctionInfos)),
|
2015-09-14 14:16:44 +08:00
|
|
|
Handles(std::move(Arg.Handles)) {
|
|
|
|
// Update the parent for each DeletionCallbackHandle.
|
|
|
|
for (auto &H : Handles) {
|
|
|
|
assert(H.GAR == &Arg);
|
|
|
|
H.GAR = 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-10 01:55:00 +08:00
|
|
|
|
2016-03-11 17:15:11 +08:00
|
|
|
GlobalsAAResult::~GlobalsAAResult() {}
|
|
|
|
|
[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
|
|
|
/*static*/ GlobalsAAResult
|
|
|
|
GlobalsAAResult::analyzeModule(Module &M, const TargetLibraryInfo &TLI,
|
|
|
|
CallGraph &CG) {
|
|
|
|
GlobalsAAResult Result(M.getDataLayout(), TLI);
|
|
|
|
|
[GlobalsAA] Teach GlobalsAA about nocapture
Arguments to function calls marked "nocapture" can be marked as
non-escaping. However, nocapture is defined in terms of the lifetime
of the callee, and if the callee can directly or indirectly recurse to
the caller, the semantics of nocapture are invalid.
Therefore, we eagerly discover which SCC each function belongs to,
and later can check if callee and caller of a callsite belong to
the same SCC, in which case there could be recursion.
This means that we can't be so optimistic in
getModRefInfo(ImmutableCallsite) - previously we assumed all call
arguments never aliased with an escaping global. Now we need to check,
because a global could now be passed as an argument but still not
escape.
This also solves a related conformance problem: MemCpyOptimizer can
turn non-escaping stores of globals into calls to intrinsics like
llvm.memcpy/llvm/memset. This confuses GlobalsAA, which knows the
global can't escape and so returns NoModRef when queried, when
obviously a memcpy/memset call does indeed reference and modify its
arguments.
This fixes PR24800, PR24801, and PR24802.
llvm-svn: 248576
2015-09-25 23:39:29 +08:00
|
|
|
// Discover which functions aren't recursive, to feed into AnalyzeGlobals.
|
|
|
|
Result.CollectSCCMembership(CG);
|
|
|
|
|
[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
|
|
|
// Find non-addr taken globals.
|
|
|
|
Result.AnalyzeGlobals(M);
|
|
|
|
|
|
|
|
// Propagate on CG.
|
|
|
|
Result.AnalyzeCallGraph(CG, M);
|
|
|
|
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
2016-11-24 01:53:26 +08:00
|
|
|
AnalysisKey GlobalsAA::Key;
|
2016-03-11 18:22:49 +08:00
|
|
|
|
2016-08-09 08:28:38 +08:00
|
|
|
GlobalsAAResult GlobalsAA::run(Module &M, ModuleAnalysisManager &AM) {
|
[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
|
|
|
return GlobalsAAResult::analyzeModule(M,
|
2016-03-11 19:05:24 +08:00
|
|
|
AM.getResult<TargetLibraryAnalysis>(M),
|
|
|
|
AM.getResult<CallGraphAnalysis>(M));
|
[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
|
|
|
}
|
|
|
|
|
|
|
|
char GlobalsAAWrapperPass::ID = 0;
|
|
|
|
INITIALIZE_PASS_BEGIN(GlobalsAAWrapperPass, "globals-aa",
|
|
|
|
"Globals Alias Analysis", false, true)
|
|
|
|
INITIALIZE_PASS_DEPENDENCY(CallGraphWrapperPass)
|
|
|
|
INITIALIZE_PASS_DEPENDENCY(TargetLibraryInfoWrapperPass)
|
|
|
|
INITIALIZE_PASS_END(GlobalsAAWrapperPass, "globals-aa",
|
|
|
|
"Globals Alias Analysis", false, true)
|
|
|
|
|
|
|
|
ModulePass *llvm::createGlobalsAAWrapperPass() {
|
|
|
|
return new GlobalsAAWrapperPass();
|
|
|
|
}
|
|
|
|
|
|
|
|
GlobalsAAWrapperPass::GlobalsAAWrapperPass() : ModulePass(ID) {
|
|
|
|
initializeGlobalsAAWrapperPassPass(*PassRegistry::getPassRegistry());
|
|
|
|
}
|
|
|
|
|
|
|
|
bool GlobalsAAWrapperPass::runOnModule(Module &M) {
|
|
|
|
Result.reset(new GlobalsAAResult(GlobalsAAResult::analyzeModule(
|
|
|
|
M, getAnalysis<TargetLibraryInfoWrapperPass>().getTLI(),
|
|
|
|
getAnalysis<CallGraphWrapperPass>().getCallGraph())));
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool GlobalsAAWrapperPass::doFinalization(Module &M) {
|
|
|
|
Result.reset();
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
void GlobalsAAWrapperPass::getAnalysisUsage(AnalysisUsage &AU) const {
|
|
|
|
AU.setPreservesAll();
|
|
|
|
AU.addRequired<CallGraphWrapperPass>();
|
|
|
|
AU.addRequired<TargetLibraryInfoWrapperPass>();
|
2004-06-28 14:33:13 +08:00
|
|
|
}
|