2004-06-28 14:33:13 +08:00
|
|
|
//===- GlobalsModRef.cpp - Simple Mod/Ref Analysis for Globals ------------===//
|
2005-04-22 05:13:18 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
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"
|
2020-06-25 22:29:07 +08:00
|
|
|
#include "llvm/Analysis/CallGraph.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"
|
Sink all InitializePasses.h includes
This file lists every pass in LLVM, and is included by Pass.h, which is
very popular. Every time we add, remove, or rename a pass in LLVM, it
caused lots of recompilation.
I found this fact by looking at this table, which is sorted by the
number of times a file was changed over the last 100,000 git commits
multiplied by the number of object files that depend on it in the
current checkout:
recompiles touches affected_files header
342380 95 3604 llvm/include/llvm/ADT/STLExtras.h
314730 234 1345 llvm/include/llvm/InitializePasses.h
307036 118 2602 llvm/include/llvm/ADT/APInt.h
213049 59 3611 llvm/include/llvm/Support/MathExtras.h
170422 47 3626 llvm/include/llvm/Support/Compiler.h
162225 45 3605 llvm/include/llvm/ADT/Optional.h
158319 63 2513 llvm/include/llvm/ADT/Triple.h
140322 39 3598 llvm/include/llvm/ADT/StringRef.h
137647 59 2333 llvm/include/llvm/Support/Error.h
131619 73 1803 llvm/include/llvm/Support/FileSystem.h
Before this change, touching InitializePasses.h would cause 1345 files
to recompile. After this change, touching it only causes 550 compiles in
an incremental rebuild.
Reviewers: bkramer, asbirlea, bollu, jdoerfert
Differential Revision: https://reviews.llvm.org/D70211
2019-11-14 05:15:01 +08:00
|
|
|
#include "llvm/InitializePasses.h"
|
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"
|
2020-06-25 22:29:07 +08:00
|
|
|
|
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
|
2020-07-31 12:07:10 +08:00
|
|
|
// transforms which cause assymetry between how effective getUnderlyingObject
|
[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
|
|
|
// 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.
|
2018-07-27 13:38:14 +08:00
|
|
|
struct alignas(8) AlignedMap {
|
2015-07-23 15:50:52 +08:00
|
|
|
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;
|
|
|
|
}
|
2020-01-16 04:36:20 +08:00
|
|
|
static constexpr int 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!
|
[ModRefInfo] Add must alias info to ModRefInfo.
Summary:
Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases.
Shift existing Mod/Ref/ModRef values to include an additional most
significant bit. Update wrappers that modify ModRefInfo values to
reflect the change.
Notes:
* ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it.
* Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA).
* GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost.
* There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location.
Reviewers: dberlin, hfinkel, george.burgess.iv
Subscribers: llvm-commits, sanjoy
Differential Revision: https://reviews.llvm.org/D38862
llvm-svn: 321309
2017-12-22 05:41:53 +08:00
|
|
|
/// It overlaps with ModRefInfo::Must bit!
|
|
|
|
/// FunctionInfo.getModRefInfo() masks out everything except ModRef so
|
|
|
|
/// this remains correct, but the Must info is lost.
|
2015-07-23 15:50:52 +08:00
|
|
|
enum { MayReadAnyGlobal = 4 };
|
|
|
|
|
|
|
|
/// Checks to document the invariants of the bit packing here.
|
[ModRefInfo] Add must alias info to ModRefInfo.
Summary:
Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases.
Shift existing Mod/Ref/ModRef values to include an additional most
significant bit. Update wrappers that modify ModRefInfo values to
reflect the change.
Notes:
* ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it.
* Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA).
* GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost.
* There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location.
Reviewers: dberlin, hfinkel, george.burgess.iv
Subscribers: llvm-commits, sanjoy
Differential Revision: https://reviews.llvm.org/D38862
llvm-svn: 321309
2017-12-22 05:41:53 +08:00
|
|
|
static_assert((MayReadAnyGlobal & static_cast<int>(ModRefInfo::MustModRef)) ==
|
|
|
|
0,
|
2015-07-23 15:50:52 +08:00
|
|
|
"ModRef and the MayReadAnyGlobal flag bits overlap.");
|
[ModRefInfo] Add must alias info to ModRefInfo.
Summary:
Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases.
Shift existing Mod/Ref/ModRef values to include an additional most
significant bit. Update wrappers that modify ModRefInfo values to
reflect the change.
Notes:
* ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it.
* Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA).
* GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost.
* There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location.
Reviewers: dberlin, hfinkel, george.burgess.iv
Subscribers: llvm-commits, sanjoy
Differential Revision: https://reviews.llvm.org/D38862
llvm-svn: 321309
2017-12-22 05:41:53 +08:00
|
|
|
static_assert(((MayReadAnyGlobal |
|
|
|
|
static_cast<int>(ModRefInfo::MustModRef)) >>
|
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
|
|
|
|
[ModRefInfo] Add must alias info to ModRefInfo.
Summary:
Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases.
Shift existing Mod/Ref/ModRef values to include an additional most
significant bit. Update wrappers that modify ModRefInfo values to
reflect the change.
Notes:
* ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it.
* Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA).
* GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost.
* There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location.
Reviewers: dberlin, hfinkel, george.burgess.iv
Subscribers: llvm-commits, sanjoy
Differential Revision: https://reviews.llvm.org/D38862
llvm-svn: 321309
2017-12-22 05:41:53 +08:00
|
|
|
/// This method clears MayReadAnyGlobal bit added by GlobalsAAResult to return
|
|
|
|
/// the corresponding ModRefInfo. It must align in functionality with
|
|
|
|
/// clearMust().
|
|
|
|
ModRefInfo globalClearMayReadAnyGlobal(int I) const {
|
|
|
|
return ModRefInfo((I & static_cast<int>(ModRefInfo::ModRef)) |
|
|
|
|
static_cast<int>(ModRefInfo::NoModRef));
|
|
|
|
}
|
|
|
|
|
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 {
|
[ModRefInfo] Add must alias info to ModRefInfo.
Summary:
Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases.
Shift existing Mod/Ref/ModRef values to include an additional most
significant bit. Update wrappers that modify ModRefInfo values to
reflect the change.
Notes:
* ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it.
* Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA).
* GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost.
* There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location.
Reviewers: dberlin, hfinkel, george.burgess.iv
Subscribers: llvm-commits, sanjoy
Differential Revision: https://reviews.llvm.org/D38862
llvm-svn: 321309
2017-12-22 05:41:53 +08:00
|
|
|
return globalClearMayReadAnyGlobal(Info.getInt());
|
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) {
|
[ModRefInfo] Add must alias info to ModRefInfo.
Summary:
Add an additional bit to ModRefInfo, ModRefInfo::Must, to be cleared for known must aliases.
Shift existing Mod/Ref/ModRef values to include an additional most
significant bit. Update wrappers that modify ModRefInfo values to
reflect the change.
Notes:
* ModRefInfo::Must is almost entirely cleared in the AAResults methods, the remaining changes are trying to preserve it.
* Only some small changes to make custom AA passes set ModRefInfo::Must (BasicAA).
* GlobalsModRef already declares a bit, who's meaning overlaps with the most significant bit in ModRefInfo (MayReadAnyGlobal). No changes to shift the value of MayReadAnyGlobal (see AlignedMap). FunctionInfo.getModRef() ajusts most significant bit so correctness is preserved, but the Must info is lost.
* There are cases where the ModRefInfo::Must is not set, e.g. 2 calls that only read will return ModRefInfo::NoModRef, though they may read from exactly the same location.
Reviewers: dberlin, hfinkel, george.burgess.iv
Subscribers: llvm-commits, sanjoy
Differential Revision: https://reviews.llvm.org/D38862
llvm-svn: 321309
2017-12-22 05:41:53 +08:00
|
|
|
Info.setInt(Info.getInt() | static_cast<int>(setMust(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
|
2019-01-07 13:42:51 +08:00
|
|
|
GlobalsAAResult::getModRefBehavior(const CallBase *Call) {
|
2015-08-14 11:48:20 +08:00
|
|
|
FunctionModRefBehavior Min = FMRB_UnknownModRefBehavior;
|
2015-07-14 16:42:39 +08:00
|
|
|
|
2019-01-07 13:42:51 +08:00
|
|
|
if (!Call->hasOperandBundles())
|
|
|
|
if (const Function *F = Call->getCalledFunction())
|
2016-02-09 10:31:47 +08:00
|
|
|
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
|
|
|
|
2019-01-07 13:42:51 +08:00
|
|
|
return FunctionModRefBehavior(AAResultBase::getModRefBehavior(Call) & 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)
|
2019-11-01 03:35:46 +08:00
|
|
|
if (F.hasLocalLinkage()) {
|
2015-07-23 06:10:05 +08:00
|
|
|
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;
|
2019-11-01 03:35:46 +08:00
|
|
|
} else
|
|
|
|
UnknownFunctionsWithLocalLinkage = true;
|
|
|
|
}
|
2004-06-28 14:33:13 +08:00
|
|
|
|
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;
|
2019-01-07 13:42:51 +08:00
|
|
|
} else if (auto *Call = dyn_cast<CallBase>(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.
|
2019-01-07 13:42:51 +08:00
|
|
|
if (Call->isDataOperand(&U)) {
|
2014-02-10 22:17:30 +08:00
|
|
|
// Detect calls to free.
|
Change TargetLibraryInfo analysis passes to always require Function
Summary:
This is the first change to enable the TLI to be built per-function so
that -fno-builtin* handling can be migrated to use function attributes.
See discussion on D61634 for background. This is an enabler for fixing
handling of these options for LTO, for example.
This change should not affect behavior, as the provided function is not
yet used to build a specifically per-function TLI, but rather enables
that migration.
Most of the changes were very mechanical, e.g. passing a Function to the
legacy analysis pass's getTLI interface, or in Module level cases,
adding a callback. This is similar to the way the per-function TTI
analysis works.
There was one place where we were looking for builtins but not in the
context of a specific function. See FindCXAAtExit in
lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround
could provide the wrong behavior in some corner cases. Suggestions
welcome.
Reviewers: chandlerc, hfinkel
Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66428
llvm-svn: 371284
2019-09-07 11:09:36 +08:00
|
|
|
if (Call->isArgOperand(&U) &&
|
|
|
|
isFreeCall(I, &GetTLI(*Call->getFunction()))) {
|
2015-07-23 06:10:05 +08:00
|
|
|
if (Writers)
|
2019-01-07 13:42:51 +08:00
|
|
|
Writers->insert(Call->getParent()->getParent());
|
2015-07-23 06:10:05 +08:00
|
|
|
} 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;
|
2018-07-31 03:41:25 +08:00
|
|
|
|
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.
|
2020-07-31 17:09:54 +08:00
|
|
|
Value *Ptr = getUnderlyingObject(SI->getOperand(0));
|
2006-10-02 06:36:45 +08:00
|
|
|
|
Change TargetLibraryInfo analysis passes to always require Function
Summary:
This is the first change to enable the TLI to be built per-function so
that -fno-builtin* handling can be migrated to use function attributes.
See discussion on D61634 for background. This is an enabler for fixing
handling of these options for LTO, for example.
This change should not affect behavior, as the provided function is not
yet used to build a specifically per-function TLI, but rather enables
that migration.
Most of the changes were very mechanical, e.g. passing a Function to the
legacy analysis pass's getTLI interface, or in Module level cases,
adding a callback. This is similar to the way the per-function TTI
analysis works.
There was one place where we were looking for builtins but not in the
context of a specific function. See FindCXAAtExit in
lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround
could provide the wrong behavior in some corner cases. Suggestions
welcome.
Reviewers: chandlerc, hfinkel
Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66428
llvm-svn: 371284
2019-09-07 11:09:36 +08:00
|
|
|
if (!isAllocLikeFn(Ptr, &GetTLI(*SI->getFunction())))
|
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;
|
|
|
|
}
|
|
|
|
|
2018-07-31 03:41:25 +08:00
|
|
|
void GlobalsAAResult::CollectSCCMembership(CallGraph &CG) {
|
[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
|
|
|
// 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];
|
2018-03-17 07:51:33 +08:00
|
|
|
Handles.emplace_front(*this, F);
|
|
|
|
Handles.front().I = Handles.begin();
|
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
|
|
|
|
2019-04-05 06:40:06 +08:00
|
|
|
if (F->isDeclaration() || F->hasOptNone()) {
|
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);
|
2019-11-01 03:35:46 +08:00
|
|
|
if (!F->onlyAccessesArgMemory())
|
|
|
|
FI.setMayReadAnyGlobal();
|
|
|
|
if (!F->isIntrinsic()) {
|
|
|
|
KnowNothing = true;
|
|
|
|
break;
|
|
|
|
}
|
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.
|
2019-04-05 06:40:06 +08:00
|
|
|
if (Node->getFunction()->hasOptNone())
|
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.
|
2019-01-07 13:42:51 +08:00
|
|
|
if (auto *Call = dyn_cast<CallBase>(&I)) {
|
Change TargetLibraryInfo analysis passes to always require Function
Summary:
This is the first change to enable the TLI to be built per-function so
that -fno-builtin* handling can be migrated to use function attributes.
See discussion on D61634 for background. This is an enabler for fixing
handling of these options for LTO, for example.
This change should not affect behavior, as the provided function is not
yet used to build a specifically per-function TLI, but rather enables
that migration.
Most of the changes were very mechanical, e.g. passing a Function to the
legacy analysis pass's getTLI interface, or in Module level cases,
adding a callback. This is similar to the way the per-function TTI
analysis works.
There was one place where we were looking for builtins but not in the
context of a specific function. See FindCXAAtExit in
lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround
could provide the wrong behavior in some corner cases. Suggestions
welcome.
Reviewers: chandlerc, hfinkel
Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66428
llvm-svn: 371284
2019-09-07 11:09:36 +08:00
|
|
|
auto &TLI = GetTLI(*Node->getFunction());
|
2019-01-07 13:42:51 +08:00
|
|
|
if (isAllocationFn(Call, &TLI) || isFreeCall(Call, &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);
|
2019-01-07 13:42:51 +08:00
|
|
|
} else if (Function *Callee = Call->getCalledFunction()) {
|
2015-07-15 16:53:29 +08:00
|
|
|
// The callgraph doesn't include intrinsic calls.
|
|
|
|
if (Callee->isIntrinsic()) {
|
2019-01-07 13:42:51 +08:00
|
|
|
if (isa<DbgInfoIntrinsic>(Call))
|
2018-01-15 15:05:51 +08:00
|
|
|
// Don't let dbg intrinsics affect alias info.
|
|
|
|
continue;
|
|
|
|
|
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
|
2019-02-05 16:30:48 +08:00
|
|
|
// they read or write memory.
|
2015-07-15 16:53:29 +08:00
|
|
|
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();
|
2018-07-31 03:41:25 +08:00
|
|
|
|
2015-10-22 21:44:26 +08:00
|
|
|
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)) {
|
2020-07-31 17:09:54 +08:00
|
|
|
Inputs.push_back(getUnderlyingObject(LI->getPointerOperand()));
|
2015-10-22 21:44:26 +08:00
|
|
|
continue;
|
2018-07-31 03:41:25 +08:00
|
|
|
}
|
2015-10-22 21:44:26 +08:00
|
|
|
if (auto *SI = dyn_cast<SelectInst>(Input)) {
|
2020-07-31 17:09:54 +08:00
|
|
|
const Value *LHS = getUnderlyingObject(SI->getTrueValue());
|
|
|
|
const Value *RHS = getUnderlyingObject(SI->getFalseValue());
|
2015-10-22 21:44:26 +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()) {
|
2020-07-31 17:09:54 +08:00
|
|
|
Op = getUnderlyingObject(Op);
|
2015-10-22 21:44:26 +08:00
|
|
|
if (Visited.insert(Op).second)
|
|
|
|
Inputs.push_back(Op);
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
2018-07-31 03:41:25 +08:00
|
|
|
|
2015-10-22 21:44:26 +08:00
|
|
|
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;
|
|
|
|
}
|
2018-07-31 03:41:25 +08:00
|
|
|
|
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.
|
2020-07-31 17:09:54 +08:00
|
|
|
const Value *Ptr = getUnderlyingObject(LI->getPointerOperand());
|
2015-10-22 21:44:26 +08:00
|
|
|
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)) {
|
2020-07-31 17:09:54 +08:00
|
|
|
const Value *LHS = getUnderlyingObject(SI->getTrueValue());
|
|
|
|
const Value *RHS = getUnderlyingObject(SI->getFalseValue());
|
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()) {
|
2020-07-31 17:09:54 +08:00
|
|
|
Op = getUnderlyingObject(Op);
|
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
|
2019-02-05 16:30:48 +08:00
|
|
|
// it isn't clear how to do so reasonably 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
|
2019-02-05 16:30:48 +08:00
|
|
|
// implementation of such a query. Until then, just conservatively return
|
2015-08-11 16:06:44 +08:00
|
|
|
// 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;
|
|
|
|
}
|
|
|
|
|
2020-01-16 06:10:37 +08:00
|
|
|
bool GlobalsAAResult::invalidate(Module &, const PreservedAnalyses &PA,
|
|
|
|
ModuleAnalysisManager::Invalidator &) {
|
|
|
|
// Check whether the analysis has been explicitly invalidated. Otherwise, it's
|
|
|
|
// stateless and remains preserved.
|
|
|
|
auto PAC = PA.getChecker<GlobalsAA>();
|
|
|
|
return !PAC.preservedWhenStateless();
|
|
|
|
}
|
|
|
|
|
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,
|
[AliasAnalysis] Second prototype to cache BasicAA / anyAA state.
Summary:
Adding contained caching to AliasAnalysis. BasicAA is currently the only one using it.
AA changes:
- This patch is pulling the caches from BasicAAResults to AAResults, meaning the getModRefInfo call benefits from the IsCapturedCache as well when in "batch mode".
- All AAResultBase implementations add the QueryInfo member to all APIs. AAResults APIs maintain wrapper APIs such that all alias()/getModRefInfo call sites are unchanged.
- AA now provides a BatchAAResults type as a wrapper to AAResults. It keeps the AAResults instance and a QueryInfo instantiated to batch mode. It delegates all work to the AAResults instance with the batched QueryInfo. More API wrappers may be needed in BatchAAResults; only the minimum needed is currently added.
MemorySSA changes:
- All walkers are now templated on the AA used (AliasAnalysis=AAResults or BatchAAResults).
- At build time, we optimize uses; now we create a local walker (lives only as long as OptimizeUses does) using BatchAAResults.
- All Walkers have an internal AA and only use that now, never the AA in MemorySSA. The Walkers receive the AA they will use when built.
- The walker we use for queries after the build is instantiated on AliasAnalysis and is built after building MemorySSA and setting AA.
- All static methods doing walking are now templated on AliasAnalysisType if they are used both during build and after. If used only during build, the method now only takes a BatchAAResults. If used only after build, the method now takes an AliasAnalysis.
Subscribers: sanjoy, arsenm, jvesely, nhaehnle, jlebar, george.burgess.iv, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59315
llvm-svn: 356783
2019-03-23 01:22:19 +08:00
|
|
|
const MemoryLocation &LocB,
|
|
|
|
AAQueryInfo &AAQI) {
|
2006-10-02 06:36:45 +08:00
|
|
|
// Get the base object these pointers point to.
|
2020-07-31 17:09:54 +08:00
|
|
|
const Value *UV1 = getUnderlyingObject(LocA.Ptr);
|
|
|
|
const Value *UV2 = getUnderlyingObject(LocB.Ptr);
|
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;
|
|
|
|
|
[AliasAnalysis] Second prototype to cache BasicAA / anyAA state.
Summary:
Adding contained caching to AliasAnalysis. BasicAA is currently the only one using it.
AA changes:
- This patch is pulling the caches from BasicAAResults to AAResults, meaning the getModRefInfo call benefits from the IsCapturedCache as well when in "batch mode".
- All AAResultBase implementations add the QueryInfo member to all APIs. AAResults APIs maintain wrapper APIs such that all alias()/getModRefInfo call sites are unchanged.
- AA now provides a BatchAAResults type as a wrapper to AAResults. It keeps the AAResults instance and a QueryInfo instantiated to batch mode. It delegates all work to the AAResults instance with the batched QueryInfo. More API wrappers may be needed in BatchAAResults; only the minimum needed is currently added.
MemorySSA changes:
- All walkers are now templated on the AA used (AliasAnalysis=AAResults or BatchAAResults).
- At build time, we optimize uses; now we create a local walker (lives only as long as OptimizeUses does) using BatchAAResults.
- All Walkers have an internal AA and only use that now, never the AA in MemorySSA. The Walkers receive the AA they will use when built.
- The walker we use for queries after the build is instantiated on AliasAnalysis and is built after building MemorySSA and setting AA.
- All static methods doing walking are now templated on AliasAnalysisType if they are used both during build and after. If used only during build, the method now only takes a BatchAAResults. If used only after build, the method now takes an AliasAnalysis.
Subscribers: sanjoy, arsenm, jvesely, nhaehnle, jlebar, george.burgess.iv, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59315
llvm-svn: 356783
2019-03-23 01:22:19 +08:00
|
|
|
return AAResultBase::alias(LocA, LocB, AAQI);
|
2004-06-28 14:33:13 +08:00
|
|
|
}
|
|
|
|
|
2019-01-07 13:42:51 +08:00
|
|
|
ModRefInfo GlobalsAAResult::getModRefInfoForArgument(const CallBase *Call,
|
[AliasAnalysis] Second prototype to cache BasicAA / anyAA state.
Summary:
Adding contained caching to AliasAnalysis. BasicAA is currently the only one using it.
AA changes:
- This patch is pulling the caches from BasicAAResults to AAResults, meaning the getModRefInfo call benefits from the IsCapturedCache as well when in "batch mode".
- All AAResultBase implementations add the QueryInfo member to all APIs. AAResults APIs maintain wrapper APIs such that all alias()/getModRefInfo call sites are unchanged.
- AA now provides a BatchAAResults type as a wrapper to AAResults. It keeps the AAResults instance and a QueryInfo instantiated to batch mode. It delegates all work to the AAResults instance with the batched QueryInfo. More API wrappers may be needed in BatchAAResults; only the minimum needed is currently added.
MemorySSA changes:
- All walkers are now templated on the AA used (AliasAnalysis=AAResults or BatchAAResults).
- At build time, we optimize uses; now we create a local walker (lives only as long as OptimizeUses does) using BatchAAResults.
- All Walkers have an internal AA and only use that now, never the AA in MemorySSA. The Walkers receive the AA they will use when built.
- The walker we use for queries after the build is instantiated on AliasAnalysis and is built after building MemorySSA and setting AA.
- All static methods doing walking are now templated on AliasAnalysisType if they are used both during build and after. If used only during build, the method now only takes a BatchAAResults. If used only after build, the method now takes an AliasAnalysis.
Subscribers: sanjoy, arsenm, jvesely, nhaehnle, jlebar, george.burgess.iv, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59315
llvm-svn: 356783
2019-03-23 01:22:19 +08:00
|
|
|
const GlobalValue *GV,
|
|
|
|
AAQueryInfo &AAQI) {
|
2019-01-07 13:42:51 +08:00
|
|
|
if (Call->doesNotAccessMemory())
|
2017-12-08 06:41:34 +08:00
|
|
|
return ModRefInfo::NoModRef;
|
|
|
|
ModRefInfo ConservativeResult =
|
2019-01-07 13:42:51 +08:00
|
|
|
Call->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.
|
2019-01-07 13:42:51 +08:00
|
|
|
for (auto &A : Call->args()) {
|
Add "const" in GetUnderlyingObjects. NFC
Summary:
Both the input Value pointer and the returned Value
pointers in GetUnderlyingObjects are now declared as
const.
It turned out that all current (in-tree) uses of
GetUnderlyingObjects were trivial to update, being
satisfied with have those Value pointers declared
as const. Actually, in the past several of the users
had to use const_cast, just because of ValueTracking
not providing a version of GetUnderlyingObjects with
"const" Value pointers. With this patch we get rid
of those const casts.
Reviewers: hfinkel, materi, jkorous
Reviewed By: jkorous
Subscribers: dexonsmith, jkorous, jholewinski, sdardis, eraman, hiraditya, jrtc27, atanasyan, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61038
llvm-svn: 359072
2019-04-24 14:55:50 +08:00
|
|
|
SmallVector<const Value*, 4> Objects;
|
2020-07-31 17:09:54 +08:00
|
|
|
getUnderlyingObjects(A, Objects);
|
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.
|
Add "const" in GetUnderlyingObjects. NFC
Summary:
Both the input Value pointer and the returned Value
pointers in GetUnderlyingObjects are now declared as
const.
It turned out that all current (in-tree) uses of
GetUnderlyingObjects were trivial to update, being
satisfied with have those Value pointers declared
as const. Actually, in the past several of the users
had to use const_cast, just because of ValueTracking
not providing a version of GetUnderlyingObjects with
"const" Value pointers. With this patch we get rid
of those const casts.
Reviewers: hfinkel, materi, jkorous
Reviewed By: jkorous
Subscribers: dexonsmith, jkorous, jholewinski, sdardis, eraman, hiraditya, jrtc27, atanasyan, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61038
llvm-svn: 359072
2019-04-24 14:55:50 +08:00
|
|
|
!all_of(Objects, [&](const Value *V) {
|
[AliasAnalysis] Second prototype to cache BasicAA / anyAA state.
Summary:
Adding contained caching to AliasAnalysis. BasicAA is currently the only one using it.
AA changes:
- This patch is pulling the caches from BasicAAResults to AAResults, meaning the getModRefInfo call benefits from the IsCapturedCache as well when in "batch mode".
- All AAResultBase implementations add the QueryInfo member to all APIs. AAResults APIs maintain wrapper APIs such that all alias()/getModRefInfo call sites are unchanged.
- AA now provides a BatchAAResults type as a wrapper to AAResults. It keeps the AAResults instance and a QueryInfo instantiated to batch mode. It delegates all work to the AAResults instance with the batched QueryInfo. More API wrappers may be needed in BatchAAResults; only the minimum needed is currently added.
MemorySSA changes:
- All walkers are now templated on the AA used (AliasAnalysis=AAResults or BatchAAResults).
- At build time, we optimize uses; now we create a local walker (lives only as long as OptimizeUses does) using BatchAAResults.
- All Walkers have an internal AA and only use that now, never the AA in MemorySSA. The Walkers receive the AA they will use when built.
- The walker we use for queries after the build is instantiated on AliasAnalysis and is built after building MemorySSA and setting AA.
- All static methods doing walking are now templated on AliasAnalysisType if they are used both during build and after. If used only during build, the method now only takes a BatchAAResults. If used only after build, the method now takes an AliasAnalysis.
Subscribers: sanjoy, arsenm, jvesely, nhaehnle, jlebar, george.burgess.iv, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59315
llvm-svn: 356783
2019-03-23 01:22:19 +08:00
|
|
|
return this->alias(MemoryLocation(V), MemoryLocation(GV), AAQI) ==
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2019-01-07 13:42:51 +08:00
|
|
|
ModRefInfo GlobalsAAResult::getModRefInfo(const CallBase *Call,
|
[AliasAnalysis] Second prototype to cache BasicAA / anyAA state.
Summary:
Adding contained caching to AliasAnalysis. BasicAA is currently the only one using it.
AA changes:
- This patch is pulling the caches from BasicAAResults to AAResults, meaning the getModRefInfo call benefits from the IsCapturedCache as well when in "batch mode".
- All AAResultBase implementations add the QueryInfo member to all APIs. AAResults APIs maintain wrapper APIs such that all alias()/getModRefInfo call sites are unchanged.
- AA now provides a BatchAAResults type as a wrapper to AAResults. It keeps the AAResults instance and a QueryInfo instantiated to batch mode. It delegates all work to the AAResults instance with the batched QueryInfo. More API wrappers may be needed in BatchAAResults; only the minimum needed is currently added.
MemorySSA changes:
- All walkers are now templated on the AA used (AliasAnalysis=AAResults or BatchAAResults).
- At build time, we optimize uses; now we create a local walker (lives only as long as OptimizeUses does) using BatchAAResults.
- All Walkers have an internal AA and only use that now, never the AA in MemorySSA. The Walkers receive the AA they will use when built.
- The walker we use for queries after the build is instantiated on AliasAnalysis and is built after building MemorySSA and setting AA.
- All static methods doing walking are now templated on AliasAnalysisType if they are used both during build and after. If used only during build, the method now only takes a BatchAAResults. If used only after build, the method now takes an AliasAnalysis.
Subscribers: sanjoy, arsenm, jvesely, nhaehnle, jlebar, george.burgess.iv, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59315
llvm-svn: 356783
2019-03-23 01:22:19 +08:00
|
|
|
const MemoryLocation &Loc,
|
|
|
|
AAQueryInfo &AAQI) {
|
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 =
|
2020-07-31 17:09:54 +08:00
|
|
|
dyn_cast<GlobalValue>(getUnderlyingObject(Loc.Ptr)))
|
2019-11-01 03:35:46 +08:00
|
|
|
// If GV is internal to this IR and there is no function with local linkage
|
|
|
|
// that has had their address taken, keep looking for a tighter ModRefInfo.
|
|
|
|
if (GV->hasLocalLinkage() && !UnknownFunctionsWithLocalLinkage)
|
2019-01-07 13:42:51 +08:00
|
|
|
if (const Function *F = Call->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),
|
[AliasAnalysis] Second prototype to cache BasicAA / anyAA state.
Summary:
Adding contained caching to AliasAnalysis. BasicAA is currently the only one using it.
AA changes:
- This patch is pulling the caches from BasicAAResults to AAResults, meaning the getModRefInfo call benefits from the IsCapturedCache as well when in "batch mode".
- All AAResultBase implementations add the QueryInfo member to all APIs. AAResults APIs maintain wrapper APIs such that all alias()/getModRefInfo call sites are unchanged.
- AA now provides a BatchAAResults type as a wrapper to AAResults. It keeps the AAResults instance and a QueryInfo instantiated to batch mode. It delegates all work to the AAResults instance with the batched QueryInfo. More API wrappers may be needed in BatchAAResults; only the minimum needed is currently added.
MemorySSA changes:
- All walkers are now templated on the AA used (AliasAnalysis=AAResults or BatchAAResults).
- At build time, we optimize uses; now we create a local walker (lives only as long as OptimizeUses does) using BatchAAResults.
- All Walkers have an internal AA and only use that now, never the AA in MemorySSA. The Walkers receive the AA they will use when built.
- The walker we use for queries after the build is instantiated on AliasAnalysis and is built after building MemorySSA and setting AA.
- All static methods doing walking are now templated on AliasAnalysisType if they are used both during build and after. If used only during build, the method now only takes a BatchAAResults. If used only after build, the method now takes an AliasAnalysis.
Subscribers: sanjoy, arsenm, jvesely, nhaehnle, jlebar, george.burgess.iv, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59315
llvm-svn: 356783
2019-03-23 01:22:19 +08:00
|
|
|
getModRefInfoForArgument(Call, GV, AAQI));
|
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
|
[AliasAnalysis] Second prototype to cache BasicAA / anyAA state.
Summary:
Adding contained caching to AliasAnalysis. BasicAA is currently the only one using it.
AA changes:
- This patch is pulling the caches from BasicAAResults to AAResults, meaning the getModRefInfo call benefits from the IsCapturedCache as well when in "batch mode".
- All AAResultBase implementations add the QueryInfo member to all APIs. AAResults APIs maintain wrapper APIs such that all alias()/getModRefInfo call sites are unchanged.
- AA now provides a BatchAAResults type as a wrapper to AAResults. It keeps the AAResults instance and a QueryInfo instantiated to batch mode. It delegates all work to the AAResults instance with the batched QueryInfo. More API wrappers may be needed in BatchAAResults; only the minimum needed is currently added.
MemorySSA changes:
- All walkers are now templated on the AA used (AliasAnalysis=AAResults or BatchAAResults).
- At build time, we optimize uses; now we create a local walker (lives only as long as OptimizeUses does) using BatchAAResults.
- All Walkers have an internal AA and only use that now, never the AA in MemorySSA. The Walkers receive the AA they will use when built.
- The walker we use for queries after the build is instantiated on AliasAnalysis and is built after building MemorySSA and setting AA.
- All static methods doing walking are now templated on AliasAnalysisType if they are used both during build and after. If used only during build, the method now only takes a BatchAAResults. If used only after build, the method now takes an AliasAnalysis.
Subscribers: sanjoy, arsenm, jvesely, nhaehnle, jlebar, george.burgess.iv, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59315
llvm-svn: 356783
2019-03-23 01:22:19 +08:00
|
|
|
return intersectModRef(Known, AAResultBase::getModRefInfo(Call, Loc, AAQI));
|
[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
|
|
|
}
|
|
|
|
|
Change TargetLibraryInfo analysis passes to always require Function
Summary:
This is the first change to enable the TLI to be built per-function so
that -fno-builtin* handling can be migrated to use function attributes.
See discussion on D61634 for background. This is an enabler for fixing
handling of these options for LTO, for example.
This change should not affect behavior, as the provided function is not
yet used to build a specifically per-function TLI, but rather enables
that migration.
Most of the changes were very mechanical, e.g. passing a Function to the
legacy analysis pass's getTLI interface, or in Module level cases,
adding a callback. This is similar to the way the per-function TTI
analysis works.
There was one place where we were looking for builtins but not in the
context of a specific function. See FindCXAAtExit in
lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround
could provide the wrong behavior in some corner cases. Suggestions
welcome.
Reviewers: chandlerc, hfinkel
Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66428
llvm-svn: 371284
2019-09-07 11:09:36 +08:00
|
|
|
GlobalsAAResult::GlobalsAAResult(
|
|
|
|
const DataLayout &DL,
|
|
|
|
std::function<const TargetLibraryInfo &(Function &F)> GetTLI)
|
|
|
|
: AAResultBase(), DL(DL), GetTLI(std::move(GetTLI)) {}
|
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
with the new pass manager, and no longer relying on analysis groups.
This builds essentially a ground-up new AA infrastructure stack for
LLVM. The core ideas are the same that are used throughout the new pass
manager: type erased polymorphism and direct composition. The design is
as follows:
- FunctionAAResults is a type-erasing alias analysis results aggregation
interface to walk a single query across a range of results from
different alias analyses. Currently this is function-specific as we
always assume that aliasing queries are *within* a function.
- AAResultBase is a CRTP utility providing stub implementations of
various parts of the alias analysis result concept, notably in several
cases in terms of other more general parts of the interface. This can
be used to implement only a narrow part of the interface rather than
the entire interface. This isn't really ideal, this logic should be
hoisted into FunctionAAResults as currently it will cause
a significant amount of redundant work, but it faithfully models the
behavior of the prior infrastructure.
- All the alias analysis passes are ported to be wrapper passes for the
legacy PM and new-style analysis passes for the new PM with a shared
result object. In some cases (most notably CFL), this is an extremely
naive approach that we should revisit when we can specialize for the
new pass manager.
- BasicAA has been restructured to reflect that it is much more
fundamentally a function analysis because it uses dominator trees and
loop info that need to be constructed for each function.
All of the references to getting alias analysis results have been
updated to use the new aggregation interface. All the preservation and
other pass management code has been updated accordingly.
The way the FunctionAAResultsWrapperPass works is to detect the
available alias analyses when run, and add them to the results object.
This means that we should be able to continue to respect when various
passes are added to the pipeline, for example adding CFL or adding TBAA
passes should just cause their results to be available and to get folded
into this. The exception to this rule is BasicAA which really needs to
be a function pass due to using dominator trees and loop info. As
a consequence, the FunctionAAResultsWrapperPass directly depends on
BasicAA and always includes it in the aggregation.
This has significant implications for preserving analyses. Generally,
most passes shouldn't bother preserving FunctionAAResultsWrapperPass
because rebuilding the results just updates the set of known AA passes.
The exception to this rule are LoopPass instances which need to preserve
all the function analyses that the loop pass manager will end up
needing. This means preserving both BasicAAWrapperPass and the
aggregating FunctionAAResultsWrapperPass.
Now, when preserving an alias analysis, you do so by directly preserving
that analysis. This is only necessary for non-immutable-pass-provided
alias analyses though, and there are only three of interest: BasicAA,
GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
preserved when needed because it (like DominatorTree and LoopInfo) is
marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
set everywhere we previously were preserving all of AliasAnalysis, and
I've added SCEVAA in the intersection of that with where we preserve
SCEV itself.
One significant challenge to all of this is that the CGSCC passes were
actually using the alias analysis implementations by taking advantage of
a pretty amazing set of loop holes in the old pass manager's analysis
management code which allowed analysis groups to slide through in many
cases. Moving away from analysis groups makes this problem much more
obvious. To fix it, I've leveraged the flexibility the design of the new
PM components provides to just directly construct the relevant alias
analyses for the relevant functions in the IPO passes that need them.
This is a bit hacky, but should go away with the new pass manager, and
is already in many ways cleaner than the prior state.
Another significant challenge is that various facilities of the old
alias analysis infrastructure just don't fit any more. The most
significant of these is the alias analysis 'counter' pass. That pass
relied on the ability to snoop on AA queries at different points in the
analysis group chain. Instead, I'm planning to build printing
functionality directly into the aggregation layer. I've not included
that in this patch merely to keep it smaller.
Note that all of this needs a nearly complete rewrite of the AA
documentation. I'm planning to do that, but I'd like to make sure the
new design settles, and to flesh out a bit more of what it looks like in
the new pass manager first.
Differential Revision: http://reviews.llvm.org/D12080
llvm-svn: 247167
2015-09-10 01:55:00 +08:00
|
|
|
|
|
|
|
GlobalsAAResult::GlobalsAAResult(GlobalsAAResult &&Arg)
|
Change TargetLibraryInfo analysis passes to always require Function
Summary:
This is the first change to enable the TLI to be built per-function so
that -fno-builtin* handling can be migrated to use function attributes.
See discussion on D61634 for background. This is an enabler for fixing
handling of these options for LTO, for example.
This change should not affect behavior, as the provided function is not
yet used to build a specifically per-function TLI, but rather enables
that migration.
Most of the changes were very mechanical, e.g. passing a Function to the
legacy analysis pass's getTLI interface, or in Module level cases,
adding a callback. This is similar to the way the per-function TTI
analysis works.
There was one place where we were looking for builtins but not in the
context of a specific function. See FindCXAAtExit in
lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround
could provide the wrong behavior in some corner cases. Suggestions
welcome.
Reviewers: chandlerc, hfinkel
Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66428
llvm-svn: 371284
2019-09-07 11:09:36 +08:00
|
|
|
: AAResultBase(std::move(Arg)), DL(Arg.DL), GetTLI(std::move(Arg.GetTLI)),
|
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() {}
|
|
|
|
|
Change TargetLibraryInfo analysis passes to always require Function
Summary:
This is the first change to enable the TLI to be built per-function so
that -fno-builtin* handling can be migrated to use function attributes.
See discussion on D61634 for background. This is an enabler for fixing
handling of these options for LTO, for example.
This change should not affect behavior, as the provided function is not
yet used to build a specifically per-function TLI, but rather enables
that migration.
Most of the changes were very mechanical, e.g. passing a Function to the
legacy analysis pass's getTLI interface, or in Module level cases,
adding a callback. This is similar to the way the per-function TTI
analysis works.
There was one place where we were looking for builtins but not in the
context of a specific function. See FindCXAAtExit in
lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround
could provide the wrong behavior in some corner cases. Suggestions
welcome.
Reviewers: chandlerc, hfinkel
Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66428
llvm-svn: 371284
2019-09-07 11:09:36 +08:00
|
|
|
/*static*/ GlobalsAAResult GlobalsAAResult::analyzeModule(
|
|
|
|
Module &M, std::function<const TargetLibraryInfo &(Function &F)> GetTLI,
|
|
|
|
CallGraph &CG) {
|
|
|
|
GlobalsAAResult Result(M.getDataLayout(), GetTLI);
|
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
with the new pass manager, and no longer relying on analysis groups.
This builds essentially a ground-up new AA infrastructure stack for
LLVM. The core ideas are the same that are used throughout the new pass
manager: type erased polymorphism and direct composition. The design is
as follows:
- FunctionAAResults is a type-erasing alias analysis results aggregation
interface to walk a single query across a range of results from
different alias analyses. Currently this is function-specific as we
always assume that aliasing queries are *within* a function.
- AAResultBase is a CRTP utility providing stub implementations of
various parts of the alias analysis result concept, notably in several
cases in terms of other more general parts of the interface. This can
be used to implement only a narrow part of the interface rather than
the entire interface. This isn't really ideal, this logic should be
hoisted into FunctionAAResults as currently it will cause
a significant amount of redundant work, but it faithfully models the
behavior of the prior infrastructure.
- All the alias analysis passes are ported to be wrapper passes for the
legacy PM and new-style analysis passes for the new PM with a shared
result object. In some cases (most notably CFL), this is an extremely
naive approach that we should revisit when we can specialize for the
new pass manager.
- BasicAA has been restructured to reflect that it is much more
fundamentally a function analysis because it uses dominator trees and
loop info that need to be constructed for each function.
All of the references to getting alias analysis results have been
updated to use the new aggregation interface. All the preservation and
other pass management code has been updated accordingly.
The way the FunctionAAResultsWrapperPass works is to detect the
available alias analyses when run, and add them to the results object.
This means that we should be able to continue to respect when various
passes are added to the pipeline, for example adding CFL or adding TBAA
passes should just cause their results to be available and to get folded
into this. The exception to this rule is BasicAA which really needs to
be a function pass due to using dominator trees and loop info. As
a consequence, the FunctionAAResultsWrapperPass directly depends on
BasicAA and always includes it in the aggregation.
This has significant implications for preserving analyses. Generally,
most passes shouldn't bother preserving FunctionAAResultsWrapperPass
because rebuilding the results just updates the set of known AA passes.
The exception to this rule are LoopPass instances which need to preserve
all the function analyses that the loop pass manager will end up
needing. This means preserving both BasicAAWrapperPass and the
aggregating FunctionAAResultsWrapperPass.
Now, when preserving an alias analysis, you do so by directly preserving
that analysis. This is only necessary for non-immutable-pass-provided
alias analyses though, and there are only three of interest: BasicAA,
GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
preserved when needed because it (like DominatorTree and LoopInfo) is
marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
set everywhere we previously were preserving all of AliasAnalysis, and
I've added SCEVAA in the intersection of that with where we preserve
SCEV itself.
One significant challenge to all of this is that the CGSCC passes were
actually using the alias analysis implementations by taking advantage of
a pretty amazing set of loop holes in the old pass manager's analysis
management code which allowed analysis groups to slide through in many
cases. Moving away from analysis groups makes this problem much more
obvious. To fix it, I've leveraged the flexibility the design of the new
PM components provides to just directly construct the relevant alias
analyses for the relevant functions in the IPO passes that need them.
This is a bit hacky, but should go away with the new pass manager, and
is already in many ways cleaner than the prior state.
Another significant challenge is that various facilities of the old
alias analysis infrastructure just don't fit any more. The most
significant of these is the alias analysis 'counter' pass. That pass
relied on the ability to snoop on AA queries at different points in the
analysis group chain. Instead, I'm planning to build printing
functionality directly into the aggregation layer. I've not included
that in this patch merely to keep it smaller.
Note that all of this needs a nearly complete rewrite of the AA
documentation. I'm planning to do that, but I'd like to make sure the
new design settles, and to flesh out a bit more of what it looks like in
the new pass manager first.
Differential Revision: http://reviews.llvm.org/D12080
llvm-svn: 247167
2015-09-10 01:55:00 +08:00
|
|
|
|
[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) {
|
Change TargetLibraryInfo analysis passes to always require Function
Summary:
This is the first change to enable the TLI to be built per-function so
that -fno-builtin* handling can be migrated to use function attributes.
See discussion on D61634 for background. This is an enabler for fixing
handling of these options for LTO, for example.
This change should not affect behavior, as the provided function is not
yet used to build a specifically per-function TLI, but rather enables
that migration.
Most of the changes were very mechanical, e.g. passing a Function to the
legacy analysis pass's getTLI interface, or in Module level cases,
adding a callback. This is similar to the way the per-function TTI
analysis works.
There was one place where we were looking for builtins but not in the
context of a specific function. See FindCXAAtExit in
lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround
could provide the wrong behavior in some corner cases. Suggestions
welcome.
Reviewers: chandlerc, hfinkel
Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66428
llvm-svn: 371284
2019-09-07 11:09:36 +08:00
|
|
|
FunctionAnalysisManager &FAM =
|
|
|
|
AM.getResult<FunctionAnalysisManagerModuleProxy>(M).getManager();
|
|
|
|
auto GetTLI = [&FAM](Function &F) -> TargetLibraryInfo & {
|
|
|
|
return FAM.getResult<TargetLibraryAnalysis>(F);
|
|
|
|
};
|
|
|
|
return GlobalsAAResult::analyzeModule(M, GetTLI,
|
2016-03-11 19:05:24 +08:00
|
|
|
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) {
|
Change TargetLibraryInfo analysis passes to always require Function
Summary:
This is the first change to enable the TLI to be built per-function so
that -fno-builtin* handling can be migrated to use function attributes.
See discussion on D61634 for background. This is an enabler for fixing
handling of these options for LTO, for example.
This change should not affect behavior, as the provided function is not
yet used to build a specifically per-function TLI, but rather enables
that migration.
Most of the changes were very mechanical, e.g. passing a Function to the
legacy analysis pass's getTLI interface, or in Module level cases,
adding a callback. This is similar to the way the per-function TTI
analysis works.
There was one place where we were looking for builtins but not in the
context of a specific function. See FindCXAAtExit in
lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround
could provide the wrong behavior in some corner cases. Suggestions
welcome.
Reviewers: chandlerc, hfinkel
Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66428
llvm-svn: 371284
2019-09-07 11:09:36 +08:00
|
|
|
auto GetTLI = [this](Function &F) -> TargetLibraryInfo & {
|
|
|
|
return this->getAnalysis<TargetLibraryInfoWrapperPass>().getTLI(F);
|
|
|
|
};
|
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
with the new pass manager, and no longer relying on analysis groups.
This builds essentially a ground-up new AA infrastructure stack for
LLVM. The core ideas are the same that are used throughout the new pass
manager: type erased polymorphism and direct composition. The design is
as follows:
- FunctionAAResults is a type-erasing alias analysis results aggregation
interface to walk a single query across a range of results from
different alias analyses. Currently this is function-specific as we
always assume that aliasing queries are *within* a function.
- AAResultBase is a CRTP utility providing stub implementations of
various parts of the alias analysis result concept, notably in several
cases in terms of other more general parts of the interface. This can
be used to implement only a narrow part of the interface rather than
the entire interface. This isn't really ideal, this logic should be
hoisted into FunctionAAResults as currently it will cause
a significant amount of redundant work, but it faithfully models the
behavior of the prior infrastructure.
- All the alias analysis passes are ported to be wrapper passes for the
legacy PM and new-style analysis passes for the new PM with a shared
result object. In some cases (most notably CFL), this is an extremely
naive approach that we should revisit when we can specialize for the
new pass manager.
- BasicAA has been restructured to reflect that it is much more
fundamentally a function analysis because it uses dominator trees and
loop info that need to be constructed for each function.
All of the references to getting alias analysis results have been
updated to use the new aggregation interface. All the preservation and
other pass management code has been updated accordingly.
The way the FunctionAAResultsWrapperPass works is to detect the
available alias analyses when run, and add them to the results object.
This means that we should be able to continue to respect when various
passes are added to the pipeline, for example adding CFL or adding TBAA
passes should just cause their results to be available and to get folded
into this. The exception to this rule is BasicAA which really needs to
be a function pass due to using dominator trees and loop info. As
a consequence, the FunctionAAResultsWrapperPass directly depends on
BasicAA and always includes it in the aggregation.
This has significant implications for preserving analyses. Generally,
most passes shouldn't bother preserving FunctionAAResultsWrapperPass
because rebuilding the results just updates the set of known AA passes.
The exception to this rule are LoopPass instances which need to preserve
all the function analyses that the loop pass manager will end up
needing. This means preserving both BasicAAWrapperPass and the
aggregating FunctionAAResultsWrapperPass.
Now, when preserving an alias analysis, you do so by directly preserving
that analysis. This is only necessary for non-immutable-pass-provided
alias analyses though, and there are only three of interest: BasicAA,
GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
preserved when needed because it (like DominatorTree and LoopInfo) is
marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
set everywhere we previously were preserving all of AliasAnalysis, and
I've added SCEVAA in the intersection of that with where we preserve
SCEV itself.
One significant challenge to all of this is that the CGSCC passes were
actually using the alias analysis implementations by taking advantage of
a pretty amazing set of loop holes in the old pass manager's analysis
management code which allowed analysis groups to slide through in many
cases. Moving away from analysis groups makes this problem much more
obvious. To fix it, I've leveraged the flexibility the design of the new
PM components provides to just directly construct the relevant alias
analyses for the relevant functions in the IPO passes that need them.
This is a bit hacky, but should go away with the new pass manager, and
is already in many ways cleaner than the prior state.
Another significant challenge is that various facilities of the old
alias analysis infrastructure just don't fit any more. The most
significant of these is the alias analysis 'counter' pass. That pass
relied on the ability to snoop on AA queries at different points in the
analysis group chain. Instead, I'm planning to build printing
functionality directly into the aggregation layer. I've not included
that in this patch merely to keep it smaller.
Note that all of this needs a nearly complete rewrite of the AA
documentation. I'm planning to do that, but I'd like to make sure the
new design settles, and to flesh out a bit more of what it looks like in
the new pass manager first.
Differential Revision: http://reviews.llvm.org/D12080
llvm-svn: 247167
2015-09-10 01:55:00 +08:00
|
|
|
Result.reset(new GlobalsAAResult(GlobalsAAResult::analyzeModule(
|
Change TargetLibraryInfo analysis passes to always require Function
Summary:
This is the first change to enable the TLI to be built per-function so
that -fno-builtin* handling can be migrated to use function attributes.
See discussion on D61634 for background. This is an enabler for fixing
handling of these options for LTO, for example.
This change should not affect behavior, as the provided function is not
yet used to build a specifically per-function TLI, but rather enables
that migration.
Most of the changes were very mechanical, e.g. passing a Function to the
legacy analysis pass's getTLI interface, or in Module level cases,
adding a callback. This is similar to the way the per-function TTI
analysis works.
There was one place where we were looking for builtins but not in the
context of a specific function. See FindCXAAtExit in
lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround
could provide the wrong behavior in some corner cases. Suggestions
welcome.
Reviewers: chandlerc, hfinkel
Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66428
llvm-svn: 371284
2019-09-07 11:09:36 +08:00
|
|
|
M, GetTLI, getAnalysis<CallGraphWrapperPass>().getCallGraph())));
|
[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 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
|
|
|
}
|