2013-03-21 08:55:59 +08:00
|
|
|
//===- FunctionAttrs.cpp - Pass which marks functions attributes ----------===//
|
2008-09-19 16:17:05 +08:00
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
2016-01-08 18:55:52 +08:00
|
|
|
///
|
|
|
|
/// \file
|
|
|
|
/// This file implements interprocedural passes which walk the
|
|
|
|
/// call-graph deducing and/or propagating function attributes.
|
|
|
|
///
|
2008-09-19 16:17:05 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2016-02-18 19:03:11 +08:00
|
|
|
#include "llvm/Transforms/IPO/FunctionAttrs.h"
|
2008-09-19 16:17:05 +08:00
|
|
|
#include "llvm/Transforms/IPO.h"
|
2011-12-29 07:24:21 +08:00
|
|
|
#include "llvm/ADT/SCCIterator.h"
|
2012-10-31 21:45:49 +08:00
|
|
|
#include "llvm/ADT/SetVector.h"
|
2009-01-02 19:54:37 +08:00
|
|
|
#include "llvm/ADT/SmallSet.h"
|
2008-09-19 16:17:05 +08:00
|
|
|
#include "llvm/ADT/Statistic.h"
|
2015-11-19 16:49:57 +08:00
|
|
|
#include "llvm/ADT/StringSwitch.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/Analysis/AliasAnalysis.h"
|
2016-12-19 16:22:17 +08:00
|
|
|
#include "llvm/Analysis/AssumptionCache.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/BasicAliasAnalysis.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/Analysis/CallGraph.h"
|
2013-01-07 23:26:48 +08:00
|
|
|
#include "llvm/Analysis/CallGraphSCCPass.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/Analysis/CaptureTracking.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"
|
2015-09-01 03:44:38 +08:00
|
|
|
#include "llvm/Analysis/ValueTracking.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/GlobalVariable.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/IntrinsicInst.h"
|
|
|
|
#include "llvm/IR/LLVMContext.h"
|
2015-09-01 03:44:38 +08:00
|
|
|
#include "llvm/Support/Debug.h"
|
2015-09-01 05:19:18 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2015-01-15 10:16:27 +08:00
|
|
|
#include "llvm/Analysis/TargetLibraryInfo.h"
|
2008-09-19 16:17:05 +08:00
|
|
|
using namespace llvm;
|
|
|
|
|
2014-04-22 10:55:47 +08:00
|
|
|
#define DEBUG_TYPE "functionattrs"
|
|
|
|
|
2008-09-19 16:17:05 +08:00
|
|
|
STATISTIC(NumReadNone, "Number of functions marked readnone");
|
|
|
|
STATISTIC(NumReadOnly, "Number of functions marked readonly");
|
2009-01-01 00:14:43 +08:00
|
|
|
STATISTIC(NumNoCapture, "Number of arguments marked nocapture");
|
2016-07-20 02:50:26 +08:00
|
|
|
STATISTIC(NumReturned, "Number of arguments marked returned");
|
2013-07-06 08:29:58 +08:00
|
|
|
STATISTIC(NumReadNoneArg, "Number of arguments marked readnone");
|
|
|
|
STATISTIC(NumReadOnlyArg, "Number of arguments marked readonly");
|
2009-03-08 14:20:47 +08:00
|
|
|
STATISTIC(NumNoAlias, "Number of function returns marked noalias");
|
2015-09-01 03:44:38 +08:00
|
|
|
STATISTIC(NumNonNullReturn, "Number of function returns marked nonnull");
|
2015-11-12 18:55:20 +08:00
|
|
|
STATISTIC(NumNoRecurse, "Number of functions marked as norecurse");
|
2008-09-19 16:17:05 +08:00
|
|
|
|
2017-02-14 07:10:51 +08:00
|
|
|
// FIXME: This is disabled by default to avoid exposing security vulnerabilities
|
|
|
|
// in C/C++ code compiled by clang:
|
|
|
|
// http://lists.llvm.org/pipermail/cfe-dev/2017-January/052066.html
|
|
|
|
static cl::opt<bool> EnableNonnullArgPropagation(
|
|
|
|
"enable-nonnull-arg-prop", cl::Hidden,
|
|
|
|
cl::desc("Try to propagate nonnull argument attributes from callsites to "
|
|
|
|
"caller functions."));
|
|
|
|
|
2015-10-30 02:29:15 +08:00
|
|
|
namespace {
|
|
|
|
typedef SmallSetVector<Function *, 8> SCCNodeSet;
|
|
|
|
}
|
|
|
|
|
2017-02-14 08:28:13 +08:00
|
|
|
/// Returns the memory access attribute for function F using AAR for AA results,
|
|
|
|
/// where SCCNodes is the current SCC.
|
|
|
|
///
|
|
|
|
/// If ThisBody is true, this function may examine the function body and will
|
|
|
|
/// return a result pertaining to this copy of the function. If it is false, the
|
|
|
|
/// result will be based only on AA results for the function declaration; it
|
|
|
|
/// will be assumed that some other (perhaps less optimized) version of the
|
|
|
|
/// function may be selected at link time.
|
|
|
|
static MemoryAccessKind checkFunctionMemoryAccess(Function &F, bool ThisBody,
|
|
|
|
AAResults &AAR,
|
2015-10-30 02:29:15 +08:00
|
|
|
const SCCNodeSet &SCCNodes) {
|
2015-09-22 01:39:41 +08:00
|
|
|
FunctionModRefBehavior MRB = AAR.getModRefBehavior(&F);
|
|
|
|
if (MRB == FMRB_DoesNotAccessMemory)
|
|
|
|
// Already perfect!
|
|
|
|
return MAK_ReadNone;
|
|
|
|
|
2017-02-14 08:28:13 +08:00
|
|
|
if (!ThisBody) {
|
2015-09-22 01:39:41 +08:00
|
|
|
if (AliasAnalysis::onlyReadsMemory(MRB))
|
|
|
|
return MAK_ReadOnly;
|
|
|
|
|
|
|
|
// Conservatively assume it writes to memory.
|
|
|
|
return MAK_MayWrite;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Scan the function body for instructions that may read or write memory.
|
|
|
|
bool ReadsMemory = false;
|
|
|
|
for (inst_iterator II = inst_begin(F), E = inst_end(F); II != E; ++II) {
|
|
|
|
Instruction *I = &*II;
|
|
|
|
|
|
|
|
// Some instructions can be ignored even if they read or write memory.
|
|
|
|
// Detect these now, skipping to the next instruction if one is found.
|
|
|
|
CallSite CS(cast<Value>(I));
|
|
|
|
if (CS) {
|
2016-02-10 02:40:40 +08:00
|
|
|
// Ignore calls to functions in the same SCC, as long as the call sites
|
|
|
|
// don't have operand bundles. Calls with operand bundles are allowed to
|
|
|
|
// have memory effects not described by the memory effects of the call
|
|
|
|
// target.
|
|
|
|
if (!CS.hasOperandBundles() && CS.getCalledFunction() &&
|
|
|
|
SCCNodes.count(CS.getCalledFunction()))
|
2015-09-22 01:39:41 +08:00
|
|
|
continue;
|
|
|
|
FunctionModRefBehavior MRB = AAR.getModRefBehavior(CS);
|
2015-10-27 09:41:43 +08:00
|
|
|
|
|
|
|
// If the call doesn't access memory, we're done.
|
|
|
|
if (!(MRB & MRI_ModRef))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!AliasAnalysis::onlyAccessesArgPointees(MRB)) {
|
|
|
|
// The call could access any memory. If that includes writes, give up.
|
|
|
|
if (MRB & MRI_Mod)
|
|
|
|
return MAK_MayWrite;
|
|
|
|
// If it reads, note it.
|
|
|
|
if (MRB & MRI_Ref)
|
|
|
|
ReadsMemory = true;
|
2015-09-22 01:39:41 +08:00
|
|
|
continue;
|
|
|
|
}
|
2015-10-27 09:41:43 +08:00
|
|
|
|
|
|
|
// Check whether all pointer arguments point to local memory, and
|
|
|
|
// ignore calls that only access local memory.
|
|
|
|
for (CallSite::arg_iterator CI = CS.arg_begin(), CE = CS.arg_end();
|
|
|
|
CI != CE; ++CI) {
|
|
|
|
Value *Arg = *CI;
|
2015-11-18 03:30:51 +08:00
|
|
|
if (!Arg->getType()->isPtrOrPtrVectorTy())
|
2015-10-27 09:41:43 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
AAMDNodes AAInfo;
|
|
|
|
I->getAAMetadata(AAInfo);
|
|
|
|
MemoryLocation Loc(Arg, MemoryLocation::UnknownSize, AAInfo);
|
|
|
|
|
|
|
|
// Skip accesses to local or constant memory as they don't impact the
|
|
|
|
// externally visible mod/ref behavior.
|
|
|
|
if (AAR.pointsToConstantMemory(Loc, /*OrLocal=*/true))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (MRB & MRI_Mod)
|
|
|
|
// Writes non-local memory. Give up.
|
|
|
|
return MAK_MayWrite;
|
|
|
|
if (MRB & MRI_Ref)
|
|
|
|
// Ok, it reads non-local memory.
|
|
|
|
ReadsMemory = true;
|
|
|
|
}
|
2015-09-22 01:39:41 +08:00
|
|
|
continue;
|
|
|
|
} else if (LoadInst *LI = dyn_cast<LoadInst>(I)) {
|
|
|
|
// Ignore non-volatile loads from local memory. (Atomic is okay here.)
|
|
|
|
if (!LI->isVolatile()) {
|
|
|
|
MemoryLocation Loc = MemoryLocation::get(LI);
|
|
|
|
if (AAR.pointsToConstantMemory(Loc, /*OrLocal=*/true))
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
} else if (StoreInst *SI = dyn_cast<StoreInst>(I)) {
|
|
|
|
// Ignore non-volatile stores to local memory. (Atomic is okay here.)
|
|
|
|
if (!SI->isVolatile()) {
|
|
|
|
MemoryLocation Loc = MemoryLocation::get(SI);
|
|
|
|
if (AAR.pointsToConstantMemory(Loc, /*OrLocal=*/true))
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
} else if (VAArgInst *VI = dyn_cast<VAArgInst>(I)) {
|
|
|
|
// Ignore vaargs on local memory.
|
|
|
|
MemoryLocation Loc = MemoryLocation::get(VI);
|
|
|
|
if (AAR.pointsToConstantMemory(Loc, /*OrLocal=*/true))
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Any remaining instructions need to be taken seriously! Check if they
|
|
|
|
// read or write memory.
|
|
|
|
if (I->mayWriteToMemory())
|
|
|
|
// Writes memory. Just give up.
|
|
|
|
return MAK_MayWrite;
|
|
|
|
|
|
|
|
// If this instruction may read memory, remember that.
|
|
|
|
ReadsMemory |= I->mayReadFromMemory();
|
|
|
|
}
|
|
|
|
|
|
|
|
return ReadsMemory ? MAK_ReadOnly : MAK_ReadNone;
|
|
|
|
}
|
|
|
|
|
2017-02-14 08:28:13 +08:00
|
|
|
MemoryAccessKind llvm::computeFunctionBodyMemoryAccess(Function &F,
|
|
|
|
AAResults &AAR) {
|
|
|
|
return checkFunctionMemoryAccess(F, /*ThisBody=*/true, AAR, {});
|
|
|
|
}
|
|
|
|
|
2015-09-13 14:57:25 +08:00
|
|
|
/// Deduce readonly/readnone attributes for the SCC.
|
2015-10-31 00:48:08 +08:00
|
|
|
template <typename AARGetterT>
|
2017-02-10 07:11:52 +08:00
|
|
|
static bool addReadAttrs(const SCCNodeSet &SCCNodes, AARGetterT &&AARGetter) {
|
2008-09-29 21:35:31 +08:00
|
|
|
// Check if any of the functions in the SCC read or write memory. If they
|
|
|
|
// write memory then they can't be marked readnone or readonly.
|
2008-09-19 16:17:05 +08:00
|
|
|
bool ReadsMemory = false;
|
2015-10-30 02:29:15 +08:00
|
|
|
for (Function *F : SCCNodes) {
|
2015-10-31 00:48:08 +08:00
|
|
|
// Call the callable parameter to look up AA results for this function.
|
|
|
|
AAResults &AAR = AARGetter(*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
|
|
|
|
2017-02-14 08:28:13 +08:00
|
|
|
// Non-exact function definitions may not be selected at link time, and an
|
|
|
|
// alternative version that writes to memory may be selected. See the
|
|
|
|
// comment on GlobalValue::isDefinitionExact for more details.
|
|
|
|
switch (checkFunctionMemoryAccess(*F, F->hasExactDefinition(),
|
|
|
|
AAR, SCCNodes)) {
|
2015-09-22 01:39:41 +08:00
|
|
|
case MAK_MayWrite:
|
|
|
|
return false;
|
|
|
|
case MAK_ReadOnly:
|
2008-09-19 16:17:05 +08:00
|
|
|
ReadsMemory = true;
|
2015-09-22 01:39:41 +08:00
|
|
|
break;
|
|
|
|
case MAK_ReadNone:
|
|
|
|
// Nothing to do!
|
|
|
|
break;
|
2008-09-19 16:17:05 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Success! Functions in this SCC do not access memory, or only read memory.
|
|
|
|
// Give them the appropriate attribute.
|
|
|
|
bool MadeChange = false;
|
2015-10-30 02:29:15 +08:00
|
|
|
for (Function *F : SCCNodes) {
|
2008-09-19 16:17:05 +08:00
|
|
|
if (F->doesNotAccessMemory())
|
|
|
|
// Already perfect!
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (F->onlyReadsMemory() && ReadsMemory)
|
|
|
|
// No change.
|
|
|
|
continue;
|
|
|
|
|
|
|
|
MadeChange = true;
|
|
|
|
|
|
|
|
// Clear out any existing attributes.
|
2017-04-20 01:28:52 +08:00
|
|
|
F->removeFnAttr(Attribute::ReadOnly);
|
|
|
|
F->removeFnAttr(Attribute::ReadNone);
|
2008-09-19 16:17:05 +08:00
|
|
|
|
|
|
|
// Add in the new attribute.
|
2017-04-20 01:28:52 +08:00
|
|
|
F->addFnAttr(ReadsMemory ? Attribute::ReadOnly : Attribute::ReadNone);
|
2008-09-19 16:17:05 +08:00
|
|
|
|
|
|
|
if (ReadsMemory)
|
2009-01-02 19:46:24 +08:00
|
|
|
++NumReadOnly;
|
2008-09-19 16:17:05 +08:00
|
|
|
else
|
2009-01-02 19:46:24 +08:00
|
|
|
++NumReadNone;
|
2008-09-19 16:17:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return MadeChange;
|
|
|
|
}
|
2009-01-01 00:14:43 +08:00
|
|
|
|
2011-12-29 07:24:21 +08:00
|
|
|
namespace {
|
2015-09-13 14:57:25 +08:00
|
|
|
/// For a given pointer Argument, this retains a list of Arguments of functions
|
|
|
|
/// in the same SCC that the pointer data flows into. We use this to build an
|
|
|
|
/// SCC of the arguments.
|
2015-09-13 14:47:20 +08:00
|
|
|
struct ArgumentGraphNode {
|
|
|
|
Argument *Definition;
|
|
|
|
SmallVector<ArgumentGraphNode *, 4> Uses;
|
|
|
|
};
|
|
|
|
|
|
|
|
class ArgumentGraph {
|
|
|
|
// We store pointers to ArgumentGraphNode objects, so it's important that
|
|
|
|
// that they not move around upon insert.
|
|
|
|
typedef std::map<Argument *, ArgumentGraphNode> ArgumentMapTy;
|
|
|
|
|
|
|
|
ArgumentMapTy ArgumentMap;
|
|
|
|
|
|
|
|
// There is no root node for the argument graph, in fact:
|
|
|
|
// void f(int *x, int *y) { if (...) f(x, y); }
|
|
|
|
// is an example where the graph is disconnected. The SCCIterator requires a
|
|
|
|
// single entry point, so we maintain a fake ("synthetic") root node that
|
|
|
|
// uses every node. Because the graph is directed and nothing points into
|
|
|
|
// the root, it will not participate in any SCCs (except for its own).
|
|
|
|
ArgumentGraphNode SyntheticRoot;
|
|
|
|
|
|
|
|
public:
|
|
|
|
ArgumentGraph() { SyntheticRoot.Definition = nullptr; }
|
|
|
|
|
|
|
|
typedef SmallVectorImpl<ArgumentGraphNode *>::iterator iterator;
|
|
|
|
|
|
|
|
iterator begin() { return SyntheticRoot.Uses.begin(); }
|
|
|
|
iterator end() { return SyntheticRoot.Uses.end(); }
|
|
|
|
ArgumentGraphNode *getEntryNode() { return &SyntheticRoot; }
|
|
|
|
|
|
|
|
ArgumentGraphNode *operator[](Argument *A) {
|
|
|
|
ArgumentGraphNode &Node = ArgumentMap[A];
|
|
|
|
Node.Definition = A;
|
|
|
|
SyntheticRoot.Uses.push_back(&Node);
|
|
|
|
return &Node;
|
|
|
|
}
|
|
|
|
};
|
2011-12-29 07:24:21 +08:00
|
|
|
|
2015-09-13 14:57:25 +08:00
|
|
|
/// This tracker checks whether callees are in the SCC, and if so it does not
|
|
|
|
/// consider that a capture, instead adding it to the "Uses" list and
|
|
|
|
/// continuing with the analysis.
|
2015-09-13 14:47:20 +08:00
|
|
|
struct ArgumentUsesTracker : public CaptureTracker {
|
2015-10-30 02:29:15 +08:00
|
|
|
ArgumentUsesTracker(const SCCNodeSet &SCCNodes)
|
2011-12-29 07:24:21 +08:00
|
|
|
: Captured(false), SCCNodes(SCCNodes) {}
|
|
|
|
|
2015-09-13 14:47:20 +08:00
|
|
|
void tooManyUses() override { Captured = true; }
|
2011-12-29 07:24:21 +08:00
|
|
|
|
2015-09-13 14:47:20 +08:00
|
|
|
bool captured(const Use *U) override {
|
|
|
|
CallSite CS(U->getUser());
|
|
|
|
if (!CS.getInstruction()) {
|
|
|
|
Captured = true;
|
|
|
|
return true;
|
|
|
|
}
|
2011-12-29 07:24:21 +08:00
|
|
|
|
2015-09-13 14:47:20 +08:00
|
|
|
Function *F = CS.getCalledFunction();
|
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
|
|
|
if (!F || !F->hasExactDefinition() || !SCCNodes.count(F)) {
|
2015-09-13 14:47:20 +08:00
|
|
|
Captured = true;
|
|
|
|
return true;
|
|
|
|
}
|
2011-12-29 07:24:21 +08:00
|
|
|
|
2015-11-05 11:04:40 +08:00
|
|
|
// Note: the callee and the two successor blocks *follow* the argument
|
|
|
|
// operands. This means there is no need to adjust UseIndex to account for
|
|
|
|
// these.
|
|
|
|
|
|
|
|
unsigned UseIndex =
|
|
|
|
std::distance(const_cast<const Use *>(CS.arg_begin()), U);
|
|
|
|
|
2015-11-07 09:56:00 +08:00
|
|
|
assert(UseIndex < CS.data_operands_size() &&
|
|
|
|
"Indirect function calls should have been filtered above!");
|
|
|
|
|
|
|
|
if (UseIndex >= CS.getNumArgOperands()) {
|
|
|
|
// Data operand, but not a argument operand -- must be a bundle operand
|
|
|
|
assert(CS.hasOperandBundles() && "Must be!");
|
|
|
|
|
|
|
|
// CaptureTracking told us that we're being captured by an operand bundle
|
|
|
|
// use. In this case it does not matter if the callee is within our SCC
|
|
|
|
// or not -- we've been captured in some unknown way, and we have to be
|
|
|
|
// conservative.
|
|
|
|
Captured = true;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-11-05 11:04:40 +08:00
|
|
|
if (UseIndex >= F->arg_size()) {
|
|
|
|
assert(F->isVarArg() && "More params than args in non-varargs call");
|
|
|
|
Captured = true;
|
|
|
|
return true;
|
2011-12-29 07:24:21 +08:00
|
|
|
}
|
2015-11-05 11:04:40 +08:00
|
|
|
|
2015-11-07 08:01:16 +08:00
|
|
|
Uses.push_back(&*std::next(F->arg_begin(), UseIndex));
|
2015-09-13 14:47:20 +08:00
|
|
|
return false;
|
|
|
|
}
|
2011-12-29 07:24:21 +08:00
|
|
|
|
2015-09-13 14:47:20 +08:00
|
|
|
bool Captured; // True only if certainly captured (used outside our SCC).
|
|
|
|
SmallVector<Argument *, 4> Uses; // Uses within our SCC.
|
2011-12-29 07:24:21 +08:00
|
|
|
|
2015-10-30 02:29:15 +08:00
|
|
|
const SCCNodeSet &SCCNodes;
|
2015-09-13 14:47:20 +08:00
|
|
|
};
|
2015-06-23 17:49:53 +08:00
|
|
|
}
|
2011-12-29 07:24:21 +08:00
|
|
|
|
|
|
|
namespace llvm {
|
2015-09-13 14:47:20 +08:00
|
|
|
template <> struct GraphTraits<ArgumentGraphNode *> {
|
2016-08-02 06:32:20 +08:00
|
|
|
typedef ArgumentGraphNode *NodeRef;
|
2015-09-13 14:47:20 +08:00
|
|
|
typedef SmallVectorImpl<ArgumentGraphNode *>::iterator ChildIteratorType;
|
2011-12-29 07:24:21 +08:00
|
|
|
|
2016-09-01 00:48:13 +08:00
|
|
|
static NodeRef getEntryNode(NodeRef A) { return A; }
|
|
|
|
static ChildIteratorType child_begin(NodeRef N) { return N->Uses.begin(); }
|
|
|
|
static ChildIteratorType child_end(NodeRef N) { return N->Uses.end(); }
|
2015-09-13 14:47:20 +08:00
|
|
|
};
|
|
|
|
template <>
|
|
|
|
struct GraphTraits<ArgumentGraph *> : public GraphTraits<ArgumentGraphNode *> {
|
2016-08-23 05:09:30 +08:00
|
|
|
static NodeRef getEntryNode(ArgumentGraph *AG) { return AG->getEntryNode(); }
|
2015-09-13 14:47:20 +08:00
|
|
|
static ChildIteratorType nodes_begin(ArgumentGraph *AG) {
|
|
|
|
return AG->begin();
|
|
|
|
}
|
|
|
|
static ChildIteratorType nodes_end(ArgumentGraph *AG) { return AG->end(); }
|
|
|
|
};
|
2015-06-23 17:49:53 +08:00
|
|
|
}
|
2011-12-29 07:24:21 +08:00
|
|
|
|
2015-09-13 14:57:25 +08:00
|
|
|
/// Returns Attribute::None, Attribute::ReadOnly or Attribute::ReadNone.
|
2013-07-06 08:29:58 +08:00
|
|
|
static Attribute::AttrKind
|
|
|
|
determinePointerReadAttrs(Argument *A,
|
2015-09-13 14:47:20 +08:00
|
|
|
const SmallPtrSet<Argument *, 8> &SCCNodes) {
|
|
|
|
|
|
|
|
SmallVector<Use *, 32> Worklist;
|
|
|
|
SmallSet<Use *, 32> Visited;
|
2013-07-06 08:29:58 +08:00
|
|
|
|
2014-01-28 10:38:36 +08:00
|
|
|
// inalloca arguments are always clobbered by the call.
|
|
|
|
if (A->hasInAllocaAttr())
|
|
|
|
return Attribute::None;
|
|
|
|
|
2013-07-06 08:29:58 +08:00
|
|
|
bool IsRead = false;
|
|
|
|
// We don't need to track IsWritten. If A is written to, return immediately.
|
|
|
|
|
2014-03-09 11:16:01 +08:00
|
|
|
for (Use &U : A->uses()) {
|
|
|
|
Visited.insert(&U);
|
|
|
|
Worklist.push_back(&U);
|
2013-07-06 08:29:58 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
while (!Worklist.empty()) {
|
|
|
|
Use *U = Worklist.pop_back_val();
|
|
|
|
Instruction *I = cast<Instruction>(U->getUser());
|
|
|
|
|
|
|
|
switch (I->getOpcode()) {
|
|
|
|
case Instruction::BitCast:
|
|
|
|
case Instruction::GetElementPtr:
|
|
|
|
case Instruction::PHI:
|
|
|
|
case Instruction::Select:
|
2014-01-15 03:11:52 +08:00
|
|
|
case Instruction::AddrSpaceCast:
|
2013-07-06 08:29:58 +08:00
|
|
|
// The original value is not read/written via this if the new value isn't.
|
2014-03-09 11:16:01 +08:00
|
|
|
for (Use &UU : I->uses())
|
2014-11-19 15:49:26 +08:00
|
|
|
if (Visited.insert(&UU).second)
|
2014-03-09 11:16:01 +08:00
|
|
|
Worklist.push_back(&UU);
|
2013-07-06 08:29:58 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case Instruction::Call:
|
|
|
|
case Instruction::Invoke: {
|
2014-05-30 10:31:27 +08:00
|
|
|
bool Captures = true;
|
|
|
|
|
|
|
|
if (I->getType()->isVoidTy())
|
|
|
|
Captures = false;
|
|
|
|
|
|
|
|
auto AddUsersToWorklistIfCapturing = [&] {
|
|
|
|
if (Captures)
|
|
|
|
for (Use &UU : I->uses())
|
2014-11-19 15:49:26 +08:00
|
|
|
if (Visited.insert(&UU).second)
|
2014-05-30 10:31:27 +08:00
|
|
|
Worklist.push_back(&UU);
|
|
|
|
};
|
|
|
|
|
2013-07-06 08:29:58 +08:00
|
|
|
CallSite CS(I);
|
2014-05-30 10:31:27 +08:00
|
|
|
if (CS.doesNotAccessMemory()) {
|
|
|
|
AddUsersToWorklistIfCapturing();
|
2013-07-06 08:29:58 +08:00
|
|
|
continue;
|
2014-05-30 10:31:27 +08:00
|
|
|
}
|
2013-07-06 08:29:58 +08:00
|
|
|
|
|
|
|
Function *F = CS.getCalledFunction();
|
|
|
|
if (!F) {
|
|
|
|
if (CS.onlyReadsMemory()) {
|
|
|
|
IsRead = true;
|
2014-05-30 10:31:27 +08:00
|
|
|
AddUsersToWorklistIfCapturing();
|
2013-07-06 08:29:58 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
return Attribute::None;
|
|
|
|
}
|
|
|
|
|
2015-11-07 09:55:53 +08:00
|
|
|
// Note: the callee and the two successor blocks *follow* the argument
|
|
|
|
// operands. This means there is no need to adjust UseIndex to account
|
|
|
|
// for these.
|
|
|
|
|
|
|
|
unsigned UseIndex = std::distance(CS.arg_begin(), U);
|
|
|
|
|
2015-11-07 09:56:07 +08:00
|
|
|
// U cannot be the callee operand use: since we're exploring the
|
|
|
|
// transitive uses of an Argument, having such a use be a callee would
|
|
|
|
// imply the CallSite is an indirect call or invoke; and we'd take the
|
|
|
|
// early exit above.
|
|
|
|
assert(UseIndex < CS.data_operands_size() &&
|
|
|
|
"Data operand use expected!");
|
2015-11-07 09:56:00 +08:00
|
|
|
|
|
|
|
bool IsOperandBundleUse = UseIndex >= CS.getNumArgOperands();
|
|
|
|
|
|
|
|
if (UseIndex >= F->arg_size() && !IsOperandBundleUse) {
|
2015-11-07 09:55:53 +08:00
|
|
|
assert(F->isVarArg() && "More params than args in non-varargs call");
|
|
|
|
return Attribute::None;
|
2013-07-06 08:29:58 +08:00
|
|
|
}
|
2015-11-07 09:55:53 +08:00
|
|
|
|
2015-11-21 03:17:10 +08:00
|
|
|
Captures &= !CS.doesNotCapture(UseIndex);
|
|
|
|
|
2015-11-07 09:56:00 +08:00
|
|
|
// Since the optimizer (by design) cannot see the data flow corresponding
|
|
|
|
// to a operand bundle use, these cannot participate in the optimistic SCC
|
|
|
|
// analysis. Instead, we model the operand bundle uses as arguments in
|
|
|
|
// call to a function external to the SCC.
|
2016-08-17 09:23:58 +08:00
|
|
|
if (IsOperandBundleUse ||
|
|
|
|
!SCCNodes.count(&*std::next(F->arg_begin(), UseIndex))) {
|
2015-11-07 09:56:00 +08:00
|
|
|
|
|
|
|
// The accessors used on CallSite here do the right thing for calls and
|
|
|
|
// invokes with operand bundles.
|
|
|
|
|
2015-11-07 09:55:53 +08:00
|
|
|
if (!CS.onlyReadsMemory() && !CS.onlyReadsMemory(UseIndex))
|
|
|
|
return Attribute::None;
|
|
|
|
if (!CS.doesNotAccessMemory(UseIndex))
|
|
|
|
IsRead = true;
|
|
|
|
}
|
|
|
|
|
2014-05-30 10:31:27 +08:00
|
|
|
AddUsersToWorklistIfCapturing();
|
2013-07-06 08:29:58 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
case Instruction::Load:
|
2016-05-25 13:53:04 +08:00
|
|
|
// A volatile load has side effects beyond what readonly can be relied
|
|
|
|
// upon.
|
|
|
|
if (cast<LoadInst>(I)->isVolatile())
|
|
|
|
return Attribute::None;
|
|
|
|
|
2013-07-06 08:29:58 +08:00
|
|
|
IsRead = true;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Instruction::ICmp:
|
|
|
|
case Instruction::Ret:
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
return Attribute::None;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return IsRead ? Attribute::ReadOnly : Attribute::ReadNone;
|
|
|
|
}
|
|
|
|
|
2016-07-20 02:50:26 +08:00
|
|
|
/// Deduce returned attributes for the SCC.
|
|
|
|
static bool addArgumentReturnedAttrs(const SCCNodeSet &SCCNodes) {
|
|
|
|
bool Changed = false;
|
|
|
|
|
|
|
|
// Check each function in turn, determining if an argument is always returned.
|
|
|
|
for (Function *F : SCCNodes) {
|
|
|
|
// We can infer and propagate function attributes only when we know that the
|
|
|
|
// definition we'll get at link time is *exactly* the definition we see now.
|
|
|
|
// For more details, see GlobalValue::mayBeDerefined.
|
|
|
|
if (!F->hasExactDefinition())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (F->getReturnType()->isVoidTy())
|
|
|
|
continue;
|
|
|
|
|
2016-09-13 00:04:59 +08:00
|
|
|
// There is nothing to do if an argument is already marked as 'returned'.
|
|
|
|
if (any_of(F->args(),
|
|
|
|
[](const Argument &Arg) { return Arg.hasReturnedAttr(); }))
|
|
|
|
continue;
|
|
|
|
|
2016-07-20 02:50:26 +08:00
|
|
|
auto FindRetArg = [&]() -> Value * {
|
|
|
|
Value *RetArg = nullptr;
|
|
|
|
for (BasicBlock &BB : *F)
|
|
|
|
if (auto *Ret = dyn_cast<ReturnInst>(BB.getTerminator())) {
|
|
|
|
// Note that stripPointerCasts should look through functions with
|
|
|
|
// returned arguments.
|
|
|
|
Value *RetVal = Ret->getReturnValue()->stripPointerCasts();
|
|
|
|
if (!isa<Argument>(RetVal) || RetVal->getType() != F->getReturnType())
|
|
|
|
return nullptr;
|
|
|
|
|
|
|
|
if (!RetArg)
|
|
|
|
RetArg = RetVal;
|
|
|
|
else if (RetArg != RetVal)
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
return RetArg;
|
|
|
|
};
|
|
|
|
|
|
|
|
if (Value *RetArg = FindRetArg()) {
|
|
|
|
auto *A = cast<Argument>(RetArg);
|
2017-04-20 01:28:52 +08:00
|
|
|
A->addAttr(Attribute::Returned);
|
2016-07-20 02:50:26 +08:00
|
|
|
++NumReturned;
|
|
|
|
Changed = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return Changed;
|
|
|
|
}
|
|
|
|
|
2017-02-14 07:10:51 +08:00
|
|
|
/// If a callsite has arguments that are also arguments to the parent function,
|
|
|
|
/// try to propagate attributes from the callsite's arguments to the parent's
|
|
|
|
/// arguments. This may be important because inlining can cause information loss
|
|
|
|
/// when attribute knowledge disappears with the inlined call.
|
|
|
|
static bool addArgumentAttrsFromCallsites(Function &F) {
|
|
|
|
if (!EnableNonnullArgPropagation)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
bool Changed = false;
|
|
|
|
|
|
|
|
// For an argument attribute to transfer from a callsite to the parent, the
|
|
|
|
// call must be guaranteed to execute every time the parent is called.
|
|
|
|
// Conservatively, just check for calls in the entry block that are guaranteed
|
|
|
|
// to execute.
|
|
|
|
// TODO: This could be enhanced by testing if the callsite post-dominates the
|
|
|
|
// entry block or by doing simple forward walks or backward walks to the
|
|
|
|
// callsite.
|
|
|
|
BasicBlock &Entry = F.getEntryBlock();
|
|
|
|
for (Instruction &I : Entry) {
|
|
|
|
if (auto CS = CallSite(&I)) {
|
|
|
|
if (auto *CalledFunc = CS.getCalledFunction()) {
|
|
|
|
for (auto &CSArg : CalledFunc->args()) {
|
|
|
|
if (!CSArg.hasNonNullAttr())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// If the non-null callsite argument operand is an argument to 'F'
|
|
|
|
// (the caller) and the call is guaranteed to execute, then the value
|
|
|
|
// must be non-null throughout 'F'.
|
|
|
|
auto *FArg = dyn_cast<Argument>(CS.getArgOperand(CSArg.getArgNo()));
|
|
|
|
if (FArg && !FArg->hasNonNullAttr()) {
|
|
|
|
FArg->addAttr(Attribute::NonNull);
|
|
|
|
Changed = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!isGuaranteedToTransferExecutionToSuccessor(&I))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return Changed;
|
|
|
|
}
|
|
|
|
|
2015-09-13 14:57:25 +08:00
|
|
|
/// Deduce nocapture attributes for the SCC.
|
2015-10-30 02:29:15 +08:00
|
|
|
static bool addArgumentAttrs(const SCCNodeSet &SCCNodes) {
|
2009-01-01 00:14:43 +08:00
|
|
|
bool Changed = false;
|
|
|
|
|
2011-12-29 07:24:21 +08:00
|
|
|
ArgumentGraph AG;
|
|
|
|
|
2009-01-01 00:14:43 +08:00
|
|
|
// Check each function in turn, determining which pointer arguments are not
|
|
|
|
// captured.
|
2015-10-30 02:29:15 +08:00
|
|
|
for (Function *F : SCCNodes) {
|
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
|
|
|
// We can infer and propagate function attributes only when we know that the
|
|
|
|
// definition we'll get at link time is *exactly* the definition we see now.
|
|
|
|
// For more details, see GlobalValue::mayBeDerefined.
|
|
|
|
if (!F->hasExactDefinition())
|
2009-01-01 00:14:43 +08:00
|
|
|
continue;
|
|
|
|
|
2017-02-14 07:10:51 +08:00
|
|
|
Changed |= addArgumentAttrsFromCallsites(*F);
|
|
|
|
|
2011-12-29 07:24:21 +08:00
|
|
|
// Functions that are readonly (or readnone) and nounwind and don't return
|
|
|
|
// a value can't capture arguments. Don't analyze them.
|
|
|
|
if (F->onlyReadsMemory() && F->doesNotThrow() &&
|
|
|
|
F->getReturnType()->isVoidTy()) {
|
2015-09-13 14:47:20 +08:00
|
|
|
for (Function::arg_iterator A = F->arg_begin(), E = F->arg_end(); A != E;
|
|
|
|
++A) {
|
2013-06-23 00:56:32 +08:00
|
|
|
if (A->getType()->isPointerTy() && !A->hasNoCaptureAttr()) {
|
2017-04-20 01:28:52 +08:00
|
|
|
A->addAttr(Attribute::NoCapture);
|
2013-06-23 00:56:32 +08:00
|
|
|
++NumNoCapture;
|
|
|
|
Changed = true;
|
|
|
|
}
|
2011-12-29 07:24:21 +08:00
|
|
|
}
|
2013-06-23 00:56:32 +08:00
|
|
|
continue;
|
|
|
|
}
|
2011-12-29 07:24:21 +08:00
|
|
|
|
2015-09-13 14:47:20 +08:00
|
|
|
for (Function::arg_iterator A = F->arg_begin(), E = F->arg_end(); A != E;
|
|
|
|
++A) {
|
|
|
|
if (!A->getType()->isPointerTy())
|
|
|
|
continue;
|
2013-07-06 08:29:58 +08:00
|
|
|
bool HasNonLocalUses = false;
|
|
|
|
if (!A->hasNoCaptureAttr()) {
|
2011-12-29 07:24:21 +08:00
|
|
|
ArgumentUsesTracker Tracker(SCCNodes);
|
2015-10-14 01:51:03 +08:00
|
|
|
PointerMayBeCaptured(&*A, &Tracker);
|
2013-06-23 00:56:32 +08:00
|
|
|
if (!Tracker.Captured) {
|
|
|
|
if (Tracker.Uses.empty()) {
|
|
|
|
// If it's trivially not captured, mark it nocapture now.
|
2017-04-20 01:28:52 +08:00
|
|
|
A->addAttr(Attribute::NoCapture);
|
2013-06-23 00:56:32 +08:00
|
|
|
++NumNoCapture;
|
|
|
|
Changed = true;
|
|
|
|
} else {
|
|
|
|
// If it's not trivially captured and not trivially not captured,
|
|
|
|
// then it must be calling into another function in our SCC. Save
|
|
|
|
// its particulars for Argument-SCC analysis later.
|
2015-10-14 01:51:03 +08:00
|
|
|
ArgumentGraphNode *Node = AG[&*A];
|
2016-06-26 20:28:59 +08:00
|
|
|
for (Argument *Use : Tracker.Uses) {
|
|
|
|
Node->Uses.push_back(AG[Use]);
|
|
|
|
if (Use != &*A)
|
2013-07-06 08:29:58 +08:00
|
|
|
HasNonLocalUses = true;
|
|
|
|
}
|
2013-06-23 00:56:32 +08:00
|
|
|
}
|
2011-12-29 07:24:21 +08:00
|
|
|
}
|
2013-06-23 00:56:32 +08:00
|
|
|
// Otherwise, it's captured. Don't bother doing SCC analysis on it.
|
2011-12-29 07:24:21 +08:00
|
|
|
}
|
2013-07-06 08:29:58 +08:00
|
|
|
if (!HasNonLocalUses && !A->onlyReadsMemory()) {
|
|
|
|
// Can we determine that it's readonly/readnone without doing an SCC?
|
|
|
|
// Note that we don't allow any calls at all here, or else our result
|
|
|
|
// will be dependent on the iteration order through the functions in the
|
|
|
|
// SCC.
|
2015-09-13 14:47:20 +08:00
|
|
|
SmallPtrSet<Argument *, 8> Self;
|
2015-10-14 01:51:03 +08:00
|
|
|
Self.insert(&*A);
|
|
|
|
Attribute::AttrKind R = determinePointerReadAttrs(&*A, Self);
|
2013-07-06 08:29:58 +08:00
|
|
|
if (R != Attribute::None) {
|
2017-04-20 01:28:52 +08:00
|
|
|
A->addAttr(R);
|
2013-07-06 08:29:58 +08:00
|
|
|
Changed = true;
|
|
|
|
R == Attribute::ReadOnly ? ++NumReadOnlyArg : ++NumReadNoneArg;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2011-12-29 07:24:21 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// The graph we've collected is partial because we stopped scanning for
|
|
|
|
// argument uses once we solved the argument trivially. These partial nodes
|
|
|
|
// show up as ArgumentGraphNode objects with an empty Uses list, and for
|
|
|
|
// these nodes the final decision about whether they capture has already been
|
|
|
|
// made. If the definition doesn't have a 'nocapture' attribute by now, it
|
|
|
|
// captures.
|
|
|
|
|
2015-09-13 14:47:20 +08:00
|
|
|
for (scc_iterator<ArgumentGraph *> I = scc_begin(&AG); !I.isAtEnd(); ++I) {
|
2014-04-26 02:24:50 +08:00
|
|
|
const std::vector<ArgumentGraphNode *> &ArgumentSCC = *I;
|
2011-12-29 07:24:21 +08:00
|
|
|
if (ArgumentSCC.size() == 1) {
|
2015-09-13 14:47:20 +08:00
|
|
|
if (!ArgumentSCC[0]->Definition)
|
|
|
|
continue; // synthetic root node
|
2011-12-29 07:24:21 +08:00
|
|
|
|
|
|
|
// eg. "void f(int* x) { if (...) f(x); }"
|
|
|
|
if (ArgumentSCC[0]->Uses.size() == 1 &&
|
|
|
|
ArgumentSCC[0]->Uses[0] == ArgumentSCC[0]) {
|
2013-07-06 08:29:58 +08:00
|
|
|
Argument *A = ArgumentSCC[0]->Definition;
|
2017-04-20 01:28:52 +08:00
|
|
|
A->addAttr(Attribute::NoCapture);
|
2009-01-02 11:46:56 +08:00
|
|
|
++NumNoCapture;
|
2009-01-01 00:14:43 +08:00
|
|
|
Changed = true;
|
|
|
|
}
|
2011-12-29 07:24:21 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool SCCCaptured = false;
|
2014-04-26 02:24:50 +08:00
|
|
|
for (auto I = ArgumentSCC.begin(), E = ArgumentSCC.end();
|
|
|
|
I != E && !SCCCaptured; ++I) {
|
2011-12-29 07:24:21 +08:00
|
|
|
ArgumentGraphNode *Node = *I;
|
|
|
|
if (Node->Uses.empty()) {
|
|
|
|
if (!Node->Definition->hasNoCaptureAttr())
|
|
|
|
SCCCaptured = true;
|
|
|
|
}
|
|
|
|
}
|
2015-09-13 14:47:20 +08:00
|
|
|
if (SCCCaptured)
|
|
|
|
continue;
|
2011-12-29 07:24:21 +08:00
|
|
|
|
2015-09-13 14:47:20 +08:00
|
|
|
SmallPtrSet<Argument *, 8> ArgumentSCCNodes;
|
2011-12-29 07:24:21 +08:00
|
|
|
// Fill ArgumentSCCNodes with the elements of the ArgumentSCC. Used for
|
|
|
|
// quickly looking up whether a given Argument is in this ArgumentSCC.
|
2016-06-26 20:28:59 +08:00
|
|
|
for (ArgumentGraphNode *I : ArgumentSCC) {
|
|
|
|
ArgumentSCCNodes.insert(I->Definition);
|
2011-12-29 07:24:21 +08:00
|
|
|
}
|
|
|
|
|
2014-04-26 02:24:50 +08:00
|
|
|
for (auto I = ArgumentSCC.begin(), E = ArgumentSCC.end();
|
|
|
|
I != E && !SCCCaptured; ++I) {
|
2011-12-29 07:24:21 +08:00
|
|
|
ArgumentGraphNode *N = *I;
|
2016-06-26 20:28:59 +08:00
|
|
|
for (ArgumentGraphNode *Use : N->Uses) {
|
|
|
|
Argument *A = Use->Definition;
|
2011-12-29 07:24:21 +08:00
|
|
|
if (A->hasNoCaptureAttr() || ArgumentSCCNodes.count(A))
|
|
|
|
continue;
|
|
|
|
SCCCaptured = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2015-09-13 14:47:20 +08:00
|
|
|
if (SCCCaptured)
|
|
|
|
continue;
|
2011-12-29 07:24:21 +08:00
|
|
|
|
2012-01-06 06:21:45 +08:00
|
|
|
for (unsigned i = 0, e = ArgumentSCC.size(); i != e; ++i) {
|
2011-12-29 07:24:21 +08:00
|
|
|
Argument *A = ArgumentSCC[i]->Definition;
|
2017-04-20 01:28:52 +08:00
|
|
|
A->addAttr(Attribute::NoCapture);
|
2011-12-29 07:24:21 +08:00
|
|
|
++NumNoCapture;
|
|
|
|
Changed = true;
|
|
|
|
}
|
2013-07-06 08:29:58 +08:00
|
|
|
|
|
|
|
// We also want to compute readonly/readnone. With a small number of false
|
|
|
|
// negatives, we can assume that any pointer which is captured isn't going
|
|
|
|
// to be provably readonly or readnone, since by definition we can't
|
|
|
|
// analyze all uses of a captured pointer.
|
|
|
|
//
|
|
|
|
// The false negatives happen when the pointer is captured by a function
|
|
|
|
// that promises readonly/readnone behaviour on the pointer, then the
|
|
|
|
// pointer's lifetime ends before anything that writes to arbitrary memory.
|
|
|
|
// Also, a readonly/readnone pointer may be returned, but returning a
|
|
|
|
// pointer is capturing it.
|
|
|
|
|
|
|
|
Attribute::AttrKind ReadAttr = Attribute::ReadNone;
|
|
|
|
for (unsigned i = 0, e = ArgumentSCC.size(); i != e; ++i) {
|
|
|
|
Argument *A = ArgumentSCC[i]->Definition;
|
|
|
|
Attribute::AttrKind K = determinePointerReadAttrs(A, ArgumentSCCNodes);
|
|
|
|
if (K == Attribute::ReadNone)
|
|
|
|
continue;
|
|
|
|
if (K == Attribute::ReadOnly) {
|
|
|
|
ReadAttr = Attribute::ReadOnly;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
ReadAttr = K;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ReadAttr != Attribute::None) {
|
|
|
|
for (unsigned i = 0, e = ArgumentSCC.size(); i != e; ++i) {
|
|
|
|
Argument *A = ArgumentSCC[i]->Definition;
|
2015-05-26 03:46:38 +08:00
|
|
|
// Clear out existing readonly/readnone attributes
|
2017-04-20 01:28:52 +08:00
|
|
|
A->removeAttr(Attribute::ReadOnly);
|
|
|
|
A->removeAttr(Attribute::ReadNone);
|
|
|
|
A->addAttr(ReadAttr);
|
2013-07-06 08:29:58 +08:00
|
|
|
ReadAttr == Attribute::ReadOnly ? ++NumReadOnlyArg : ++NumReadNoneArg;
|
|
|
|
Changed = true;
|
|
|
|
}
|
|
|
|
}
|
2009-01-01 00:14:43 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return Changed;
|
|
|
|
}
|
|
|
|
|
2015-09-13 14:57:25 +08:00
|
|
|
/// Tests whether a function is "malloc-like".
|
|
|
|
///
|
|
|
|
/// A function is "malloc-like" if it returns either null or a pointer that
|
|
|
|
/// doesn't alias any other pointer visible to the caller.
|
2015-10-30 02:29:15 +08:00
|
|
|
static bool isFunctionMallocLike(Function *F, const SCCNodeSet &SCCNodes) {
|
2012-10-31 21:45:49 +08:00
|
|
|
SmallSetVector<Value *, 8> FlowsToReturn;
|
2016-06-26 20:28:59 +08:00
|
|
|
for (BasicBlock &BB : *F)
|
|
|
|
if (ReturnInst *Ret = dyn_cast<ReturnInst>(BB.getTerminator()))
|
2009-03-08 14:20:47 +08:00
|
|
|
FlowsToReturn.insert(Ret->getReturnValue());
|
|
|
|
|
|
|
|
for (unsigned i = 0; i != FlowsToReturn.size(); ++i) {
|
2012-10-31 21:45:49 +08:00
|
|
|
Value *RetVal = FlowsToReturn[i];
|
2009-03-08 14:20:47 +08:00
|
|
|
|
|
|
|
if (Constant *C = dyn_cast<Constant>(RetVal)) {
|
|
|
|
if (!C->isNullValue() && !isa<UndefValue>(C))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (isa<Argument>(RetVal))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (Instruction *RVI = dyn_cast<Instruction>(RetVal))
|
|
|
|
switch (RVI->getOpcode()) {
|
2015-09-13 14:47:20 +08:00
|
|
|
// Extend the analysis by looking upwards.
|
|
|
|
case Instruction::BitCast:
|
|
|
|
case Instruction::GetElementPtr:
|
|
|
|
case Instruction::AddrSpaceCast:
|
|
|
|
FlowsToReturn.insert(RVI->getOperand(0));
|
|
|
|
continue;
|
|
|
|
case Instruction::Select: {
|
|
|
|
SelectInst *SI = cast<SelectInst>(RVI);
|
|
|
|
FlowsToReturn.insert(SI->getTrueValue());
|
|
|
|
FlowsToReturn.insert(SI->getFalseValue());
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
case Instruction::PHI: {
|
|
|
|
PHINode *PN = cast<PHINode>(RVI);
|
|
|
|
for (Value *IncValue : PN->incoming_values())
|
|
|
|
FlowsToReturn.insert(IncValue);
|
|
|
|
continue;
|
|
|
|
}
|
2009-03-08 14:20:47 +08:00
|
|
|
|
2015-09-13 14:47:20 +08:00
|
|
|
// Check whether the pointer came from an allocation.
|
|
|
|
case Instruction::Alloca:
|
|
|
|
break;
|
|
|
|
case Instruction::Call:
|
|
|
|
case Instruction::Invoke: {
|
|
|
|
CallSite CS(RVI);
|
2017-04-15 04:19:02 +08:00
|
|
|
if (CS.hasRetAttr(Attribute::NoAlias))
|
2009-03-08 14:20:47 +08:00
|
|
|
break;
|
2015-09-13 14:47:20 +08:00
|
|
|
if (CS.getCalledFunction() && SCCNodes.count(CS.getCalledFunction()))
|
|
|
|
break;
|
2016-08-18 04:30:52 +08:00
|
|
|
LLVM_FALLTHROUGH;
|
|
|
|
}
|
2015-09-13 14:47:20 +08:00
|
|
|
default:
|
|
|
|
return false; // Did not come from an allocation.
|
2009-03-08 14:20:47 +08:00
|
|
|
}
|
|
|
|
|
2009-11-20 05:57:48 +08:00
|
|
|
if (PointerMayBeCaptured(RetVal, false, /*StoreCaptures=*/false))
|
2009-03-08 14:20:47 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-09-13 14:57:25 +08:00
|
|
|
/// Deduce noalias attributes for the SCC.
|
2015-10-30 02:29:15 +08:00
|
|
|
static bool addNoAliasAttrs(const SCCNodeSet &SCCNodes) {
|
2009-03-09 01:08:09 +08:00
|
|
|
// Check each function in turn, determining which functions return noalias
|
|
|
|
// pointers.
|
2015-10-30 02:29:15 +08:00
|
|
|
for (Function *F : SCCNodes) {
|
2009-03-08 14:20:47 +08:00
|
|
|
// Already noalias.
|
2017-05-04 02:17:31 +08:00
|
|
|
if (F->returnDoesNotAlias())
|
2009-03-08 14:20:47 +08:00
|
|
|
continue;
|
|
|
|
|
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
|
|
|
// We can infer and propagate function attributes only when we know that the
|
|
|
|
// definition we'll get at link time is *exactly* the definition we see now.
|
|
|
|
// For more details, see GlobalValue::mayBeDerefined.
|
|
|
|
if (!F->hasExactDefinition())
|
2009-03-08 14:20:47 +08:00
|
|
|
return false;
|
|
|
|
|
2015-09-13 14:47:20 +08:00
|
|
|
// We annotate noalias return values, which are only applicable to
|
2009-03-08 14:20:47 +08:00
|
|
|
// pointer types.
|
2010-02-16 19:11:14 +08:00
|
|
|
if (!F->getReturnType()->isPointerTy())
|
2009-03-08 14:20:47 +08:00
|
|
|
continue;
|
|
|
|
|
2015-09-13 16:23:27 +08:00
|
|
|
if (!isFunctionMallocLike(F, SCCNodes))
|
2009-03-08 14:20:47 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool MadeChange = false;
|
2015-10-30 02:29:15 +08:00
|
|
|
for (Function *F : SCCNodes) {
|
2017-05-04 02:17:31 +08:00
|
|
|
if (F->returnDoesNotAlias() ||
|
2017-04-29 02:37:16 +08:00
|
|
|
!F->getReturnType()->isPointerTy())
|
2009-03-08 14:20:47 +08:00
|
|
|
continue;
|
|
|
|
|
2017-05-04 02:17:31 +08:00
|
|
|
F->setReturnDoesNotAlias();
|
2009-03-08 14:20:47 +08:00
|
|
|
++NumNoAlias;
|
|
|
|
MadeChange = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return MadeChange;
|
|
|
|
}
|
|
|
|
|
2015-09-13 14:57:25 +08:00
|
|
|
/// Tests whether this function is known to not return null.
|
2015-09-13 16:17:14 +08:00
|
|
|
///
|
|
|
|
/// Requires that the function returns a pointer.
|
|
|
|
///
|
|
|
|
/// Returns true if it believes the function will not return a null, and sets
|
|
|
|
/// \p Speculative based on whether the returned conclusion is a speculative
|
|
|
|
/// conclusion due to SCC calls.
|
2015-10-30 02:29:15 +08:00
|
|
|
static bool isReturnNonNull(Function *F, const SCCNodeSet &SCCNodes,
|
2016-07-03 07:47:27 +08:00
|
|
|
bool &Speculative) {
|
2015-09-01 03:44:38 +08:00
|
|
|
assert(F->getReturnType()->isPointerTy() &&
|
|
|
|
"nonnull only meaningful on pointer types");
|
|
|
|
Speculative = false;
|
2015-09-13 14:47:20 +08:00
|
|
|
|
2015-09-01 03:44:38 +08:00
|
|
|
SmallSetVector<Value *, 8> FlowsToReturn;
|
|
|
|
for (BasicBlock &BB : *F)
|
|
|
|
if (auto *Ret = dyn_cast<ReturnInst>(BB.getTerminator()))
|
|
|
|
FlowsToReturn.insert(Ret->getReturnValue());
|
|
|
|
|
|
|
|
for (unsigned i = 0; i != FlowsToReturn.size(); ++i) {
|
|
|
|
Value *RetVal = FlowsToReturn[i];
|
|
|
|
|
|
|
|
// If this value is locally known to be non-null, we're good
|
2016-07-03 07:47:27 +08:00
|
|
|
if (isKnownNonNull(RetVal))
|
2015-09-01 03:44:38 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
// Otherwise, we need to look upwards since we can't make any local
|
2015-09-13 14:47:20 +08:00
|
|
|
// conclusions.
|
2015-09-01 03:44:38 +08:00
|
|
|
Instruction *RVI = dyn_cast<Instruction>(RetVal);
|
|
|
|
if (!RVI)
|
|
|
|
return false;
|
|
|
|
switch (RVI->getOpcode()) {
|
2015-09-13 14:47:20 +08:00
|
|
|
// Extend the analysis by looking upwards.
|
2015-09-01 03:44:38 +08:00
|
|
|
case Instruction::BitCast:
|
|
|
|
case Instruction::GetElementPtr:
|
|
|
|
case Instruction::AddrSpaceCast:
|
|
|
|
FlowsToReturn.insert(RVI->getOperand(0));
|
|
|
|
continue;
|
|
|
|
case Instruction::Select: {
|
|
|
|
SelectInst *SI = cast<SelectInst>(RVI);
|
|
|
|
FlowsToReturn.insert(SI->getTrueValue());
|
|
|
|
FlowsToReturn.insert(SI->getFalseValue());
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
case Instruction::PHI: {
|
|
|
|
PHINode *PN = cast<PHINode>(RVI);
|
|
|
|
for (int i = 0, e = PN->getNumIncomingValues(); i != e; ++i)
|
|
|
|
FlowsToReturn.insert(PN->getIncomingValue(i));
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
case Instruction::Call:
|
|
|
|
case Instruction::Invoke: {
|
|
|
|
CallSite CS(RVI);
|
|
|
|
Function *Callee = CS.getCalledFunction();
|
|
|
|
// A call to a node within the SCC is assumed to return null until
|
|
|
|
// proven otherwise
|
|
|
|
if (Callee && SCCNodes.count(Callee)) {
|
|
|
|
Speculative = true;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
default:
|
2015-09-13 14:47:20 +08:00
|
|
|
return false; // Unknown source, may be null
|
2015-09-01 03:44:38 +08:00
|
|
|
};
|
|
|
|
llvm_unreachable("should have either continued or returned");
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-09-13 14:57:25 +08:00
|
|
|
/// Deduce nonnull attributes for the SCC.
|
2016-07-03 07:47:27 +08:00
|
|
|
static bool addNonNullAttrs(const SCCNodeSet &SCCNodes) {
|
2015-09-01 03:44:38 +08:00
|
|
|
// Speculative that all functions in the SCC return only nonnull
|
|
|
|
// pointers. We may refute this as we analyze functions.
|
|
|
|
bool SCCReturnsNonNull = true;
|
|
|
|
|
|
|
|
bool MadeChange = false;
|
|
|
|
|
|
|
|
// Check each function in turn, determining which functions return nonnull
|
|
|
|
// pointers.
|
2015-10-30 02:29:15 +08:00
|
|
|
for (Function *F : SCCNodes) {
|
2015-09-01 03:44:38 +08:00
|
|
|
// Already nonnull.
|
Rename AttributeSet to AttributeList
Summary:
This class is a list of AttributeSetNodes corresponding the function
prototype of a call or function declaration. This class used to be
called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is
typically accessed by parameter and return value index, so
"AttributeList" seems like a more intuitive name.
Rename AttributeSetImpl to AttributeListImpl to follow suit.
It's useful to rename this class so that we can rename AttributeSetNode
to AttributeSet later. AttributeSet is the set of attributes that apply
to a single function, argument, or return value.
Reviewers: sanjoy, javed.absar, chandlerc, pete
Reviewed By: pete
Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits
Differential Revision: https://reviews.llvm.org/D31102
llvm-svn: 298393
2017-03-22 00:57:19 +08:00
|
|
|
if (F->getAttributes().hasAttribute(AttributeList::ReturnIndex,
|
2015-09-01 03:44:38 +08:00
|
|
|
Attribute::NonNull))
|
|
|
|
continue;
|
|
|
|
|
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
|
|
|
// We can infer and propagate function attributes only when we know that the
|
|
|
|
// definition we'll get at link time is *exactly* the definition we see now.
|
|
|
|
// For more details, see GlobalValue::mayBeDerefined.
|
|
|
|
if (!F->hasExactDefinition())
|
2015-09-01 03:44:38 +08:00
|
|
|
return false;
|
|
|
|
|
2015-09-13 14:47:20 +08:00
|
|
|
// We annotate nonnull return values, which are only applicable to
|
2015-09-01 03:44:38 +08:00
|
|
|
// pointer types.
|
|
|
|
if (!F->getReturnType()->isPointerTy())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
bool Speculative = false;
|
2016-07-03 07:47:27 +08:00
|
|
|
if (isReturnNonNull(F, SCCNodes, Speculative)) {
|
2015-09-01 03:44:38 +08:00
|
|
|
if (!Speculative) {
|
|
|
|
// Mark the function eagerly since we may discover a function
|
|
|
|
// which prevents us from speculating about the entire SCC
|
|
|
|
DEBUG(dbgs() << "Eagerly marking " << F->getName() << " as nonnull\n");
|
Rename AttributeSet to AttributeList
Summary:
This class is a list of AttributeSetNodes corresponding the function
prototype of a call or function declaration. This class used to be
called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is
typically accessed by parameter and return value index, so
"AttributeList" seems like a more intuitive name.
Rename AttributeSetImpl to AttributeListImpl to follow suit.
It's useful to rename this class so that we can rename AttributeSetNode
to AttributeSet later. AttributeSet is the set of attributes that apply
to a single function, argument, or return value.
Reviewers: sanjoy, javed.absar, chandlerc, pete
Reviewed By: pete
Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits
Differential Revision: https://reviews.llvm.org/D31102
llvm-svn: 298393
2017-03-22 00:57:19 +08:00
|
|
|
F->addAttribute(AttributeList::ReturnIndex, Attribute::NonNull);
|
2015-09-01 03:44:38 +08:00
|
|
|
++NumNonNullReturn;
|
|
|
|
MadeChange = true;
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
// At least one function returns something which could be null, can't
|
|
|
|
// speculate any more.
|
|
|
|
SCCReturnsNonNull = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (SCCReturnsNonNull) {
|
2015-10-30 02:29:15 +08:00
|
|
|
for (Function *F : SCCNodes) {
|
Rename AttributeSet to AttributeList
Summary:
This class is a list of AttributeSetNodes corresponding the function
prototype of a call or function declaration. This class used to be
called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is
typically accessed by parameter and return value index, so
"AttributeList" seems like a more intuitive name.
Rename AttributeSetImpl to AttributeListImpl to follow suit.
It's useful to rename this class so that we can rename AttributeSetNode
to AttributeSet later. AttributeSet is the set of attributes that apply
to a single function, argument, or return value.
Reviewers: sanjoy, javed.absar, chandlerc, pete
Reviewed By: pete
Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits
Differential Revision: https://reviews.llvm.org/D31102
llvm-svn: 298393
2017-03-22 00:57:19 +08:00
|
|
|
if (F->getAttributes().hasAttribute(AttributeList::ReturnIndex,
|
2015-09-01 03:44:38 +08:00
|
|
|
Attribute::NonNull) ||
|
|
|
|
!F->getReturnType()->isPointerTy())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
DEBUG(dbgs() << "SCC marking " << F->getName() << " as nonnull\n");
|
Rename AttributeSet to AttributeList
Summary:
This class is a list of AttributeSetNodes corresponding the function
prototype of a call or function declaration. This class used to be
called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is
typically accessed by parameter and return value index, so
"AttributeList" seems like a more intuitive name.
Rename AttributeSetImpl to AttributeListImpl to follow suit.
It's useful to rename this class so that we can rename AttributeSetNode
to AttributeSet later. AttributeSet is the set of attributes that apply
to a single function, argument, or return value.
Reviewers: sanjoy, javed.absar, chandlerc, pete
Reviewed By: pete
Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits
Differential Revision: https://reviews.llvm.org/D31102
llvm-svn: 298393
2017-03-22 00:57:19 +08:00
|
|
|
F->addAttribute(AttributeList::ReturnIndex, Attribute::NonNull);
|
2015-09-01 03:44:38 +08:00
|
|
|
++NumNonNullReturn;
|
|
|
|
MadeChange = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return MadeChange;
|
|
|
|
}
|
|
|
|
|
2016-03-15 04:18:54 +08:00
|
|
|
/// Remove the convergent attribute from all functions in the SCC if every
|
|
|
|
/// callsite within the SCC is not convergent (except for calls to functions
|
|
|
|
/// within the SCC). Returns true if changes were made.
|
2016-02-12 17:47:49 +08:00
|
|
|
static bool removeConvergentAttrs(const SCCNodeSet &SCCNodes) {
|
2016-03-15 04:18:54 +08:00
|
|
|
// For every function in SCC, ensure that either
|
|
|
|
// * it is not convergent, or
|
|
|
|
// * we can remove its convergent attribute.
|
|
|
|
bool HasConvergentFn = false;
|
|
|
|
for (Function *F : SCCNodes) {
|
|
|
|
if (!F->isConvergent()) continue;
|
|
|
|
HasConvergentFn = true;
|
|
|
|
|
|
|
|
// Can't remove convergent from function declarations.
|
|
|
|
if (F->isDeclaration()) return false;
|
|
|
|
|
|
|
|
// Can't remove convergent if any of our functions has a convergent call to a
|
|
|
|
// function not in the SCC.
|
|
|
|
for (Instruction &I : instructions(*F)) {
|
|
|
|
CallSite CS(&I);
|
|
|
|
// Bail if CS is a convergent call to a function not in the SCC.
|
|
|
|
if (CS && CS.isConvergent() &&
|
|
|
|
SCCNodes.count(CS.getCalledFunction()) == 0)
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
2016-02-23 02:24:43 +08:00
|
|
|
|
2016-03-15 04:18:54 +08:00
|
|
|
// If the SCC doesn't have any convergent functions, we have nothing to do.
|
|
|
|
if (!HasConvergentFn) return false;
|
2016-02-23 01:51:35 +08:00
|
|
|
|
2016-03-15 04:18:54 +08:00
|
|
|
// If we got here, all of the calls the SCC makes to functions not in the SCC
|
|
|
|
// are non-convergent. Therefore all of the SCC's functions can also be made
|
|
|
|
// non-convergent. We'll remove the attr from the callsites in
|
|
|
|
// InstCombineCalls.
|
2016-02-12 17:47:49 +08:00
|
|
|
for (Function *F : SCCNodes) {
|
2016-03-15 04:18:54 +08:00
|
|
|
if (!F->isConvergent()) continue;
|
|
|
|
|
|
|
|
DEBUG(dbgs() << "Removing convergent attr from fn " << F->getName()
|
|
|
|
<< "\n");
|
2016-02-12 17:47:49 +08:00
|
|
|
F->setNotConvergent();
|
|
|
|
}
|
2016-02-10 07:03:22 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-11-12 18:55:20 +08:00
|
|
|
static bool setDoesNotRecurse(Function &F) {
|
|
|
|
if (F.doesNotRecurse())
|
|
|
|
return false;
|
|
|
|
F.setDoesNotRecurse();
|
|
|
|
++NumNoRecurse;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2016-02-13 16:47:51 +08:00
|
|
|
static bool addNoRecurseAttrs(const SCCNodeSet &SCCNodes) {
|
2015-11-12 18:55:20 +08:00
|
|
|
// Try and identify functions that do not recurse.
|
|
|
|
|
|
|
|
// If the SCC contains multiple nodes we know for sure there is recursion.
|
2016-02-13 16:47:51 +08:00
|
|
|
if (SCCNodes.size() != 1)
|
2015-11-12 18:55:20 +08:00
|
|
|
return false;
|
|
|
|
|
2016-02-13 16:47:51 +08:00
|
|
|
Function *F = *SCCNodes.begin();
|
2015-11-12 18:55:20 +08:00
|
|
|
if (!F || F->isDeclaration() || F->doesNotRecurse())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// If all of the calls in F are identifiable and are to norecurse functions, F
|
|
|
|
// is norecurse. This check also detects self-recursion as F is not currently
|
|
|
|
// marked norecurse, so any called from F to F will not be marked norecurse.
|
2016-02-13 16:47:51 +08:00
|
|
|
for (Instruction &I : instructions(*F))
|
|
|
|
if (auto CS = CallSite(&I)) {
|
|
|
|
Function *Callee = CS.getCalledFunction();
|
|
|
|
if (!Callee || Callee == F || !Callee->doesNotRecurse())
|
|
|
|
// Function calls a potentially recursive function.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Every call was to a non-recursive function other than this function, and
|
|
|
|
// we have no indirect recursion as the SCC size is one. This function cannot
|
|
|
|
// recurse.
|
|
|
|
return setDoesNotRecurse(*F);
|
2015-11-12 18:55:20 +08:00
|
|
|
}
|
|
|
|
|
2016-03-11 19:05:24 +08:00
|
|
|
PreservedAnalyses PostOrderFunctionAttrsPass::run(LazyCallGraph::SCC &C,
|
[PM] Introduce basic update capabilities to the new PM's CGSCC pass
manager, including both plumbing and logic to handle function pass
updates.
There are three fundamentally tied changes here:
1) Plumbing *some* mechanism for updating the CGSCC pass manager as the
CG changes while passes are running.
2) Changing the CGSCC pass manager infrastructure to have support for
the underlying graph to mutate mid-pass run.
3) Actually updating the CG after function passes run.
I can separate them if necessary, but I think its really useful to have
them together as the needs of #3 drove #2, and that in turn drove #1.
The plumbing technique is to extend the "run" method signature with
extra arguments. We provide the call graph that intrinsically is
available as it is the basis of the pass manager's IR units, and an
output parameter that records the results of updating the call graph
during an SCC passes's run. Note that "...UpdateResult" isn't a *great*
name here... suggestions very welcome.
I tried a pretty frustrating number of different data structures and such
for the innards of the update result. Every other one failed for one
reason or another. Sometimes I just couldn't keep the layers of
complexity right in my head. The thing that really worked was to just
directly provide access to the underlying structures used to walk the
call graph so that their updates could be informed by the *particular*
nature of the change to the graph.
The technique for how to make the pass management infrastructure cope
with mutating graphs was also something that took a really, really large
number of iterations to get to a place where I was happy. Here are some
of the considerations that drove the design:
- We operate at three levels within the infrastructure: RefSCC, SCC, and
Node. In each case, we are working bottom up and so we want to
continue to iterate on the "lowest" node as the graph changes. Look at
how we iterate over nodes in an SCC running function passes as those
function passes mutate the CG. We continue to iterate on the "lowest"
SCC, which is the one that continues to contain the function just
processed.
- The call graph structure re-uses SCCs (and RefSCCs) during mutation
events for the *highest* entry in the resulting new subgraph, not the
lowest. This means that it is necessary to continually update the
current SCC or RefSCC as it shifts. This is really surprising and
subtle, and took a long time for me to work out. I actually tried
changing the call graph to provide the opposite behavior, and it
breaks *EVERYTHING*. The graph update algorithms are really deeply
tied to this particualr pattern.
- When SCCs or RefSCCs are split apart and refined and we continually
re-pin our processing to the bottom one in the subgraph, we need to
enqueue the newly formed SCCs and RefSCCs for subsequent processing.
Queuing them presents a few challenges:
1) SCCs and RefSCCs use wildly different iteration strategies at
a high level. We end up needing to converge them on worklist
approaches that can be extended in order to be able to handle the
mutations.
2) The order of the enqueuing need to remain bottom-up post-order so
that we don't get surprising order of visitation for things like
the inliner.
3) We need the worklists to have set semantics so we don't duplicate
things endlessly. We don't need a *persistent* set though because
we always keep processing the bottom node!!!! This is super, super
surprising to me and took a long time to convince myself this is
correct, but I'm pretty sure it is... Once we sink down to the
bottom node, we can't re-split out the same node in any way, and
the postorder of the current queue is fixed and unchanging.
4) We need to make sure that the "current" SCC or RefSCC actually gets
enqueued here such that we re-visit it because we continue
processing a *new*, *bottom* SCC/RefSCC.
- We also need the ability to *skip* SCCs and RefSCCs that get merged
into a larger component. We even need the ability to skip *nodes* from
an SCC that are no longer part of that SCC.
This led to the design you see in the patch which uses SetVector-based
worklists. The RefSCC worklist is always empty until an update occurs
and is just used to handle those RefSCCs created by updates as the
others don't even exist yet and are formed on-demand during the
bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and
we push new SCCs onto it and blacklist existing SCCs on it to get the
desired processing.
We then *directly* update these when updating the call graph as I was
never able to find a satisfactory abstraction around the update
strategy.
Finally, we need to compute the updates for function passes. This is
mostly used as an initial customer of all the update mechanisms to drive
their design to at least cover some real set of use cases. There are
a bunch of interesting things that came out of doing this:
- It is really nice to do this a function at a time because that
function is likely hot in the cache. This means we want even the
function pass adaptor to support online updates to the call graph!
- To update the call graph after arbitrary function pass mutations is
quite hard. We have to build a fairly comprehensive set of
data structures and then process them. Fortunately, some of this code
is related to the code for building the cal graph in the first place.
Unfortunately, very little of it makes any sense to share because the
nature of what we're doing is so very different. I've factored out the
one part that made sense at least.
- We need to transfer these updates into the various structures for the
CGSCC pass manager. Once those were more sanely worked out, this
became relatively easier. But some of those needs necessitated changes
to the LazyCallGraph interface to make it significantly easier to
extract the changed SCCs from an update operation.
- We also need to update the CGSCC analysis manager as the shape of the
graph changes. When an SCC is merged away we need to clear analyses
associated with it from the analysis manager which we didn't have
support for in the analysis manager infrsatructure. New SCCs are easy!
But then we have the case that the original SCC has its shape changed
but remains in the call graph. There we need to *invalidate* the
analyses associated with it.
- We also need to invalidate analyses after we *finish* processing an
SCC. But the analyses we need to invalidate here are *only those for
the newly updated SCC*!!! Because we only continue processing the
bottom SCC, if we split SCCs apart the original one gets invalidated
once when its shape changes and is not processed farther so its
analyses will be correct. It is the bottom SCC which continues being
processed and needs to have the "normal" invalidation done based on
the preserved analyses set.
All of this is mostly background and context for the changes here.
Many thanks to all the reviewers who helped here. Especially Sanjoy who
caught several interesting bugs in the graph algorithms, David, Sean,
and others who all helped with feedback.
Differential Revision: http://reviews.llvm.org/D21464
llvm-svn: 279618
2016-08-24 17:37:14 +08:00
|
|
|
CGSCCAnalysisManager &AM,
|
|
|
|
LazyCallGraph &CG,
|
|
|
|
CGSCCUpdateResult &) {
|
2016-02-18 19:03:11 +08:00
|
|
|
FunctionAnalysisManager &FAM =
|
[PM] Introduce basic update capabilities to the new PM's CGSCC pass
manager, including both plumbing and logic to handle function pass
updates.
There are three fundamentally tied changes here:
1) Plumbing *some* mechanism for updating the CGSCC pass manager as the
CG changes while passes are running.
2) Changing the CGSCC pass manager infrastructure to have support for
the underlying graph to mutate mid-pass run.
3) Actually updating the CG after function passes run.
I can separate them if necessary, but I think its really useful to have
them together as the needs of #3 drove #2, and that in turn drove #1.
The plumbing technique is to extend the "run" method signature with
extra arguments. We provide the call graph that intrinsically is
available as it is the basis of the pass manager's IR units, and an
output parameter that records the results of updating the call graph
during an SCC passes's run. Note that "...UpdateResult" isn't a *great*
name here... suggestions very welcome.
I tried a pretty frustrating number of different data structures and such
for the innards of the update result. Every other one failed for one
reason or another. Sometimes I just couldn't keep the layers of
complexity right in my head. The thing that really worked was to just
directly provide access to the underlying structures used to walk the
call graph so that their updates could be informed by the *particular*
nature of the change to the graph.
The technique for how to make the pass management infrastructure cope
with mutating graphs was also something that took a really, really large
number of iterations to get to a place where I was happy. Here are some
of the considerations that drove the design:
- We operate at three levels within the infrastructure: RefSCC, SCC, and
Node. In each case, we are working bottom up and so we want to
continue to iterate on the "lowest" node as the graph changes. Look at
how we iterate over nodes in an SCC running function passes as those
function passes mutate the CG. We continue to iterate on the "lowest"
SCC, which is the one that continues to contain the function just
processed.
- The call graph structure re-uses SCCs (and RefSCCs) during mutation
events for the *highest* entry in the resulting new subgraph, not the
lowest. This means that it is necessary to continually update the
current SCC or RefSCC as it shifts. This is really surprising and
subtle, and took a long time for me to work out. I actually tried
changing the call graph to provide the opposite behavior, and it
breaks *EVERYTHING*. The graph update algorithms are really deeply
tied to this particualr pattern.
- When SCCs or RefSCCs are split apart and refined and we continually
re-pin our processing to the bottom one in the subgraph, we need to
enqueue the newly formed SCCs and RefSCCs for subsequent processing.
Queuing them presents a few challenges:
1) SCCs and RefSCCs use wildly different iteration strategies at
a high level. We end up needing to converge them on worklist
approaches that can be extended in order to be able to handle the
mutations.
2) The order of the enqueuing need to remain bottom-up post-order so
that we don't get surprising order of visitation for things like
the inliner.
3) We need the worklists to have set semantics so we don't duplicate
things endlessly. We don't need a *persistent* set though because
we always keep processing the bottom node!!!! This is super, super
surprising to me and took a long time to convince myself this is
correct, but I'm pretty sure it is... Once we sink down to the
bottom node, we can't re-split out the same node in any way, and
the postorder of the current queue is fixed and unchanging.
4) We need to make sure that the "current" SCC or RefSCC actually gets
enqueued here such that we re-visit it because we continue
processing a *new*, *bottom* SCC/RefSCC.
- We also need the ability to *skip* SCCs and RefSCCs that get merged
into a larger component. We even need the ability to skip *nodes* from
an SCC that are no longer part of that SCC.
This led to the design you see in the patch which uses SetVector-based
worklists. The RefSCC worklist is always empty until an update occurs
and is just used to handle those RefSCCs created by updates as the
others don't even exist yet and are formed on-demand during the
bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and
we push new SCCs onto it and blacklist existing SCCs on it to get the
desired processing.
We then *directly* update these when updating the call graph as I was
never able to find a satisfactory abstraction around the update
strategy.
Finally, we need to compute the updates for function passes. This is
mostly used as an initial customer of all the update mechanisms to drive
their design to at least cover some real set of use cases. There are
a bunch of interesting things that came out of doing this:
- It is really nice to do this a function at a time because that
function is likely hot in the cache. This means we want even the
function pass adaptor to support online updates to the call graph!
- To update the call graph after arbitrary function pass mutations is
quite hard. We have to build a fairly comprehensive set of
data structures and then process them. Fortunately, some of this code
is related to the code for building the cal graph in the first place.
Unfortunately, very little of it makes any sense to share because the
nature of what we're doing is so very different. I've factored out the
one part that made sense at least.
- We need to transfer these updates into the various structures for the
CGSCC pass manager. Once those were more sanely worked out, this
became relatively easier. But some of those needs necessitated changes
to the LazyCallGraph interface to make it significantly easier to
extract the changed SCCs from an update operation.
- We also need to update the CGSCC analysis manager as the shape of the
graph changes. When an SCC is merged away we need to clear analyses
associated with it from the analysis manager which we didn't have
support for in the analysis manager infrsatructure. New SCCs are easy!
But then we have the case that the original SCC has its shape changed
but remains in the call graph. There we need to *invalidate* the
analyses associated with it.
- We also need to invalidate analyses after we *finish* processing an
SCC. But the analyses we need to invalidate here are *only those for
the newly updated SCC*!!! Because we only continue processing the
bottom SCC, if we split SCCs apart the original one gets invalidated
once when its shape changes and is not processed farther so its
analyses will be correct. It is the bottom SCC which continues being
processed and needs to have the "normal" invalidation done based on
the preserved analyses set.
All of this is mostly background and context for the changes here.
Many thanks to all the reviewers who helped here. Especially Sanjoy who
caught several interesting bugs in the graph algorithms, David, Sean,
and others who all helped with feedback.
Differential Revision: http://reviews.llvm.org/D21464
llvm-svn: 279618
2016-08-24 17:37:14 +08:00
|
|
|
AM.getResult<FunctionAnalysisManagerCGSCCProxy>(C, CG).getManager();
|
2016-02-18 19:03:11 +08:00
|
|
|
|
|
|
|
// We pass a lambda into functions to wire them up to the analysis manager
|
|
|
|
// for getting function analyses.
|
|
|
|
auto AARGetter = [&](Function &F) -> AAResults & {
|
|
|
|
return FAM.getResult<AAManager>(F);
|
|
|
|
};
|
|
|
|
|
|
|
|
// Fill SCCNodes with the elements of the SCC. Also track whether there are
|
|
|
|
// any external or opt-none nodes that will prevent us from optimizing any
|
|
|
|
// part of the SCC.
|
|
|
|
SCCNodeSet SCCNodes;
|
|
|
|
bool HasUnknownCall = false;
|
|
|
|
for (LazyCallGraph::Node &N : C) {
|
|
|
|
Function &F = N.getFunction();
|
|
|
|
if (F.hasFnAttribute(Attribute::OptimizeNone)) {
|
|
|
|
// Treat any function we're trying not to optimize as if it were an
|
|
|
|
// indirect call and omit it from the node set used below.
|
|
|
|
HasUnknownCall = true;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
// Track whether any functions in this SCC have an unknown call edge.
|
|
|
|
// Note: if this is ever a performance hit, we can common it with
|
|
|
|
// subsequent routines which also do scans over the instructions of the
|
|
|
|
// function.
|
|
|
|
if (!HasUnknownCall)
|
|
|
|
for (Instruction &I : instructions(F))
|
|
|
|
if (auto CS = CallSite(&I))
|
|
|
|
if (!CS.getCalledFunction()) {
|
|
|
|
HasUnknownCall = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
SCCNodes.insert(&F);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool Changed = false;
|
2016-07-20 02:50:26 +08:00
|
|
|
Changed |= addArgumentReturnedAttrs(SCCNodes);
|
2016-02-18 19:03:11 +08:00
|
|
|
Changed |= addReadAttrs(SCCNodes, AARGetter);
|
|
|
|
Changed |= addArgumentAttrs(SCCNodes);
|
|
|
|
|
|
|
|
// If we have no external nodes participating in the SCC, we can deduce some
|
|
|
|
// more precise attributes as well.
|
|
|
|
if (!HasUnknownCall) {
|
|
|
|
Changed |= addNoAliasAttrs(SCCNodes);
|
2016-07-03 07:47:27 +08:00
|
|
|
Changed |= addNonNullAttrs(SCCNodes);
|
2016-02-18 19:03:11 +08:00
|
|
|
Changed |= removeConvergentAttrs(SCCNodes);
|
|
|
|
Changed |= addNoRecurseAttrs(SCCNodes);
|
|
|
|
}
|
|
|
|
|
|
|
|
return Changed ? PreservedAnalyses::none() : PreservedAnalyses::all();
|
|
|
|
}
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
struct PostOrderFunctionAttrsLegacyPass : public CallGraphSCCPass {
|
|
|
|
static char ID; // Pass identification, replacement for typeid
|
|
|
|
PostOrderFunctionAttrsLegacyPass() : CallGraphSCCPass(ID) {
|
2016-11-08 00:28:04 +08:00
|
|
|
initializePostOrderFunctionAttrsLegacyPassPass(
|
|
|
|
*PassRegistry::getPassRegistry());
|
2016-02-18 19:03:11 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool runOnSCC(CallGraphSCC &SCC) override;
|
|
|
|
|
|
|
|
void getAnalysisUsage(AnalysisUsage &AU) const override {
|
|
|
|
AU.setPreservesCFG();
|
2016-12-19 16:22:17 +08:00
|
|
|
AU.addRequired<AssumptionCacheTracker>();
|
[AA] Hoist the logic to reformulate various AA queries in terms of other
parts of the AA interface out of the base class of every single AA
result object.
Because this logic reformulates the query in terms of some other aspect
of the API, it would easily cause O(n^2) query patterns in alias
analysis. These could in turn be magnified further based on the number
of call arguments, and then further based on the number of AA queries
made for a particular call. This ended up causing problems for Rust that
were actually noticable enough to get a bug (PR26564) and probably other
places as well.
When originally re-working the AA infrastructure, the desire was to
regularize the pattern of refinement without losing any generality.
While I think it was successful, that is clearly proving to be too
costly. And the cost is needless: we gain no actual improvement for this
generality of making a direct query to tbaa actually be able to
re-use some other alias analysis's refinement logic for one of the other
APIs, or some such. In short, this is entirely wasted work.
To the extent possible, delegation to other API surfaces should be done
at the aggregation layer so that we can avoid re-walking the
aggregation. In fact, this significantly simplifies the logic as we no
longer need to smuggle the aggregation layer into each alias analysis
(or the TargetLibraryInfo into each alias analysis just so we can form
argument memory locations!).
However, we also have some delegation logic inside of BasicAA and some
of it even makes sense. When the delegation logic is baking in specific
knowledge of aliasing properties of the LLVM IR, as opposed to simply
reformulating the query to utilize a different alias analysis interface
entry point, it makes a lot of sense to restrict that logic to
a different layer such as BasicAA. So one aspect of the delegation that
was in every AA base class is that when we don't have operand bundles,
we re-use function AA results as a fallback for callsite alias results.
This relies on the IR properties of calls and functions w.r.t. aliasing,
and so seems a better fit to BasicAA. I've lifted the logic up to that
point where it seems to be a natural fit. This still does a bit of
redundant work (we query function attributes twice, once via the
callsite and once via the function AA query) but it is *exactly* twice
here, no more.
The end result is that all of the delegation logic is hoisted out of the
base class and into either the aggregation layer when it is a pure
retargeting to a different API surface, or into BasicAA when it relies
on the IR's aliasing properties. This should fix the quadratic query
pattern reported in PR26564, although I don't have a stand-alone test
case to reproduce it.
It also seems general goodness. Now the numerous AAs that don't need
target library info don't carry it around and depend on it. I think
I can even rip out the general access to the aggregation layer and only
expose that in BasicAA as it is the only place where we re-query in that
manner.
However, this is a non-trivial change to the AA infrastructure so I want
to get some additional eyes on this before it lands. Sadly, it can't
wait long because we should really cherry pick this into 3.8 if we're
going to go this route.
Differential Revision: http://reviews.llvm.org/D17329
llvm-svn: 262490
2016-03-02 23:56:53 +08:00
|
|
|
getAAResultsAnalysisUsage(AU);
|
2016-02-18 19:03:11 +08:00
|
|
|
CallGraphSCCPass::getAnalysisUsage(AU);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
char PostOrderFunctionAttrsLegacyPass::ID = 0;
|
|
|
|
INITIALIZE_PASS_BEGIN(PostOrderFunctionAttrsLegacyPass, "functionattrs",
|
|
|
|
"Deduce function attributes", false, false)
|
2016-12-19 16:22:17 +08:00
|
|
|
INITIALIZE_PASS_DEPENDENCY(AssumptionCacheTracker)
|
2016-02-18 19:03:11 +08:00
|
|
|
INITIALIZE_PASS_DEPENDENCY(CallGraphWrapperPass)
|
|
|
|
INITIALIZE_PASS_END(PostOrderFunctionAttrsLegacyPass, "functionattrs",
|
|
|
|
"Deduce function attributes", false, false)
|
|
|
|
|
2016-11-08 00:28:04 +08:00
|
|
|
Pass *llvm::createPostOrderFunctionAttrsLegacyPass() {
|
|
|
|
return new PostOrderFunctionAttrsLegacyPass();
|
|
|
|
}
|
2016-02-18 19:03:11 +08:00
|
|
|
|
2016-07-03 11:35:03 +08:00
|
|
|
template <typename AARGetterT>
|
|
|
|
static bool runImpl(CallGraphSCC &SCC, AARGetterT AARGetter) {
|
2015-10-31 08:28:37 +08:00
|
|
|
bool Changed = false;
|
2015-10-30 02:29:15 +08:00
|
|
|
|
|
|
|
// Fill SCCNodes with the elements of the SCC. Used for quickly looking up
|
|
|
|
// whether a given CallGraphNode is in this SCC. Also track whether there are
|
|
|
|
// any external or opt-none nodes that will prevent us from optimizing any
|
|
|
|
// part of the SCC.
|
|
|
|
SCCNodeSet SCCNodes;
|
|
|
|
bool ExternalNode = false;
|
2016-06-26 20:28:59 +08:00
|
|
|
for (CallGraphNode *I : SCC) {
|
|
|
|
Function *F = I->getFunction();
|
2015-10-30 02:29:15 +08:00
|
|
|
if (!F || F->hasFnAttribute(Attribute::OptimizeNone)) {
|
|
|
|
// External node or function we're trying not to optimize - we both avoid
|
|
|
|
// transform them and avoid leveraging information they provide.
|
|
|
|
ExternalNode = true;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
SCCNodes.insert(F);
|
|
|
|
}
|
|
|
|
|
2017-06-03 05:24:17 +08:00
|
|
|
// Skip it if the SCC only contains optnone functions.
|
|
|
|
if (SCCNodes.empty())
|
|
|
|
return Changed;
|
|
|
|
|
2016-07-20 02:50:26 +08:00
|
|
|
Changed |= addArgumentReturnedAttrs(SCCNodes);
|
2015-10-31 00:48:08 +08:00
|
|
|
Changed |= addReadAttrs(SCCNodes, AARGetter);
|
2015-10-30 02:29:15 +08:00
|
|
|
Changed |= addArgumentAttrs(SCCNodes);
|
|
|
|
|
2015-12-27 16:41:34 +08:00
|
|
|
// If we have no external nodes participating in the SCC, we can deduce some
|
2015-10-30 02:29:15 +08:00
|
|
|
// more precise attributes as well.
|
|
|
|
if (!ExternalNode) {
|
|
|
|
Changed |= addNoAliasAttrs(SCCNodes);
|
2016-07-03 07:47:27 +08:00
|
|
|
Changed |= addNonNullAttrs(SCCNodes);
|
2016-02-12 17:47:49 +08:00
|
|
|
Changed |= removeConvergentAttrs(SCCNodes);
|
2016-02-13 16:47:51 +08:00
|
|
|
Changed |= addNoRecurseAttrs(SCCNodes);
|
2015-10-30 02:29:15 +08:00
|
|
|
}
|
2016-01-08 18:55:52 +08:00
|
|
|
|
2015-11-12 18:55:20 +08:00
|
|
|
return Changed;
|
|
|
|
}
|
2015-10-30 02:29:15 +08:00
|
|
|
|
2016-07-03 11:35:03 +08:00
|
|
|
bool PostOrderFunctionAttrsLegacyPass::runOnSCC(CallGraphSCC &SCC) {
|
|
|
|
if (skipSCC(SCC))
|
|
|
|
return false;
|
2017-02-10 07:11:52 +08:00
|
|
|
return runImpl(SCC, LegacyAARGetter(*this));
|
2016-07-03 11:35:03 +08:00
|
|
|
}
|
|
|
|
|
2016-01-08 18:55:52 +08:00
|
|
|
namespace {
|
[PM] Port ReversePostOrderFunctionAttrs to the new PM
Below are my super rough notes when porting. They can probably serve as
a basic guide for porting other passes to the new PM. As I port more
passes I'll expand and generalize this and make a proper
docs/HowToPortToNewPassManager.rst document. There is also missing
documentation for general concepts and API's in the new PM which will
require some documentation.
Once there is proper documentation in place we can put up a list of
passes that have to be ported and game-ify/crowdsource the rest of the
porting (at least of the middle end; the backend is still unclear).
I will however be taking personal responsibility for ensuring that the
LLD/ELF LTO pipeline is ported in a timely fashion. The remaining passes
to be ported are (do something like
`git grep "<the string in the bullet point below>"` to find the pass):
General Scalar:
[ ] Simplify the CFG
[ ] Jump Threading
[ ] MemCpy Optimization
[ ] Promote Memory to Register
[ ] MergedLoadStoreMotion
[ ] Lazy Value Information Analysis
General IPO:
[ ] Dead Argument Elimination
[ ] Deduce function attributes in RPO
Loop stuff / vectorization stuff:
[ ] Alignment from assumptions
[ ] Canonicalize natural loops
[ ] Delete dead loops
[ ] Loop Access Analysis
[ ] Loop Invariant Code Motion
[ ] Loop Vectorization
[ ] SLP Vectorizer
[ ] Unroll loops
Devirtualization / CFI:
[ ] Cross-DSO CFI
[ ] Whole program devirtualization
[ ] Lower bitset metadata
CGSCC passes:
[ ] Function Integration/Inlining
[ ] Remove unused exception handling info
[ ] Promote 'by reference' arguments to scalars
Please let me know if you are interested in working on any of the passes
in the above list (e.g. reply to the post-commit thread for this patch).
I'll probably be tackling "General Scalar" and "General IPO" first FWIW.
Steps as I port "Deduce function attributes in RPO"
---------------------------------------------------
(note: if you are doing any work based on these notes, please leave a
note in the post-commit review thread for this commit with any
improvements / suggestions / incompleteness you ran into!)
Note: "Deduce function attributes in RPO" is a module pass.
1. Do preparatory refactoring.
Do preparatory factoring. In this case all I had to do was to pull out a static helper (r272503).
(TODO: give more advice here e.g. if pass holds state or something)
2. Rename the old pass class.
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Rename class ReversePostOrderFunctionAttrs -> ReversePostOrderFunctionAttrsLegacyPass
in preparation for adding a class ReversePostOrderFunctionAttrs as the pass in the new PM.
(edit: actually wait what? The new class name will be
ReversePostOrderFunctionAttrsPass, so it doesn't conflict. So this step is
sort of useless churn).
llvm/include/llvm/InitializePasses.h
llvm/lib/LTO/LTOCodeGenerator.cpp
llvm/lib/Transforms/IPO/IPO.cpp
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Rename initializeReversePostOrderFunctionAttrsPass -> initializeReversePostOrderFunctionAttrsLegacyPassPass
(note that the "PassPass" thing falls out of `s/ReversePostOrderFunctionAttrs/ReversePostOrderFunctionAttrsLegacyPass/`)
Note that the INITIALIZE_PASS macro is what creates this identifier name, so renaming the class requires this renaming too.
Note that createReversePostOrderFunctionAttrsPass does not need to be
renamed since its name is not generated from the class name.
3. Add the new PM pass class.
In the new PM all passes need to have their
declaration in a header somewhere, so you will often need to add a header.
In this case
llvm/include/llvm/Transforms/IPO/FunctionAttrs.h is already there because
PostOrderFunctionAttrsPass was already ported.
The file-level comment from the .cpp file can be used as the file-level
comment for the new header. You may want to tweak the wording slightly
from "this file implements" to "this file provides" or similar.
Add declaration for the new PM pass in this header:
class ReversePostOrderFunctionAttrsPass
: public PassInfoMixin<ReversePostOrderFunctionAttrsPass> {
public:
PreservedAnalyses run(Module &M, AnalysisManager<Module> &AM);
};
Its name should end with `Pass` for consistency (note that this doesn't
collide with the names of most old PM passes). E.g. call it
`<name of the old PM pass>Pass`.
Also, move the doxygen comment from the old PM pass to the declaration of
this class in the header.
Also, include the declaration for the new PM class
`llvm/Transforms/IPO/FunctionAttrs.h` at the top of the file (in this case,
it was already done when the other pass in this file was ported).
Now define the `run` method for the new class.
The main things here are:
a) Use AM.getResult<...>(M) to get results instead of `getAnalysis<...>()`
b) If the old PM pass would have returned "false" (i.e. `Changed ==
false`), then you should return PreservedAnalyses::all();
c) In the old PM getAnalysisUsage method, observe the calls
`AU.addPreserved<...>();`.
In the case `Changed == true`, for each preserved analysis you should do
call `PA.preserve<...>()` on a PreservedAnalyses object and return it.
E.g.:
PreservedAnalyses PA;
PA.preserve<CallGraphAnalysis>();
return PA;
Note that calls to skipModule/skipFunction are not supported in the new PM
currently, so optnone and optimization bisect support do not work. You can
just drop those calls for now.
4. Add the pass to the new PM pass registry to make it available in opt.
In llvm/lib/Passes/PassBuilder.cpp add a #include for your header.
`#include "llvm/Transforms/IPO/FunctionAttrs.h"`
In this case there is already an include (from when
PostOrderFunctionAttrsPass was ported).
Add your pass to llvm/lib/Passes/PassRegistry.def
In this case, I added
`MODULE_PASS("rpo-functionattrs", ReversePostOrderFunctionAttrsPass())`
The string is from the `INITIALIZE_PASS*` macros used in the old pass
manager.
Then choose a test that uses the pass and use the new PM `-passes=...` to
run it.
E.g. in this case there is a test that does:
; RUN: opt < %s -basicaa -functionattrs -rpo-functionattrs -S | FileCheck %s
I have added the line:
; RUN: opt < %s -aa-pipeline=basic-aa -passes='require<targetlibinfo>,cgscc(function-attrs),rpo-functionattrs' -S | FileCheck %s
The `-aa-pipeline=basic-aa` and
`require<targetlibinfo>,cgscc(function-attrs)` are what is needed to run
functionattrs in the new PM (note that in the new PM "functionattrs"
becomes "function-attrs" for some reason). This is just pulled from
`readattrs.ll` which contains the change from when functionattrs was ported
to the new PM.
Adding rpo-functionattrs causes the pass that was just ported to run.
llvm-svn: 272505
2016-06-12 15:48:51 +08:00
|
|
|
struct ReversePostOrderFunctionAttrsLegacyPass : public ModulePass {
|
2016-01-08 18:55:52 +08:00
|
|
|
static char ID; // Pass identification, replacement for typeid
|
[PM] Port ReversePostOrderFunctionAttrs to the new PM
Below are my super rough notes when porting. They can probably serve as
a basic guide for porting other passes to the new PM. As I port more
passes I'll expand and generalize this and make a proper
docs/HowToPortToNewPassManager.rst document. There is also missing
documentation for general concepts and API's in the new PM which will
require some documentation.
Once there is proper documentation in place we can put up a list of
passes that have to be ported and game-ify/crowdsource the rest of the
porting (at least of the middle end; the backend is still unclear).
I will however be taking personal responsibility for ensuring that the
LLD/ELF LTO pipeline is ported in a timely fashion. The remaining passes
to be ported are (do something like
`git grep "<the string in the bullet point below>"` to find the pass):
General Scalar:
[ ] Simplify the CFG
[ ] Jump Threading
[ ] MemCpy Optimization
[ ] Promote Memory to Register
[ ] MergedLoadStoreMotion
[ ] Lazy Value Information Analysis
General IPO:
[ ] Dead Argument Elimination
[ ] Deduce function attributes in RPO
Loop stuff / vectorization stuff:
[ ] Alignment from assumptions
[ ] Canonicalize natural loops
[ ] Delete dead loops
[ ] Loop Access Analysis
[ ] Loop Invariant Code Motion
[ ] Loop Vectorization
[ ] SLP Vectorizer
[ ] Unroll loops
Devirtualization / CFI:
[ ] Cross-DSO CFI
[ ] Whole program devirtualization
[ ] Lower bitset metadata
CGSCC passes:
[ ] Function Integration/Inlining
[ ] Remove unused exception handling info
[ ] Promote 'by reference' arguments to scalars
Please let me know if you are interested in working on any of the passes
in the above list (e.g. reply to the post-commit thread for this patch).
I'll probably be tackling "General Scalar" and "General IPO" first FWIW.
Steps as I port "Deduce function attributes in RPO"
---------------------------------------------------
(note: if you are doing any work based on these notes, please leave a
note in the post-commit review thread for this commit with any
improvements / suggestions / incompleteness you ran into!)
Note: "Deduce function attributes in RPO" is a module pass.
1. Do preparatory refactoring.
Do preparatory factoring. In this case all I had to do was to pull out a static helper (r272503).
(TODO: give more advice here e.g. if pass holds state or something)
2. Rename the old pass class.
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Rename class ReversePostOrderFunctionAttrs -> ReversePostOrderFunctionAttrsLegacyPass
in preparation for adding a class ReversePostOrderFunctionAttrs as the pass in the new PM.
(edit: actually wait what? The new class name will be
ReversePostOrderFunctionAttrsPass, so it doesn't conflict. So this step is
sort of useless churn).
llvm/include/llvm/InitializePasses.h
llvm/lib/LTO/LTOCodeGenerator.cpp
llvm/lib/Transforms/IPO/IPO.cpp
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Rename initializeReversePostOrderFunctionAttrsPass -> initializeReversePostOrderFunctionAttrsLegacyPassPass
(note that the "PassPass" thing falls out of `s/ReversePostOrderFunctionAttrs/ReversePostOrderFunctionAttrsLegacyPass/`)
Note that the INITIALIZE_PASS macro is what creates this identifier name, so renaming the class requires this renaming too.
Note that createReversePostOrderFunctionAttrsPass does not need to be
renamed since its name is not generated from the class name.
3. Add the new PM pass class.
In the new PM all passes need to have their
declaration in a header somewhere, so you will often need to add a header.
In this case
llvm/include/llvm/Transforms/IPO/FunctionAttrs.h is already there because
PostOrderFunctionAttrsPass was already ported.
The file-level comment from the .cpp file can be used as the file-level
comment for the new header. You may want to tweak the wording slightly
from "this file implements" to "this file provides" or similar.
Add declaration for the new PM pass in this header:
class ReversePostOrderFunctionAttrsPass
: public PassInfoMixin<ReversePostOrderFunctionAttrsPass> {
public:
PreservedAnalyses run(Module &M, AnalysisManager<Module> &AM);
};
Its name should end with `Pass` for consistency (note that this doesn't
collide with the names of most old PM passes). E.g. call it
`<name of the old PM pass>Pass`.
Also, move the doxygen comment from the old PM pass to the declaration of
this class in the header.
Also, include the declaration for the new PM class
`llvm/Transforms/IPO/FunctionAttrs.h` at the top of the file (in this case,
it was already done when the other pass in this file was ported).
Now define the `run` method for the new class.
The main things here are:
a) Use AM.getResult<...>(M) to get results instead of `getAnalysis<...>()`
b) If the old PM pass would have returned "false" (i.e. `Changed ==
false`), then you should return PreservedAnalyses::all();
c) In the old PM getAnalysisUsage method, observe the calls
`AU.addPreserved<...>();`.
In the case `Changed == true`, for each preserved analysis you should do
call `PA.preserve<...>()` on a PreservedAnalyses object and return it.
E.g.:
PreservedAnalyses PA;
PA.preserve<CallGraphAnalysis>();
return PA;
Note that calls to skipModule/skipFunction are not supported in the new PM
currently, so optnone and optimization bisect support do not work. You can
just drop those calls for now.
4. Add the pass to the new PM pass registry to make it available in opt.
In llvm/lib/Passes/PassBuilder.cpp add a #include for your header.
`#include "llvm/Transforms/IPO/FunctionAttrs.h"`
In this case there is already an include (from when
PostOrderFunctionAttrsPass was ported).
Add your pass to llvm/lib/Passes/PassRegistry.def
In this case, I added
`MODULE_PASS("rpo-functionattrs", ReversePostOrderFunctionAttrsPass())`
The string is from the `INITIALIZE_PASS*` macros used in the old pass
manager.
Then choose a test that uses the pass and use the new PM `-passes=...` to
run it.
E.g. in this case there is a test that does:
; RUN: opt < %s -basicaa -functionattrs -rpo-functionattrs -S | FileCheck %s
I have added the line:
; RUN: opt < %s -aa-pipeline=basic-aa -passes='require<targetlibinfo>,cgscc(function-attrs),rpo-functionattrs' -S | FileCheck %s
The `-aa-pipeline=basic-aa` and
`require<targetlibinfo>,cgscc(function-attrs)` are what is needed to run
functionattrs in the new PM (note that in the new PM "functionattrs"
becomes "function-attrs" for some reason). This is just pulled from
`readattrs.ll` which contains the change from when functionattrs was ported
to the new PM.
Adding rpo-functionattrs causes the pass that was just ported to run.
llvm-svn: 272505
2016-06-12 15:48:51 +08:00
|
|
|
ReversePostOrderFunctionAttrsLegacyPass() : ModulePass(ID) {
|
2016-11-08 00:28:04 +08:00
|
|
|
initializeReversePostOrderFunctionAttrsLegacyPassPass(
|
|
|
|
*PassRegistry::getPassRegistry());
|
2016-01-08 18:55:52 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool runOnModule(Module &M) override;
|
|
|
|
|
|
|
|
void getAnalysisUsage(AnalysisUsage &AU) const override {
|
|
|
|
AU.setPreservesCFG();
|
|
|
|
AU.addRequired<CallGraphWrapperPass>();
|
2016-05-03 02:03:33 +08:00
|
|
|
AU.addPreserved<CallGraphWrapperPass>();
|
2016-01-08 18:55:52 +08:00
|
|
|
}
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
[PM] Port ReversePostOrderFunctionAttrs to the new PM
Below are my super rough notes when porting. They can probably serve as
a basic guide for porting other passes to the new PM. As I port more
passes I'll expand and generalize this and make a proper
docs/HowToPortToNewPassManager.rst document. There is also missing
documentation for general concepts and API's in the new PM which will
require some documentation.
Once there is proper documentation in place we can put up a list of
passes that have to be ported and game-ify/crowdsource the rest of the
porting (at least of the middle end; the backend is still unclear).
I will however be taking personal responsibility for ensuring that the
LLD/ELF LTO pipeline is ported in a timely fashion. The remaining passes
to be ported are (do something like
`git grep "<the string in the bullet point below>"` to find the pass):
General Scalar:
[ ] Simplify the CFG
[ ] Jump Threading
[ ] MemCpy Optimization
[ ] Promote Memory to Register
[ ] MergedLoadStoreMotion
[ ] Lazy Value Information Analysis
General IPO:
[ ] Dead Argument Elimination
[ ] Deduce function attributes in RPO
Loop stuff / vectorization stuff:
[ ] Alignment from assumptions
[ ] Canonicalize natural loops
[ ] Delete dead loops
[ ] Loop Access Analysis
[ ] Loop Invariant Code Motion
[ ] Loop Vectorization
[ ] SLP Vectorizer
[ ] Unroll loops
Devirtualization / CFI:
[ ] Cross-DSO CFI
[ ] Whole program devirtualization
[ ] Lower bitset metadata
CGSCC passes:
[ ] Function Integration/Inlining
[ ] Remove unused exception handling info
[ ] Promote 'by reference' arguments to scalars
Please let me know if you are interested in working on any of the passes
in the above list (e.g. reply to the post-commit thread for this patch).
I'll probably be tackling "General Scalar" and "General IPO" first FWIW.
Steps as I port "Deduce function attributes in RPO"
---------------------------------------------------
(note: if you are doing any work based on these notes, please leave a
note in the post-commit review thread for this commit with any
improvements / suggestions / incompleteness you ran into!)
Note: "Deduce function attributes in RPO" is a module pass.
1. Do preparatory refactoring.
Do preparatory factoring. In this case all I had to do was to pull out a static helper (r272503).
(TODO: give more advice here e.g. if pass holds state or something)
2. Rename the old pass class.
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Rename class ReversePostOrderFunctionAttrs -> ReversePostOrderFunctionAttrsLegacyPass
in preparation for adding a class ReversePostOrderFunctionAttrs as the pass in the new PM.
(edit: actually wait what? The new class name will be
ReversePostOrderFunctionAttrsPass, so it doesn't conflict. So this step is
sort of useless churn).
llvm/include/llvm/InitializePasses.h
llvm/lib/LTO/LTOCodeGenerator.cpp
llvm/lib/Transforms/IPO/IPO.cpp
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Rename initializeReversePostOrderFunctionAttrsPass -> initializeReversePostOrderFunctionAttrsLegacyPassPass
(note that the "PassPass" thing falls out of `s/ReversePostOrderFunctionAttrs/ReversePostOrderFunctionAttrsLegacyPass/`)
Note that the INITIALIZE_PASS macro is what creates this identifier name, so renaming the class requires this renaming too.
Note that createReversePostOrderFunctionAttrsPass does not need to be
renamed since its name is not generated from the class name.
3. Add the new PM pass class.
In the new PM all passes need to have their
declaration in a header somewhere, so you will often need to add a header.
In this case
llvm/include/llvm/Transforms/IPO/FunctionAttrs.h is already there because
PostOrderFunctionAttrsPass was already ported.
The file-level comment from the .cpp file can be used as the file-level
comment for the new header. You may want to tweak the wording slightly
from "this file implements" to "this file provides" or similar.
Add declaration for the new PM pass in this header:
class ReversePostOrderFunctionAttrsPass
: public PassInfoMixin<ReversePostOrderFunctionAttrsPass> {
public:
PreservedAnalyses run(Module &M, AnalysisManager<Module> &AM);
};
Its name should end with `Pass` for consistency (note that this doesn't
collide with the names of most old PM passes). E.g. call it
`<name of the old PM pass>Pass`.
Also, move the doxygen comment from the old PM pass to the declaration of
this class in the header.
Also, include the declaration for the new PM class
`llvm/Transforms/IPO/FunctionAttrs.h` at the top of the file (in this case,
it was already done when the other pass in this file was ported).
Now define the `run` method for the new class.
The main things here are:
a) Use AM.getResult<...>(M) to get results instead of `getAnalysis<...>()`
b) If the old PM pass would have returned "false" (i.e. `Changed ==
false`), then you should return PreservedAnalyses::all();
c) In the old PM getAnalysisUsage method, observe the calls
`AU.addPreserved<...>();`.
In the case `Changed == true`, for each preserved analysis you should do
call `PA.preserve<...>()` on a PreservedAnalyses object and return it.
E.g.:
PreservedAnalyses PA;
PA.preserve<CallGraphAnalysis>();
return PA;
Note that calls to skipModule/skipFunction are not supported in the new PM
currently, so optnone and optimization bisect support do not work. You can
just drop those calls for now.
4. Add the pass to the new PM pass registry to make it available in opt.
In llvm/lib/Passes/PassBuilder.cpp add a #include for your header.
`#include "llvm/Transforms/IPO/FunctionAttrs.h"`
In this case there is already an include (from when
PostOrderFunctionAttrsPass was ported).
Add your pass to llvm/lib/Passes/PassRegistry.def
In this case, I added
`MODULE_PASS("rpo-functionattrs", ReversePostOrderFunctionAttrsPass())`
The string is from the `INITIALIZE_PASS*` macros used in the old pass
manager.
Then choose a test that uses the pass and use the new PM `-passes=...` to
run it.
E.g. in this case there is a test that does:
; RUN: opt < %s -basicaa -functionattrs -rpo-functionattrs -S | FileCheck %s
I have added the line:
; RUN: opt < %s -aa-pipeline=basic-aa -passes='require<targetlibinfo>,cgscc(function-attrs),rpo-functionattrs' -S | FileCheck %s
The `-aa-pipeline=basic-aa` and
`require<targetlibinfo>,cgscc(function-attrs)` are what is needed to run
functionattrs in the new PM (note that in the new PM "functionattrs"
becomes "function-attrs" for some reason). This is just pulled from
`readattrs.ll` which contains the change from when functionattrs was ported
to the new PM.
Adding rpo-functionattrs causes the pass that was just ported to run.
llvm-svn: 272505
2016-06-12 15:48:51 +08:00
|
|
|
char ReversePostOrderFunctionAttrsLegacyPass::ID = 0;
|
|
|
|
INITIALIZE_PASS_BEGIN(ReversePostOrderFunctionAttrsLegacyPass, "rpo-functionattrs",
|
2016-01-08 18:55:52 +08:00
|
|
|
"Deduce function attributes in RPO", false, false)
|
|
|
|
INITIALIZE_PASS_DEPENDENCY(CallGraphWrapperPass)
|
[PM] Port ReversePostOrderFunctionAttrs to the new PM
Below are my super rough notes when porting. They can probably serve as
a basic guide for porting other passes to the new PM. As I port more
passes I'll expand and generalize this and make a proper
docs/HowToPortToNewPassManager.rst document. There is also missing
documentation for general concepts and API's in the new PM which will
require some documentation.
Once there is proper documentation in place we can put up a list of
passes that have to be ported and game-ify/crowdsource the rest of the
porting (at least of the middle end; the backend is still unclear).
I will however be taking personal responsibility for ensuring that the
LLD/ELF LTO pipeline is ported in a timely fashion. The remaining passes
to be ported are (do something like
`git grep "<the string in the bullet point below>"` to find the pass):
General Scalar:
[ ] Simplify the CFG
[ ] Jump Threading
[ ] MemCpy Optimization
[ ] Promote Memory to Register
[ ] MergedLoadStoreMotion
[ ] Lazy Value Information Analysis
General IPO:
[ ] Dead Argument Elimination
[ ] Deduce function attributes in RPO
Loop stuff / vectorization stuff:
[ ] Alignment from assumptions
[ ] Canonicalize natural loops
[ ] Delete dead loops
[ ] Loop Access Analysis
[ ] Loop Invariant Code Motion
[ ] Loop Vectorization
[ ] SLP Vectorizer
[ ] Unroll loops
Devirtualization / CFI:
[ ] Cross-DSO CFI
[ ] Whole program devirtualization
[ ] Lower bitset metadata
CGSCC passes:
[ ] Function Integration/Inlining
[ ] Remove unused exception handling info
[ ] Promote 'by reference' arguments to scalars
Please let me know if you are interested in working on any of the passes
in the above list (e.g. reply to the post-commit thread for this patch).
I'll probably be tackling "General Scalar" and "General IPO" first FWIW.
Steps as I port "Deduce function attributes in RPO"
---------------------------------------------------
(note: if you are doing any work based on these notes, please leave a
note in the post-commit review thread for this commit with any
improvements / suggestions / incompleteness you ran into!)
Note: "Deduce function attributes in RPO" is a module pass.
1. Do preparatory refactoring.
Do preparatory factoring. In this case all I had to do was to pull out a static helper (r272503).
(TODO: give more advice here e.g. if pass holds state or something)
2. Rename the old pass class.
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Rename class ReversePostOrderFunctionAttrs -> ReversePostOrderFunctionAttrsLegacyPass
in preparation for adding a class ReversePostOrderFunctionAttrs as the pass in the new PM.
(edit: actually wait what? The new class name will be
ReversePostOrderFunctionAttrsPass, so it doesn't conflict. So this step is
sort of useless churn).
llvm/include/llvm/InitializePasses.h
llvm/lib/LTO/LTOCodeGenerator.cpp
llvm/lib/Transforms/IPO/IPO.cpp
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Rename initializeReversePostOrderFunctionAttrsPass -> initializeReversePostOrderFunctionAttrsLegacyPassPass
(note that the "PassPass" thing falls out of `s/ReversePostOrderFunctionAttrs/ReversePostOrderFunctionAttrsLegacyPass/`)
Note that the INITIALIZE_PASS macro is what creates this identifier name, so renaming the class requires this renaming too.
Note that createReversePostOrderFunctionAttrsPass does not need to be
renamed since its name is not generated from the class name.
3. Add the new PM pass class.
In the new PM all passes need to have their
declaration in a header somewhere, so you will often need to add a header.
In this case
llvm/include/llvm/Transforms/IPO/FunctionAttrs.h is already there because
PostOrderFunctionAttrsPass was already ported.
The file-level comment from the .cpp file can be used as the file-level
comment for the new header. You may want to tweak the wording slightly
from "this file implements" to "this file provides" or similar.
Add declaration for the new PM pass in this header:
class ReversePostOrderFunctionAttrsPass
: public PassInfoMixin<ReversePostOrderFunctionAttrsPass> {
public:
PreservedAnalyses run(Module &M, AnalysisManager<Module> &AM);
};
Its name should end with `Pass` for consistency (note that this doesn't
collide with the names of most old PM passes). E.g. call it
`<name of the old PM pass>Pass`.
Also, move the doxygen comment from the old PM pass to the declaration of
this class in the header.
Also, include the declaration for the new PM class
`llvm/Transforms/IPO/FunctionAttrs.h` at the top of the file (in this case,
it was already done when the other pass in this file was ported).
Now define the `run` method for the new class.
The main things here are:
a) Use AM.getResult<...>(M) to get results instead of `getAnalysis<...>()`
b) If the old PM pass would have returned "false" (i.e. `Changed ==
false`), then you should return PreservedAnalyses::all();
c) In the old PM getAnalysisUsage method, observe the calls
`AU.addPreserved<...>();`.
In the case `Changed == true`, for each preserved analysis you should do
call `PA.preserve<...>()` on a PreservedAnalyses object and return it.
E.g.:
PreservedAnalyses PA;
PA.preserve<CallGraphAnalysis>();
return PA;
Note that calls to skipModule/skipFunction are not supported in the new PM
currently, so optnone and optimization bisect support do not work. You can
just drop those calls for now.
4. Add the pass to the new PM pass registry to make it available in opt.
In llvm/lib/Passes/PassBuilder.cpp add a #include for your header.
`#include "llvm/Transforms/IPO/FunctionAttrs.h"`
In this case there is already an include (from when
PostOrderFunctionAttrsPass was ported).
Add your pass to llvm/lib/Passes/PassRegistry.def
In this case, I added
`MODULE_PASS("rpo-functionattrs", ReversePostOrderFunctionAttrsPass())`
The string is from the `INITIALIZE_PASS*` macros used in the old pass
manager.
Then choose a test that uses the pass and use the new PM `-passes=...` to
run it.
E.g. in this case there is a test that does:
; RUN: opt < %s -basicaa -functionattrs -rpo-functionattrs -S | FileCheck %s
I have added the line:
; RUN: opt < %s -aa-pipeline=basic-aa -passes='require<targetlibinfo>,cgscc(function-attrs),rpo-functionattrs' -S | FileCheck %s
The `-aa-pipeline=basic-aa` and
`require<targetlibinfo>,cgscc(function-attrs)` are what is needed to run
functionattrs in the new PM (note that in the new PM "functionattrs"
becomes "function-attrs" for some reason). This is just pulled from
`readattrs.ll` which contains the change from when functionattrs was ported
to the new PM.
Adding rpo-functionattrs causes the pass that was just ported to run.
llvm-svn: 272505
2016-06-12 15:48:51 +08:00
|
|
|
INITIALIZE_PASS_END(ReversePostOrderFunctionAttrsLegacyPass, "rpo-functionattrs",
|
2016-01-08 18:55:52 +08:00
|
|
|
"Deduce function attributes in RPO", false, false)
|
|
|
|
|
|
|
|
Pass *llvm::createReversePostOrderFunctionAttrsPass() {
|
[PM] Port ReversePostOrderFunctionAttrs to the new PM
Below are my super rough notes when porting. They can probably serve as
a basic guide for porting other passes to the new PM. As I port more
passes I'll expand and generalize this and make a proper
docs/HowToPortToNewPassManager.rst document. There is also missing
documentation for general concepts and API's in the new PM which will
require some documentation.
Once there is proper documentation in place we can put up a list of
passes that have to be ported and game-ify/crowdsource the rest of the
porting (at least of the middle end; the backend is still unclear).
I will however be taking personal responsibility for ensuring that the
LLD/ELF LTO pipeline is ported in a timely fashion. The remaining passes
to be ported are (do something like
`git grep "<the string in the bullet point below>"` to find the pass):
General Scalar:
[ ] Simplify the CFG
[ ] Jump Threading
[ ] MemCpy Optimization
[ ] Promote Memory to Register
[ ] MergedLoadStoreMotion
[ ] Lazy Value Information Analysis
General IPO:
[ ] Dead Argument Elimination
[ ] Deduce function attributes in RPO
Loop stuff / vectorization stuff:
[ ] Alignment from assumptions
[ ] Canonicalize natural loops
[ ] Delete dead loops
[ ] Loop Access Analysis
[ ] Loop Invariant Code Motion
[ ] Loop Vectorization
[ ] SLP Vectorizer
[ ] Unroll loops
Devirtualization / CFI:
[ ] Cross-DSO CFI
[ ] Whole program devirtualization
[ ] Lower bitset metadata
CGSCC passes:
[ ] Function Integration/Inlining
[ ] Remove unused exception handling info
[ ] Promote 'by reference' arguments to scalars
Please let me know if you are interested in working on any of the passes
in the above list (e.g. reply to the post-commit thread for this patch).
I'll probably be tackling "General Scalar" and "General IPO" first FWIW.
Steps as I port "Deduce function attributes in RPO"
---------------------------------------------------
(note: if you are doing any work based on these notes, please leave a
note in the post-commit review thread for this commit with any
improvements / suggestions / incompleteness you ran into!)
Note: "Deduce function attributes in RPO" is a module pass.
1. Do preparatory refactoring.
Do preparatory factoring. In this case all I had to do was to pull out a static helper (r272503).
(TODO: give more advice here e.g. if pass holds state or something)
2. Rename the old pass class.
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Rename class ReversePostOrderFunctionAttrs -> ReversePostOrderFunctionAttrsLegacyPass
in preparation for adding a class ReversePostOrderFunctionAttrs as the pass in the new PM.
(edit: actually wait what? The new class name will be
ReversePostOrderFunctionAttrsPass, so it doesn't conflict. So this step is
sort of useless churn).
llvm/include/llvm/InitializePasses.h
llvm/lib/LTO/LTOCodeGenerator.cpp
llvm/lib/Transforms/IPO/IPO.cpp
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Rename initializeReversePostOrderFunctionAttrsPass -> initializeReversePostOrderFunctionAttrsLegacyPassPass
(note that the "PassPass" thing falls out of `s/ReversePostOrderFunctionAttrs/ReversePostOrderFunctionAttrsLegacyPass/`)
Note that the INITIALIZE_PASS macro is what creates this identifier name, so renaming the class requires this renaming too.
Note that createReversePostOrderFunctionAttrsPass does not need to be
renamed since its name is not generated from the class name.
3. Add the new PM pass class.
In the new PM all passes need to have their
declaration in a header somewhere, so you will often need to add a header.
In this case
llvm/include/llvm/Transforms/IPO/FunctionAttrs.h is already there because
PostOrderFunctionAttrsPass was already ported.
The file-level comment from the .cpp file can be used as the file-level
comment for the new header. You may want to tweak the wording slightly
from "this file implements" to "this file provides" or similar.
Add declaration for the new PM pass in this header:
class ReversePostOrderFunctionAttrsPass
: public PassInfoMixin<ReversePostOrderFunctionAttrsPass> {
public:
PreservedAnalyses run(Module &M, AnalysisManager<Module> &AM);
};
Its name should end with `Pass` for consistency (note that this doesn't
collide with the names of most old PM passes). E.g. call it
`<name of the old PM pass>Pass`.
Also, move the doxygen comment from the old PM pass to the declaration of
this class in the header.
Also, include the declaration for the new PM class
`llvm/Transforms/IPO/FunctionAttrs.h` at the top of the file (in this case,
it was already done when the other pass in this file was ported).
Now define the `run` method for the new class.
The main things here are:
a) Use AM.getResult<...>(M) to get results instead of `getAnalysis<...>()`
b) If the old PM pass would have returned "false" (i.e. `Changed ==
false`), then you should return PreservedAnalyses::all();
c) In the old PM getAnalysisUsage method, observe the calls
`AU.addPreserved<...>();`.
In the case `Changed == true`, for each preserved analysis you should do
call `PA.preserve<...>()` on a PreservedAnalyses object and return it.
E.g.:
PreservedAnalyses PA;
PA.preserve<CallGraphAnalysis>();
return PA;
Note that calls to skipModule/skipFunction are not supported in the new PM
currently, so optnone and optimization bisect support do not work. You can
just drop those calls for now.
4. Add the pass to the new PM pass registry to make it available in opt.
In llvm/lib/Passes/PassBuilder.cpp add a #include for your header.
`#include "llvm/Transforms/IPO/FunctionAttrs.h"`
In this case there is already an include (from when
PostOrderFunctionAttrsPass was ported).
Add your pass to llvm/lib/Passes/PassRegistry.def
In this case, I added
`MODULE_PASS("rpo-functionattrs", ReversePostOrderFunctionAttrsPass())`
The string is from the `INITIALIZE_PASS*` macros used in the old pass
manager.
Then choose a test that uses the pass and use the new PM `-passes=...` to
run it.
E.g. in this case there is a test that does:
; RUN: opt < %s -basicaa -functionattrs -rpo-functionattrs -S | FileCheck %s
I have added the line:
; RUN: opt < %s -aa-pipeline=basic-aa -passes='require<targetlibinfo>,cgscc(function-attrs),rpo-functionattrs' -S | FileCheck %s
The `-aa-pipeline=basic-aa` and
`require<targetlibinfo>,cgscc(function-attrs)` are what is needed to run
functionattrs in the new PM (note that in the new PM "functionattrs"
becomes "function-attrs" for some reason). This is just pulled from
`readattrs.ll` which contains the change from when functionattrs was ported
to the new PM.
Adding rpo-functionattrs causes the pass that was just ported to run.
llvm-svn: 272505
2016-06-12 15:48:51 +08:00
|
|
|
return new ReversePostOrderFunctionAttrsLegacyPass();
|
2016-01-08 18:55:52 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static bool addNoRecurseAttrsTopDown(Function &F) {
|
|
|
|
// We check the preconditions for the function prior to calling this to avoid
|
|
|
|
// the cost of building up a reversible post-order list. We assert them here
|
|
|
|
// to make sure none of the invariants this relies on were violated.
|
|
|
|
assert(!F.isDeclaration() && "Cannot deduce norecurse without a definition!");
|
|
|
|
assert(!F.doesNotRecurse() &&
|
|
|
|
"This function has already been deduced as norecurs!");
|
|
|
|
assert(F.hasInternalLinkage() &&
|
|
|
|
"Can only do top-down deduction for internal linkage functions!");
|
|
|
|
|
|
|
|
// If F is internal and all of its uses are calls from a non-recursive
|
|
|
|
// functions, then none of its calls could in fact recurse without going
|
|
|
|
// through a function marked norecurse, and so we can mark this function too
|
|
|
|
// as norecurse. Note that the uses must actually be calls -- otherwise
|
|
|
|
// a pointer to this function could be returned from a norecurse function but
|
|
|
|
// this function could be recursively (indirectly) called. Note that this
|
|
|
|
// also detects if F is directly recursive as F is not yet marked as
|
|
|
|
// a norecurse function.
|
|
|
|
for (auto *U : F.users()) {
|
|
|
|
auto *I = dyn_cast<Instruction>(U);
|
|
|
|
if (!I)
|
|
|
|
return false;
|
|
|
|
CallSite CS(I);
|
|
|
|
if (!CS || !CS.getParent()->getParent()->doesNotRecurse())
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return setDoesNotRecurse(F);
|
|
|
|
}
|
|
|
|
|
2016-06-12 13:44:51 +08:00
|
|
|
static bool deduceFunctionAttributeInRPO(Module &M, CallGraph &CG) {
|
2016-01-08 18:55:52 +08:00
|
|
|
// We only have a post-order SCC traversal (because SCCs are inherently
|
|
|
|
// discovered in post-order), so we accumulate them in a vector and then walk
|
|
|
|
// it in reverse. This is simpler than using the RPO iterator infrastructure
|
|
|
|
// because we need to combine SCC detection and the PO walk of the call
|
|
|
|
// graph. We can also cheat egregiously because we're primarily interested in
|
|
|
|
// synthesizing norecurse and so we can only save the singular SCCs as SCCs
|
|
|
|
// with multiple functions in them will clearly be recursive.
|
|
|
|
SmallVector<Function *, 16> Worklist;
|
|
|
|
for (scc_iterator<CallGraph *> I = scc_begin(&CG); !I.isAtEnd(); ++I) {
|
|
|
|
if (I->size() != 1)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
Function *F = I->front()->getFunction();
|
|
|
|
if (F && !F->isDeclaration() && !F->doesNotRecurse() &&
|
|
|
|
F->hasInternalLinkage())
|
|
|
|
Worklist.push_back(F);
|
|
|
|
}
|
|
|
|
|
2015-11-12 18:55:20 +08:00
|
|
|
bool Changed = false;
|
2016-01-08 18:55:52 +08:00
|
|
|
for (auto *F : reverse(Worklist))
|
|
|
|
Changed |= addNoRecurseAttrsTopDown(*F);
|
|
|
|
|
2009-01-01 00:14:43 +08:00
|
|
|
return Changed;
|
|
|
|
}
|
2016-06-12 13:44:51 +08:00
|
|
|
|
[PM] Port ReversePostOrderFunctionAttrs to the new PM
Below are my super rough notes when porting. They can probably serve as
a basic guide for porting other passes to the new PM. As I port more
passes I'll expand and generalize this and make a proper
docs/HowToPortToNewPassManager.rst document. There is also missing
documentation for general concepts and API's in the new PM which will
require some documentation.
Once there is proper documentation in place we can put up a list of
passes that have to be ported and game-ify/crowdsource the rest of the
porting (at least of the middle end; the backend is still unclear).
I will however be taking personal responsibility for ensuring that the
LLD/ELF LTO pipeline is ported in a timely fashion. The remaining passes
to be ported are (do something like
`git grep "<the string in the bullet point below>"` to find the pass):
General Scalar:
[ ] Simplify the CFG
[ ] Jump Threading
[ ] MemCpy Optimization
[ ] Promote Memory to Register
[ ] MergedLoadStoreMotion
[ ] Lazy Value Information Analysis
General IPO:
[ ] Dead Argument Elimination
[ ] Deduce function attributes in RPO
Loop stuff / vectorization stuff:
[ ] Alignment from assumptions
[ ] Canonicalize natural loops
[ ] Delete dead loops
[ ] Loop Access Analysis
[ ] Loop Invariant Code Motion
[ ] Loop Vectorization
[ ] SLP Vectorizer
[ ] Unroll loops
Devirtualization / CFI:
[ ] Cross-DSO CFI
[ ] Whole program devirtualization
[ ] Lower bitset metadata
CGSCC passes:
[ ] Function Integration/Inlining
[ ] Remove unused exception handling info
[ ] Promote 'by reference' arguments to scalars
Please let me know if you are interested in working on any of the passes
in the above list (e.g. reply to the post-commit thread for this patch).
I'll probably be tackling "General Scalar" and "General IPO" first FWIW.
Steps as I port "Deduce function attributes in RPO"
---------------------------------------------------
(note: if you are doing any work based on these notes, please leave a
note in the post-commit review thread for this commit with any
improvements / suggestions / incompleteness you ran into!)
Note: "Deduce function attributes in RPO" is a module pass.
1. Do preparatory refactoring.
Do preparatory factoring. In this case all I had to do was to pull out a static helper (r272503).
(TODO: give more advice here e.g. if pass holds state or something)
2. Rename the old pass class.
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Rename class ReversePostOrderFunctionAttrs -> ReversePostOrderFunctionAttrsLegacyPass
in preparation for adding a class ReversePostOrderFunctionAttrs as the pass in the new PM.
(edit: actually wait what? The new class name will be
ReversePostOrderFunctionAttrsPass, so it doesn't conflict. So this step is
sort of useless churn).
llvm/include/llvm/InitializePasses.h
llvm/lib/LTO/LTOCodeGenerator.cpp
llvm/lib/Transforms/IPO/IPO.cpp
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Rename initializeReversePostOrderFunctionAttrsPass -> initializeReversePostOrderFunctionAttrsLegacyPassPass
(note that the "PassPass" thing falls out of `s/ReversePostOrderFunctionAttrs/ReversePostOrderFunctionAttrsLegacyPass/`)
Note that the INITIALIZE_PASS macro is what creates this identifier name, so renaming the class requires this renaming too.
Note that createReversePostOrderFunctionAttrsPass does not need to be
renamed since its name is not generated from the class name.
3. Add the new PM pass class.
In the new PM all passes need to have their
declaration in a header somewhere, so you will often need to add a header.
In this case
llvm/include/llvm/Transforms/IPO/FunctionAttrs.h is already there because
PostOrderFunctionAttrsPass was already ported.
The file-level comment from the .cpp file can be used as the file-level
comment for the new header. You may want to tweak the wording slightly
from "this file implements" to "this file provides" or similar.
Add declaration for the new PM pass in this header:
class ReversePostOrderFunctionAttrsPass
: public PassInfoMixin<ReversePostOrderFunctionAttrsPass> {
public:
PreservedAnalyses run(Module &M, AnalysisManager<Module> &AM);
};
Its name should end with `Pass` for consistency (note that this doesn't
collide with the names of most old PM passes). E.g. call it
`<name of the old PM pass>Pass`.
Also, move the doxygen comment from the old PM pass to the declaration of
this class in the header.
Also, include the declaration for the new PM class
`llvm/Transforms/IPO/FunctionAttrs.h` at the top of the file (in this case,
it was already done when the other pass in this file was ported).
Now define the `run` method for the new class.
The main things here are:
a) Use AM.getResult<...>(M) to get results instead of `getAnalysis<...>()`
b) If the old PM pass would have returned "false" (i.e. `Changed ==
false`), then you should return PreservedAnalyses::all();
c) In the old PM getAnalysisUsage method, observe the calls
`AU.addPreserved<...>();`.
In the case `Changed == true`, for each preserved analysis you should do
call `PA.preserve<...>()` on a PreservedAnalyses object and return it.
E.g.:
PreservedAnalyses PA;
PA.preserve<CallGraphAnalysis>();
return PA;
Note that calls to skipModule/skipFunction are not supported in the new PM
currently, so optnone and optimization bisect support do not work. You can
just drop those calls for now.
4. Add the pass to the new PM pass registry to make it available in opt.
In llvm/lib/Passes/PassBuilder.cpp add a #include for your header.
`#include "llvm/Transforms/IPO/FunctionAttrs.h"`
In this case there is already an include (from when
PostOrderFunctionAttrsPass was ported).
Add your pass to llvm/lib/Passes/PassRegistry.def
In this case, I added
`MODULE_PASS("rpo-functionattrs", ReversePostOrderFunctionAttrsPass())`
The string is from the `INITIALIZE_PASS*` macros used in the old pass
manager.
Then choose a test that uses the pass and use the new PM `-passes=...` to
run it.
E.g. in this case there is a test that does:
; RUN: opt < %s -basicaa -functionattrs -rpo-functionattrs -S | FileCheck %s
I have added the line:
; RUN: opt < %s -aa-pipeline=basic-aa -passes='require<targetlibinfo>,cgscc(function-attrs),rpo-functionattrs' -S | FileCheck %s
The `-aa-pipeline=basic-aa` and
`require<targetlibinfo>,cgscc(function-attrs)` are what is needed to run
functionattrs in the new PM (note that in the new PM "functionattrs"
becomes "function-attrs" for some reason). This is just pulled from
`readattrs.ll` which contains the change from when functionattrs was ported
to the new PM.
Adding rpo-functionattrs causes the pass that was just ported to run.
llvm-svn: 272505
2016-06-12 15:48:51 +08:00
|
|
|
bool ReversePostOrderFunctionAttrsLegacyPass::runOnModule(Module &M) {
|
2016-06-12 13:44:51 +08:00
|
|
|
if (skipModule(M))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
auto &CG = getAnalysis<CallGraphWrapperPass>().getCallGraph();
|
|
|
|
|
|
|
|
return deduceFunctionAttributeInRPO(M, CG);
|
|
|
|
}
|
[PM] Port ReversePostOrderFunctionAttrs to the new PM
Below are my super rough notes when porting. They can probably serve as
a basic guide for porting other passes to the new PM. As I port more
passes I'll expand and generalize this and make a proper
docs/HowToPortToNewPassManager.rst document. There is also missing
documentation for general concepts and API's in the new PM which will
require some documentation.
Once there is proper documentation in place we can put up a list of
passes that have to be ported and game-ify/crowdsource the rest of the
porting (at least of the middle end; the backend is still unclear).
I will however be taking personal responsibility for ensuring that the
LLD/ELF LTO pipeline is ported in a timely fashion. The remaining passes
to be ported are (do something like
`git grep "<the string in the bullet point below>"` to find the pass):
General Scalar:
[ ] Simplify the CFG
[ ] Jump Threading
[ ] MemCpy Optimization
[ ] Promote Memory to Register
[ ] MergedLoadStoreMotion
[ ] Lazy Value Information Analysis
General IPO:
[ ] Dead Argument Elimination
[ ] Deduce function attributes in RPO
Loop stuff / vectorization stuff:
[ ] Alignment from assumptions
[ ] Canonicalize natural loops
[ ] Delete dead loops
[ ] Loop Access Analysis
[ ] Loop Invariant Code Motion
[ ] Loop Vectorization
[ ] SLP Vectorizer
[ ] Unroll loops
Devirtualization / CFI:
[ ] Cross-DSO CFI
[ ] Whole program devirtualization
[ ] Lower bitset metadata
CGSCC passes:
[ ] Function Integration/Inlining
[ ] Remove unused exception handling info
[ ] Promote 'by reference' arguments to scalars
Please let me know if you are interested in working on any of the passes
in the above list (e.g. reply to the post-commit thread for this patch).
I'll probably be tackling "General Scalar" and "General IPO" first FWIW.
Steps as I port "Deduce function attributes in RPO"
---------------------------------------------------
(note: if you are doing any work based on these notes, please leave a
note in the post-commit review thread for this commit with any
improvements / suggestions / incompleteness you ran into!)
Note: "Deduce function attributes in RPO" is a module pass.
1. Do preparatory refactoring.
Do preparatory factoring. In this case all I had to do was to pull out a static helper (r272503).
(TODO: give more advice here e.g. if pass holds state or something)
2. Rename the old pass class.
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Rename class ReversePostOrderFunctionAttrs -> ReversePostOrderFunctionAttrsLegacyPass
in preparation for adding a class ReversePostOrderFunctionAttrs as the pass in the new PM.
(edit: actually wait what? The new class name will be
ReversePostOrderFunctionAttrsPass, so it doesn't conflict. So this step is
sort of useless churn).
llvm/include/llvm/InitializePasses.h
llvm/lib/LTO/LTOCodeGenerator.cpp
llvm/lib/Transforms/IPO/IPO.cpp
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Rename initializeReversePostOrderFunctionAttrsPass -> initializeReversePostOrderFunctionAttrsLegacyPassPass
(note that the "PassPass" thing falls out of `s/ReversePostOrderFunctionAttrs/ReversePostOrderFunctionAttrsLegacyPass/`)
Note that the INITIALIZE_PASS macro is what creates this identifier name, so renaming the class requires this renaming too.
Note that createReversePostOrderFunctionAttrsPass does not need to be
renamed since its name is not generated from the class name.
3. Add the new PM pass class.
In the new PM all passes need to have their
declaration in a header somewhere, so you will often need to add a header.
In this case
llvm/include/llvm/Transforms/IPO/FunctionAttrs.h is already there because
PostOrderFunctionAttrsPass was already ported.
The file-level comment from the .cpp file can be used as the file-level
comment for the new header. You may want to tweak the wording slightly
from "this file implements" to "this file provides" or similar.
Add declaration for the new PM pass in this header:
class ReversePostOrderFunctionAttrsPass
: public PassInfoMixin<ReversePostOrderFunctionAttrsPass> {
public:
PreservedAnalyses run(Module &M, AnalysisManager<Module> &AM);
};
Its name should end with `Pass` for consistency (note that this doesn't
collide with the names of most old PM passes). E.g. call it
`<name of the old PM pass>Pass`.
Also, move the doxygen comment from the old PM pass to the declaration of
this class in the header.
Also, include the declaration for the new PM class
`llvm/Transforms/IPO/FunctionAttrs.h` at the top of the file (in this case,
it was already done when the other pass in this file was ported).
Now define the `run` method for the new class.
The main things here are:
a) Use AM.getResult<...>(M) to get results instead of `getAnalysis<...>()`
b) If the old PM pass would have returned "false" (i.e. `Changed ==
false`), then you should return PreservedAnalyses::all();
c) In the old PM getAnalysisUsage method, observe the calls
`AU.addPreserved<...>();`.
In the case `Changed == true`, for each preserved analysis you should do
call `PA.preserve<...>()` on a PreservedAnalyses object and return it.
E.g.:
PreservedAnalyses PA;
PA.preserve<CallGraphAnalysis>();
return PA;
Note that calls to skipModule/skipFunction are not supported in the new PM
currently, so optnone and optimization bisect support do not work. You can
just drop those calls for now.
4. Add the pass to the new PM pass registry to make it available in opt.
In llvm/lib/Passes/PassBuilder.cpp add a #include for your header.
`#include "llvm/Transforms/IPO/FunctionAttrs.h"`
In this case there is already an include (from when
PostOrderFunctionAttrsPass was ported).
Add your pass to llvm/lib/Passes/PassRegistry.def
In this case, I added
`MODULE_PASS("rpo-functionattrs", ReversePostOrderFunctionAttrsPass())`
The string is from the `INITIALIZE_PASS*` macros used in the old pass
manager.
Then choose a test that uses the pass and use the new PM `-passes=...` to
run it.
E.g. in this case there is a test that does:
; RUN: opt < %s -basicaa -functionattrs -rpo-functionattrs -S | FileCheck %s
I have added the line:
; RUN: opt < %s -aa-pipeline=basic-aa -passes='require<targetlibinfo>,cgscc(function-attrs),rpo-functionattrs' -S | FileCheck %s
The `-aa-pipeline=basic-aa` and
`require<targetlibinfo>,cgscc(function-attrs)` are what is needed to run
functionattrs in the new PM (note that in the new PM "functionattrs"
becomes "function-attrs" for some reason). This is just pulled from
`readattrs.ll` which contains the change from when functionattrs was ported
to the new PM.
Adding rpo-functionattrs causes the pass that was just ported to run.
llvm-svn: 272505
2016-06-12 15:48:51 +08:00
|
|
|
|
|
|
|
PreservedAnalyses
|
2016-08-09 08:28:38 +08:00
|
|
|
ReversePostOrderFunctionAttrsPass::run(Module &M, ModuleAnalysisManager &AM) {
|
[PM] Port ReversePostOrderFunctionAttrs to the new PM
Below are my super rough notes when porting. They can probably serve as
a basic guide for porting other passes to the new PM. As I port more
passes I'll expand and generalize this and make a proper
docs/HowToPortToNewPassManager.rst document. There is also missing
documentation for general concepts and API's in the new PM which will
require some documentation.
Once there is proper documentation in place we can put up a list of
passes that have to be ported and game-ify/crowdsource the rest of the
porting (at least of the middle end; the backend is still unclear).
I will however be taking personal responsibility for ensuring that the
LLD/ELF LTO pipeline is ported in a timely fashion. The remaining passes
to be ported are (do something like
`git grep "<the string in the bullet point below>"` to find the pass):
General Scalar:
[ ] Simplify the CFG
[ ] Jump Threading
[ ] MemCpy Optimization
[ ] Promote Memory to Register
[ ] MergedLoadStoreMotion
[ ] Lazy Value Information Analysis
General IPO:
[ ] Dead Argument Elimination
[ ] Deduce function attributes in RPO
Loop stuff / vectorization stuff:
[ ] Alignment from assumptions
[ ] Canonicalize natural loops
[ ] Delete dead loops
[ ] Loop Access Analysis
[ ] Loop Invariant Code Motion
[ ] Loop Vectorization
[ ] SLP Vectorizer
[ ] Unroll loops
Devirtualization / CFI:
[ ] Cross-DSO CFI
[ ] Whole program devirtualization
[ ] Lower bitset metadata
CGSCC passes:
[ ] Function Integration/Inlining
[ ] Remove unused exception handling info
[ ] Promote 'by reference' arguments to scalars
Please let me know if you are interested in working on any of the passes
in the above list (e.g. reply to the post-commit thread for this patch).
I'll probably be tackling "General Scalar" and "General IPO" first FWIW.
Steps as I port "Deduce function attributes in RPO"
---------------------------------------------------
(note: if you are doing any work based on these notes, please leave a
note in the post-commit review thread for this commit with any
improvements / suggestions / incompleteness you ran into!)
Note: "Deduce function attributes in RPO" is a module pass.
1. Do preparatory refactoring.
Do preparatory factoring. In this case all I had to do was to pull out a static helper (r272503).
(TODO: give more advice here e.g. if pass holds state or something)
2. Rename the old pass class.
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Rename class ReversePostOrderFunctionAttrs -> ReversePostOrderFunctionAttrsLegacyPass
in preparation for adding a class ReversePostOrderFunctionAttrs as the pass in the new PM.
(edit: actually wait what? The new class name will be
ReversePostOrderFunctionAttrsPass, so it doesn't conflict. So this step is
sort of useless churn).
llvm/include/llvm/InitializePasses.h
llvm/lib/LTO/LTOCodeGenerator.cpp
llvm/lib/Transforms/IPO/IPO.cpp
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Rename initializeReversePostOrderFunctionAttrsPass -> initializeReversePostOrderFunctionAttrsLegacyPassPass
(note that the "PassPass" thing falls out of `s/ReversePostOrderFunctionAttrs/ReversePostOrderFunctionAttrsLegacyPass/`)
Note that the INITIALIZE_PASS macro is what creates this identifier name, so renaming the class requires this renaming too.
Note that createReversePostOrderFunctionAttrsPass does not need to be
renamed since its name is not generated from the class name.
3. Add the new PM pass class.
In the new PM all passes need to have their
declaration in a header somewhere, so you will often need to add a header.
In this case
llvm/include/llvm/Transforms/IPO/FunctionAttrs.h is already there because
PostOrderFunctionAttrsPass was already ported.
The file-level comment from the .cpp file can be used as the file-level
comment for the new header. You may want to tweak the wording slightly
from "this file implements" to "this file provides" or similar.
Add declaration for the new PM pass in this header:
class ReversePostOrderFunctionAttrsPass
: public PassInfoMixin<ReversePostOrderFunctionAttrsPass> {
public:
PreservedAnalyses run(Module &M, AnalysisManager<Module> &AM);
};
Its name should end with `Pass` for consistency (note that this doesn't
collide with the names of most old PM passes). E.g. call it
`<name of the old PM pass>Pass`.
Also, move the doxygen comment from the old PM pass to the declaration of
this class in the header.
Also, include the declaration for the new PM class
`llvm/Transforms/IPO/FunctionAttrs.h` at the top of the file (in this case,
it was already done when the other pass in this file was ported).
Now define the `run` method for the new class.
The main things here are:
a) Use AM.getResult<...>(M) to get results instead of `getAnalysis<...>()`
b) If the old PM pass would have returned "false" (i.e. `Changed ==
false`), then you should return PreservedAnalyses::all();
c) In the old PM getAnalysisUsage method, observe the calls
`AU.addPreserved<...>();`.
In the case `Changed == true`, for each preserved analysis you should do
call `PA.preserve<...>()` on a PreservedAnalyses object and return it.
E.g.:
PreservedAnalyses PA;
PA.preserve<CallGraphAnalysis>();
return PA;
Note that calls to skipModule/skipFunction are not supported in the new PM
currently, so optnone and optimization bisect support do not work. You can
just drop those calls for now.
4. Add the pass to the new PM pass registry to make it available in opt.
In llvm/lib/Passes/PassBuilder.cpp add a #include for your header.
`#include "llvm/Transforms/IPO/FunctionAttrs.h"`
In this case there is already an include (from when
PostOrderFunctionAttrsPass was ported).
Add your pass to llvm/lib/Passes/PassRegistry.def
In this case, I added
`MODULE_PASS("rpo-functionattrs", ReversePostOrderFunctionAttrsPass())`
The string is from the `INITIALIZE_PASS*` macros used in the old pass
manager.
Then choose a test that uses the pass and use the new PM `-passes=...` to
run it.
E.g. in this case there is a test that does:
; RUN: opt < %s -basicaa -functionattrs -rpo-functionattrs -S | FileCheck %s
I have added the line:
; RUN: opt < %s -aa-pipeline=basic-aa -passes='require<targetlibinfo>,cgscc(function-attrs),rpo-functionattrs' -S | FileCheck %s
The `-aa-pipeline=basic-aa` and
`require<targetlibinfo>,cgscc(function-attrs)` are what is needed to run
functionattrs in the new PM (note that in the new PM "functionattrs"
becomes "function-attrs" for some reason). This is just pulled from
`readattrs.ll` which contains the change from when functionattrs was ported
to the new PM.
Adding rpo-functionattrs causes the pass that was just ported to run.
llvm-svn: 272505
2016-06-12 15:48:51 +08:00
|
|
|
auto &CG = AM.getResult<CallGraphAnalysis>(M);
|
|
|
|
|
2017-01-24 20:55:57 +08:00
|
|
|
if (!deduceFunctionAttributeInRPO(M, CG))
|
[PM] Port ReversePostOrderFunctionAttrs to the new PM
Below are my super rough notes when porting. They can probably serve as
a basic guide for porting other passes to the new PM. As I port more
passes I'll expand and generalize this and make a proper
docs/HowToPortToNewPassManager.rst document. There is also missing
documentation for general concepts and API's in the new PM which will
require some documentation.
Once there is proper documentation in place we can put up a list of
passes that have to be ported and game-ify/crowdsource the rest of the
porting (at least of the middle end; the backend is still unclear).
I will however be taking personal responsibility for ensuring that the
LLD/ELF LTO pipeline is ported in a timely fashion. The remaining passes
to be ported are (do something like
`git grep "<the string in the bullet point below>"` to find the pass):
General Scalar:
[ ] Simplify the CFG
[ ] Jump Threading
[ ] MemCpy Optimization
[ ] Promote Memory to Register
[ ] MergedLoadStoreMotion
[ ] Lazy Value Information Analysis
General IPO:
[ ] Dead Argument Elimination
[ ] Deduce function attributes in RPO
Loop stuff / vectorization stuff:
[ ] Alignment from assumptions
[ ] Canonicalize natural loops
[ ] Delete dead loops
[ ] Loop Access Analysis
[ ] Loop Invariant Code Motion
[ ] Loop Vectorization
[ ] SLP Vectorizer
[ ] Unroll loops
Devirtualization / CFI:
[ ] Cross-DSO CFI
[ ] Whole program devirtualization
[ ] Lower bitset metadata
CGSCC passes:
[ ] Function Integration/Inlining
[ ] Remove unused exception handling info
[ ] Promote 'by reference' arguments to scalars
Please let me know if you are interested in working on any of the passes
in the above list (e.g. reply to the post-commit thread for this patch).
I'll probably be tackling "General Scalar" and "General IPO" first FWIW.
Steps as I port "Deduce function attributes in RPO"
---------------------------------------------------
(note: if you are doing any work based on these notes, please leave a
note in the post-commit review thread for this commit with any
improvements / suggestions / incompleteness you ran into!)
Note: "Deduce function attributes in RPO" is a module pass.
1. Do preparatory refactoring.
Do preparatory factoring. In this case all I had to do was to pull out a static helper (r272503).
(TODO: give more advice here e.g. if pass holds state or something)
2. Rename the old pass class.
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Rename class ReversePostOrderFunctionAttrs -> ReversePostOrderFunctionAttrsLegacyPass
in preparation for adding a class ReversePostOrderFunctionAttrs as the pass in the new PM.
(edit: actually wait what? The new class name will be
ReversePostOrderFunctionAttrsPass, so it doesn't conflict. So this step is
sort of useless churn).
llvm/include/llvm/InitializePasses.h
llvm/lib/LTO/LTOCodeGenerator.cpp
llvm/lib/Transforms/IPO/IPO.cpp
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Rename initializeReversePostOrderFunctionAttrsPass -> initializeReversePostOrderFunctionAttrsLegacyPassPass
(note that the "PassPass" thing falls out of `s/ReversePostOrderFunctionAttrs/ReversePostOrderFunctionAttrsLegacyPass/`)
Note that the INITIALIZE_PASS macro is what creates this identifier name, so renaming the class requires this renaming too.
Note that createReversePostOrderFunctionAttrsPass does not need to be
renamed since its name is not generated from the class name.
3. Add the new PM pass class.
In the new PM all passes need to have their
declaration in a header somewhere, so you will often need to add a header.
In this case
llvm/include/llvm/Transforms/IPO/FunctionAttrs.h is already there because
PostOrderFunctionAttrsPass was already ported.
The file-level comment from the .cpp file can be used as the file-level
comment for the new header. You may want to tweak the wording slightly
from "this file implements" to "this file provides" or similar.
Add declaration for the new PM pass in this header:
class ReversePostOrderFunctionAttrsPass
: public PassInfoMixin<ReversePostOrderFunctionAttrsPass> {
public:
PreservedAnalyses run(Module &M, AnalysisManager<Module> &AM);
};
Its name should end with `Pass` for consistency (note that this doesn't
collide with the names of most old PM passes). E.g. call it
`<name of the old PM pass>Pass`.
Also, move the doxygen comment from the old PM pass to the declaration of
this class in the header.
Also, include the declaration for the new PM class
`llvm/Transforms/IPO/FunctionAttrs.h` at the top of the file (in this case,
it was already done when the other pass in this file was ported).
Now define the `run` method for the new class.
The main things here are:
a) Use AM.getResult<...>(M) to get results instead of `getAnalysis<...>()`
b) If the old PM pass would have returned "false" (i.e. `Changed ==
false`), then you should return PreservedAnalyses::all();
c) In the old PM getAnalysisUsage method, observe the calls
`AU.addPreserved<...>();`.
In the case `Changed == true`, for each preserved analysis you should do
call `PA.preserve<...>()` on a PreservedAnalyses object and return it.
E.g.:
PreservedAnalyses PA;
PA.preserve<CallGraphAnalysis>();
return PA;
Note that calls to skipModule/skipFunction are not supported in the new PM
currently, so optnone and optimization bisect support do not work. You can
just drop those calls for now.
4. Add the pass to the new PM pass registry to make it available in opt.
In llvm/lib/Passes/PassBuilder.cpp add a #include for your header.
`#include "llvm/Transforms/IPO/FunctionAttrs.h"`
In this case there is already an include (from when
PostOrderFunctionAttrsPass was ported).
Add your pass to llvm/lib/Passes/PassRegistry.def
In this case, I added
`MODULE_PASS("rpo-functionattrs", ReversePostOrderFunctionAttrsPass())`
The string is from the `INITIALIZE_PASS*` macros used in the old pass
manager.
Then choose a test that uses the pass and use the new PM `-passes=...` to
run it.
E.g. in this case there is a test that does:
; RUN: opt < %s -basicaa -functionattrs -rpo-functionattrs -S | FileCheck %s
I have added the line:
; RUN: opt < %s -aa-pipeline=basic-aa -passes='require<targetlibinfo>,cgscc(function-attrs),rpo-functionattrs' -S | FileCheck %s
The `-aa-pipeline=basic-aa` and
`require<targetlibinfo>,cgscc(function-attrs)` are what is needed to run
functionattrs in the new PM (note that in the new PM "functionattrs"
becomes "function-attrs" for some reason). This is just pulled from
`readattrs.ll` which contains the change from when functionattrs was ported
to the new PM.
Adding rpo-functionattrs causes the pass that was just ported to run.
llvm-svn: 272505
2016-06-12 15:48:51 +08:00
|
|
|
return PreservedAnalyses::all();
|
2017-01-24 20:55:57 +08:00
|
|
|
|
[PM] Port ReversePostOrderFunctionAttrs to the new PM
Below are my super rough notes when porting. They can probably serve as
a basic guide for porting other passes to the new PM. As I port more
passes I'll expand and generalize this and make a proper
docs/HowToPortToNewPassManager.rst document. There is also missing
documentation for general concepts and API's in the new PM which will
require some documentation.
Once there is proper documentation in place we can put up a list of
passes that have to be ported and game-ify/crowdsource the rest of the
porting (at least of the middle end; the backend is still unclear).
I will however be taking personal responsibility for ensuring that the
LLD/ELF LTO pipeline is ported in a timely fashion. The remaining passes
to be ported are (do something like
`git grep "<the string in the bullet point below>"` to find the pass):
General Scalar:
[ ] Simplify the CFG
[ ] Jump Threading
[ ] MemCpy Optimization
[ ] Promote Memory to Register
[ ] MergedLoadStoreMotion
[ ] Lazy Value Information Analysis
General IPO:
[ ] Dead Argument Elimination
[ ] Deduce function attributes in RPO
Loop stuff / vectorization stuff:
[ ] Alignment from assumptions
[ ] Canonicalize natural loops
[ ] Delete dead loops
[ ] Loop Access Analysis
[ ] Loop Invariant Code Motion
[ ] Loop Vectorization
[ ] SLP Vectorizer
[ ] Unroll loops
Devirtualization / CFI:
[ ] Cross-DSO CFI
[ ] Whole program devirtualization
[ ] Lower bitset metadata
CGSCC passes:
[ ] Function Integration/Inlining
[ ] Remove unused exception handling info
[ ] Promote 'by reference' arguments to scalars
Please let me know if you are interested in working on any of the passes
in the above list (e.g. reply to the post-commit thread for this patch).
I'll probably be tackling "General Scalar" and "General IPO" first FWIW.
Steps as I port "Deduce function attributes in RPO"
---------------------------------------------------
(note: if you are doing any work based on these notes, please leave a
note in the post-commit review thread for this commit with any
improvements / suggestions / incompleteness you ran into!)
Note: "Deduce function attributes in RPO" is a module pass.
1. Do preparatory refactoring.
Do preparatory factoring. In this case all I had to do was to pull out a static helper (r272503).
(TODO: give more advice here e.g. if pass holds state or something)
2. Rename the old pass class.
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Rename class ReversePostOrderFunctionAttrs -> ReversePostOrderFunctionAttrsLegacyPass
in preparation for adding a class ReversePostOrderFunctionAttrs as the pass in the new PM.
(edit: actually wait what? The new class name will be
ReversePostOrderFunctionAttrsPass, so it doesn't conflict. So this step is
sort of useless churn).
llvm/include/llvm/InitializePasses.h
llvm/lib/LTO/LTOCodeGenerator.cpp
llvm/lib/Transforms/IPO/IPO.cpp
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Rename initializeReversePostOrderFunctionAttrsPass -> initializeReversePostOrderFunctionAttrsLegacyPassPass
(note that the "PassPass" thing falls out of `s/ReversePostOrderFunctionAttrs/ReversePostOrderFunctionAttrsLegacyPass/`)
Note that the INITIALIZE_PASS macro is what creates this identifier name, so renaming the class requires this renaming too.
Note that createReversePostOrderFunctionAttrsPass does not need to be
renamed since its name is not generated from the class name.
3. Add the new PM pass class.
In the new PM all passes need to have their
declaration in a header somewhere, so you will often need to add a header.
In this case
llvm/include/llvm/Transforms/IPO/FunctionAttrs.h is already there because
PostOrderFunctionAttrsPass was already ported.
The file-level comment from the .cpp file can be used as the file-level
comment for the new header. You may want to tweak the wording slightly
from "this file implements" to "this file provides" or similar.
Add declaration for the new PM pass in this header:
class ReversePostOrderFunctionAttrsPass
: public PassInfoMixin<ReversePostOrderFunctionAttrsPass> {
public:
PreservedAnalyses run(Module &M, AnalysisManager<Module> &AM);
};
Its name should end with `Pass` for consistency (note that this doesn't
collide with the names of most old PM passes). E.g. call it
`<name of the old PM pass>Pass`.
Also, move the doxygen comment from the old PM pass to the declaration of
this class in the header.
Also, include the declaration for the new PM class
`llvm/Transforms/IPO/FunctionAttrs.h` at the top of the file (in this case,
it was already done when the other pass in this file was ported).
Now define the `run` method for the new class.
The main things here are:
a) Use AM.getResult<...>(M) to get results instead of `getAnalysis<...>()`
b) If the old PM pass would have returned "false" (i.e. `Changed ==
false`), then you should return PreservedAnalyses::all();
c) In the old PM getAnalysisUsage method, observe the calls
`AU.addPreserved<...>();`.
In the case `Changed == true`, for each preserved analysis you should do
call `PA.preserve<...>()` on a PreservedAnalyses object and return it.
E.g.:
PreservedAnalyses PA;
PA.preserve<CallGraphAnalysis>();
return PA;
Note that calls to skipModule/skipFunction are not supported in the new PM
currently, so optnone and optimization bisect support do not work. You can
just drop those calls for now.
4. Add the pass to the new PM pass registry to make it available in opt.
In llvm/lib/Passes/PassBuilder.cpp add a #include for your header.
`#include "llvm/Transforms/IPO/FunctionAttrs.h"`
In this case there is already an include (from when
PostOrderFunctionAttrsPass was ported).
Add your pass to llvm/lib/Passes/PassRegistry.def
In this case, I added
`MODULE_PASS("rpo-functionattrs", ReversePostOrderFunctionAttrsPass())`
The string is from the `INITIALIZE_PASS*` macros used in the old pass
manager.
Then choose a test that uses the pass and use the new PM `-passes=...` to
run it.
E.g. in this case there is a test that does:
; RUN: opt < %s -basicaa -functionattrs -rpo-functionattrs -S | FileCheck %s
I have added the line:
; RUN: opt < %s -aa-pipeline=basic-aa -passes='require<targetlibinfo>,cgscc(function-attrs),rpo-functionattrs' -S | FileCheck %s
The `-aa-pipeline=basic-aa` and
`require<targetlibinfo>,cgscc(function-attrs)` are what is needed to run
functionattrs in the new PM (note that in the new PM "functionattrs"
becomes "function-attrs" for some reason). This is just pulled from
`readattrs.ll` which contains the change from when functionattrs was ported
to the new PM.
Adding rpo-functionattrs causes the pass that was just ported to run.
llvm-svn: 272505
2016-06-12 15:48:51 +08:00
|
|
|
PreservedAnalyses PA;
|
|
|
|
PA.preserve<CallGraphAnalysis>();
|
|
|
|
return PA;
|
|
|
|
}
|