2003-05-29 23:11:31 +08:00
|
|
|
//===- InlineFunction.cpp - Code to perform function inlining -------------===//
|
2005-04-22 07:48:37 +08:00
|
|
|
//
|
2003-10-21 03:43:21 +08:00
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
2007-12-30 04:36:04 +08:00
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
2005-04-22 07:48:37 +08:00
|
|
|
//
|
2003-10-21 03:43:21 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2003-05-29 23:11:31 +08:00
|
|
|
//
|
|
|
|
// This file implements inlining of a function into a call site, resolving
|
|
|
|
// parameters and the return value as appropriate.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "llvm/Transforms/Utils/Cloning.h"
|
2015-11-25 02:57:06 +08:00
|
|
|
#include "llvm/ADT/SetVector.h"
|
Add scoped-noalias metadata
This commit adds scoped noalias metadata. The primary motivations for this
feature are:
1. To preserve noalias function attribute information when inlining
2. To provide the ability to model block-scope C99 restrict pointers
Neither of these two abilities are added here, only the necessary
infrastructure. In fact, there should be no change to existing functionality,
only the addition of new features. The logic that converts noalias function
parameters into this metadata during inlining will come in a follow-up commit.
What is added here is the ability to generally specify noalias memory-access
sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA
nodes:
!scope0 = metadata !{ metadata !"scope of foo()" }
!scope1 = metadata !{ metadata !"scope 1", metadata !scope0 }
!scope2 = metadata !{ metadata !"scope 2", metadata !scope0 }
!scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 }
!scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 }
Loads and stores can be tagged with an alias-analysis scope, and also, with a
noalias tag for a specific scope:
... = load %ptr1, !alias.scope !{ !scope1 }
... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 }
When evaluating an aliasing query, if one of the instructions is associated
with an alias.scope id that is identical to the noalias scope associated with
the other instruction, or is a descendant (in the scope hierarchy) of the
noalias scope associated with the other instruction, then the two memory
accesses are assumed not to alias.
Note that is the first element of the scope metadata is a string, then it can
be combined accross functions and translation units. The string can be replaced
by a self-reference to create globally unqiue scope identifiers.
[Note: This overview is slightly stylized, since the metadata nodes really need
to just be numbers (!0 instead of !scope0), and the scope lists are also global
unnamed metadata.]
Existing noalias metadata in a callee is "cloned" for use by the inlined code.
This is necessary because the aliasing scopes are unique to each call site
(because of possible control dependencies on the aliasing properties). For
example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets
inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } --
now just because we know that a1 does not alias with b1 at the first call site,
and a2 does not alias with b2 at the second call site, we cannot let inlining
these functons have the metadata imply that a1 does not alias with b2.
llvm-svn: 213864
2014-07-24 22:25:39 +08:00
|
|
|
#include "llvm/ADT/SmallSet.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/ADT/SmallVector.h"
|
|
|
|
#include "llvm/ADT/StringExtras.h"
|
2014-07-25 23:50:08 +08:00
|
|
|
#include "llvm/Analysis/AliasAnalysis.h"
|
2015-01-04 20:03:27 +08:00
|
|
|
#include "llvm/Analysis/AssumptionCache.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/Analysis/CallGraph.h"
|
2014-07-25 23:50:08 +08:00
|
|
|
#include "llvm/Analysis/CaptureTracking.h"
|
[IR] Reformulate LLVM's EH funclet IR
While we have successfully implemented a funclet-oriented EH scheme on
top of LLVM IR, our scheme has some notable deficiencies:
- catchendpad and cleanupendpad are necessary in the current design
but they are difficult to explain to others, even to seasoned LLVM
experts.
- catchendpad and cleanupendpad are optimization barriers. They cannot
be split and force all potentially throwing call-sites to be invokes.
This has a noticable effect on the quality of our code generation.
- catchpad, while similar in some aspects to invoke, is fairly awkward.
It is unsplittable, starts a funclet, and has control flow to other
funclets.
- The nesting relationship between funclets is currently a property of
control flow edges. Because of this, we are forced to carefully
analyze the flow graph to see if there might potentially exist illegal
nesting among funclets. While we have logic to clone funclets when
they are illegally nested, it would be nicer if we had a
representation which forbade them upfront.
Let's clean this up a bit by doing the following:
- Instead, make catchpad more like cleanuppad and landingpad: no control
flow, just a bunch of simple operands; catchpad would be splittable.
- Introduce catchswitch, a control flow instruction designed to model
the constraints of funclet oriented EH.
- Make funclet scoping explicit by having funclet instructions consume
the token produced by the funclet which contains them.
- Remove catchendpad and cleanupendpad. Their presence can be inferred
implicitly using coloring information.
N.B. The state numbering code for the CLR has been updated but the
veracity of it's output cannot be spoken for. An expert should take a
look to make sure the results are reasonable.
Reviewers: rnk, JosephTremoulet, andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D15139
llvm-svn: 255422
2015-12-12 13:38:55 +08:00
|
|
|
#include "llvm/Analysis/EHPersonalities.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/Analysis/InstructionSimplify.h"
|
Add scoped-noalias metadata
This commit adds scoped noalias metadata. The primary motivations for this
feature are:
1. To preserve noalias function attribute information when inlining
2. To provide the ability to model block-scope C99 restrict pointers
Neither of these two abilities are added here, only the necessary
infrastructure. In fact, there should be no change to existing functionality,
only the addition of new features. The logic that converts noalias function
parameters into this metadata during inlining will come in a follow-up commit.
What is added here is the ability to generally specify noalias memory-access
sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA
nodes:
!scope0 = metadata !{ metadata !"scope of foo()" }
!scope1 = metadata !{ metadata !"scope 1", metadata !scope0 }
!scope2 = metadata !{ metadata !"scope 2", metadata !scope0 }
!scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 }
!scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 }
Loads and stores can be tagged with an alias-analysis scope, and also, with a
noalias tag for a specific scope:
... = load %ptr1, !alias.scope !{ !scope1 }
... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 }
When evaluating an aliasing query, if one of the instructions is associated
with an alias.scope id that is identical to the noalias scope associated with
the other instruction, or is a descendant (in the scope hierarchy) of the
noalias scope associated with the other instruction, then the two memory
accesses are assumed not to alias.
Note that is the first element of the scope metadata is a string, then it can
be combined accross functions and translation units. The string can be replaced
by a self-reference to create globally unqiue scope identifiers.
[Note: This overview is slightly stylized, since the metadata nodes really need
to just be numbers (!0 instead of !scope0), and the scope lists are also global
unnamed metadata.]
Existing noalias metadata in a callee is "cloned" for use by the inlined code.
This is necessary because the aliasing scopes are unique to each call site
(because of possible control dependencies on the aliasing properties). For
example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets
inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } --
now just because we know that a1 does not alias with b1 at the first call site,
and a2 does not alias with b2 at the second call site, we cannot let inlining
these functons have the metadata imply that a1 does not alias with b2.
llvm-svn: 213864
2014-07-24 22:25:39 +08:00
|
|
|
#include "llvm/Analysis/ValueTracking.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/Attributes.h"
|
2014-03-04 19:01:28 +08:00
|
|
|
#include "llvm/IR/CallSite.h"
|
2014-05-16 04:11:28 +08:00
|
|
|
#include "llvm/IR/CFG.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/Constants.h"
|
|
|
|
#include "llvm/IR/DataLayout.h"
|
2014-03-06 08:46:21 +08:00
|
|
|
#include "llvm/IR/DebugInfo.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/DerivedTypes.h"
|
2015-01-31 03:37:48 +08:00
|
|
|
#include "llvm/IR/DIBuilder.h"
|
2014-07-25 23:50:08 +08:00
|
|
|
#include "llvm/IR/Dominators.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/IRBuilder.h"
|
|
|
|
#include "llvm/IR/Instructions.h"
|
|
|
|
#include "llvm/IR/IntrinsicInst.h"
|
|
|
|
#include "llvm/IR/Intrinsics.h"
|
Add scoped-noalias metadata
This commit adds scoped noalias metadata. The primary motivations for this
feature are:
1. To preserve noalias function attribute information when inlining
2. To provide the ability to model block-scope C99 restrict pointers
Neither of these two abilities are added here, only the necessary
infrastructure. In fact, there should be no change to existing functionality,
only the addition of new features. The logic that converts noalias function
parameters into this metadata during inlining will come in a follow-up commit.
What is added here is the ability to generally specify noalias memory-access
sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA
nodes:
!scope0 = metadata !{ metadata !"scope of foo()" }
!scope1 = metadata !{ metadata !"scope 1", metadata !scope0 }
!scope2 = metadata !{ metadata !"scope 2", metadata !scope0 }
!scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 }
!scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 }
Loads and stores can be tagged with an alias-analysis scope, and also, with a
noalias tag for a specific scope:
... = load %ptr1, !alias.scope !{ !scope1 }
... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 }
When evaluating an aliasing query, if one of the instructions is associated
with an alias.scope id that is identical to the noalias scope associated with
the other instruction, or is a descendant (in the scope hierarchy) of the
noalias scope associated with the other instruction, then the two memory
accesses are assumed not to alias.
Note that is the first element of the scope metadata is a string, then it can
be combined accross functions and translation units. The string can be replaced
by a self-reference to create globally unqiue scope identifiers.
[Note: This overview is slightly stylized, since the metadata nodes really need
to just be numbers (!0 instead of !scope0), and the scope lists are also global
unnamed metadata.]
Existing noalias metadata in a callee is "cloned" for use by the inlined code.
This is necessary because the aliasing scopes are unique to each call site
(because of possible control dependencies on the aliasing properties). For
example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets
inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } --
now just because we know that a1 does not alias with b1 at the first call site,
and a2 does not alias with b2 at the second call site, we cannot let inlining
these functons have the metadata imply that a1 does not alias with b2.
llvm-svn: 213864
2014-07-24 22:25:39 +08:00
|
|
|
#include "llvm/IR/MDBuilder.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/Module.h"
|
2010-12-26 04:42:38 +08:00
|
|
|
#include "llvm/Transforms/Utils/Local.h"
|
2014-07-25 23:50:08 +08:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
|
|
|
#include <algorithm>
|
2015-10-07 07:24:35 +08:00
|
|
|
|
2004-01-09 14:12:26 +08:00
|
|
|
using namespace llvm;
|
2003-05-29 23:11:31 +08:00
|
|
|
|
2014-07-25 23:50:08 +08:00
|
|
|
static cl::opt<bool>
|
2014-09-04 21:23:08 +08:00
|
|
|
EnableNoAliasConversion("enable-noalias-to-md-conversion", cl::init(true),
|
2014-07-25 23:50:08 +08:00
|
|
|
cl::Hidden,
|
|
|
|
cl::desc("Convert noalias attributes to metadata during inlining."));
|
|
|
|
|
2014-10-16 07:44:41 +08:00
|
|
|
static cl::opt<bool>
|
|
|
|
PreserveAlignmentAssumptions("preserve-alignment-assumptions-during-inlining",
|
|
|
|
cl::init(true), cl::Hidden,
|
|
|
|
cl::desc("Convert align attributes to assumptions during inlining."));
|
|
|
|
|
2012-03-27 03:09:38 +08:00
|
|
|
bool llvm::InlineFunction(CallInst *CI, InlineFunctionInfo &IFI,
|
[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
|
|
|
AAResults *CalleeAAR, bool InsertLifetime) {
|
|
|
|
return InlineFunction(CallSite(CI), IFI, CalleeAAR, InsertLifetime);
|
2006-01-15 04:07:50 +08:00
|
|
|
}
|
2012-03-27 03:09:38 +08:00
|
|
|
bool llvm::InlineFunction(InvokeInst *II, InlineFunctionInfo &IFI,
|
[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
|
|
|
AAResults *CalleeAAR, bool InsertLifetime) {
|
|
|
|
return InlineFunction(CallSite(II), IFI, CalleeAAR, InsertLifetime);
|
2006-01-15 04:07:50 +08:00
|
|
|
}
|
2003-08-24 14:59:16 +08:00
|
|
|
|
2011-05-28 02:34:38 +08:00
|
|
|
namespace {
|
2015-08-01 01:58:14 +08:00
|
|
|
/// A class for recording information about inlining a landing pad.
|
|
|
|
class LandingPadInliningInfo {
|
2012-06-09 08:01:45 +08:00
|
|
|
BasicBlock *OuterResumeDest; ///< Destination of the invoke's unwind.
|
|
|
|
BasicBlock *InnerResumeDest; ///< Destination for the callee's resume.
|
|
|
|
LandingPadInst *CallerLPad; ///< LandingPadInst associated with the invoke.
|
|
|
|
PHINode *InnerEHValuesPHI; ///< PHI for EH values from landingpad insts.
|
2012-01-31 09:22:03 +08:00
|
|
|
SmallVector<Value*, 8> UnwindDestPHIValues;
|
2011-08-14 16:01:36 +08:00
|
|
|
|
2011-07-28 08:38:23 +08:00
|
|
|
public:
|
2015-08-01 01:58:14 +08:00
|
|
|
LandingPadInliningInfo(InvokeInst *II)
|
2014-04-25 13:29:35 +08:00
|
|
|
: OuterResumeDest(II->getUnwindDest()), InnerResumeDest(nullptr),
|
|
|
|
CallerLPad(nullptr), InnerEHValuesPHI(nullptr) {
|
2011-08-14 16:01:36 +08:00
|
|
|
// If there are PHI nodes in the unwind destination block, we need to keep
|
|
|
|
// track of which values came into them from the invoke before removing
|
|
|
|
// the edge from this block.
|
|
|
|
llvm::BasicBlock *InvokeBB = II->getParent();
|
2012-01-31 09:25:54 +08:00
|
|
|
BasicBlock::iterator I = OuterResumeDest->begin();
|
2011-08-14 16:01:36 +08:00
|
|
|
for (; isa<PHINode>(I); ++I) {
|
2011-05-28 02:34:38 +08:00
|
|
|
// Save the value to use for this edge.
|
2011-08-14 16:01:36 +08:00
|
|
|
PHINode *PHI = cast<PHINode>(I);
|
|
|
|
UnwindDestPHIValues.push_back(PHI->getIncomingValueForBlock(InvokeBB));
|
|
|
|
}
|
|
|
|
|
2012-01-31 08:56:53 +08:00
|
|
|
CallerLPad = cast<LandingPadInst>(I);
|
2011-05-28 02:34:38 +08:00
|
|
|
}
|
|
|
|
|
2015-03-11 03:42:57 +08:00
|
|
|
/// The outer unwind destination is the target of
|
2012-01-31 09:25:54 +08:00
|
|
|
/// unwind edges introduced for calls within the inlined function.
|
2012-01-31 09:22:03 +08:00
|
|
|
BasicBlock *getOuterResumeDest() const {
|
2012-01-31 09:25:54 +08:00
|
|
|
return OuterResumeDest;
|
2011-05-28 02:34:38 +08:00
|
|
|
}
|
|
|
|
|
2012-01-31 09:48:40 +08:00
|
|
|
BasicBlock *getInnerResumeDest();
|
2011-08-14 16:01:36 +08:00
|
|
|
|
|
|
|
LandingPadInst *getLandingPadInst() const { return CallerLPad; }
|
|
|
|
|
2015-03-11 03:42:57 +08:00
|
|
|
/// Forward the 'resume' instruction to the caller's landing pad block.
|
|
|
|
/// When the landing pad block has only one predecessor, this is
|
2011-08-14 16:01:36 +08:00
|
|
|
/// a simple branch. When there is more than one predecessor, we need to
|
|
|
|
/// split the landing pad block after the landingpad instruction and jump
|
|
|
|
/// to there.
|
2013-03-23 04:31:05 +08:00
|
|
|
void forwardResume(ResumeInst *RI,
|
2014-08-21 13:55:13 +08:00
|
|
|
SmallPtrSetImpl<LandingPadInst*> &InlinedLPads);
|
2011-08-14 16:01:36 +08:00
|
|
|
|
2015-03-11 03:42:57 +08:00
|
|
|
/// Add incoming-PHI values to the unwind destination block for the given
|
|
|
|
/// basic block, using the values for the original invoke's source block.
|
2011-05-28 02:34:38 +08:00
|
|
|
void addIncomingPHIValuesFor(BasicBlock *BB) const {
|
2012-01-31 09:25:54 +08:00
|
|
|
addIncomingPHIValuesForInto(BB, OuterResumeDest);
|
2011-05-28 15:45:59 +08:00
|
|
|
}
|
Revert r136253, r136263, r136269, r136313, r136325, r136326, r136329, r136338,
r136339, r136341, r136369, r136387, r136392, r136396, r136429, r136430, r136444,
r136445, r136446, r136253 pending review.
llvm-svn: 136556
2011-07-30 13:42:50 +08:00
|
|
|
|
2011-05-28 15:45:59 +08:00
|
|
|
void addIncomingPHIValuesForInto(BasicBlock *src, BasicBlock *dest) const {
|
|
|
|
BasicBlock::iterator I = dest->begin();
|
2011-05-28 02:34:38 +08:00
|
|
|
for (unsigned i = 0, e = UnwindDestPHIValues.size(); i != e; ++i, ++I) {
|
Revert r136253, r136263, r136269, r136313, r136325, r136326, r136329, r136338,
r136339, r136341, r136369, r136387, r136392, r136396, r136429, r136430, r136444,
r136445, r136446, r136253 pending review.
llvm-svn: 136556
2011-07-30 13:42:50 +08:00
|
|
|
PHINode *phi = cast<PHINode>(I);
|
|
|
|
phi->addIncoming(UnwindDestPHIValues[i], src);
|
2011-05-28 02:34:38 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
};
|
2015-10-07 07:24:35 +08:00
|
|
|
} // anonymous namespace
|
2011-05-28 02:34:38 +08:00
|
|
|
|
2015-03-11 03:42:57 +08:00
|
|
|
/// Get or create a target for the branch from ResumeInsts.
|
2015-08-01 01:58:14 +08:00
|
|
|
BasicBlock *LandingPadInliningInfo::getInnerResumeDest() {
|
2011-08-14 16:01:36 +08:00
|
|
|
if (InnerResumeDest) return InnerResumeDest;
|
|
|
|
|
|
|
|
// Split the landing pad.
|
2015-10-13 10:39:05 +08:00
|
|
|
BasicBlock::iterator SplitPoint = ++CallerLPad->getIterator();
|
2011-08-14 16:01:36 +08:00
|
|
|
InnerResumeDest =
|
|
|
|
OuterResumeDest->splitBasicBlock(SplitPoint,
|
|
|
|
OuterResumeDest->getName() + ".body");
|
|
|
|
|
|
|
|
// The number of incoming edges we expect to the inner landing pad.
|
|
|
|
const unsigned PHICapacity = 2;
|
|
|
|
|
|
|
|
// Create corresponding new PHIs for all the PHIs in the outer landing pad.
|
2015-10-13 10:39:05 +08:00
|
|
|
Instruction *InsertPoint = &InnerResumeDest->front();
|
2011-08-14 16:01:36 +08:00
|
|
|
BasicBlock::iterator I = OuterResumeDest->begin();
|
|
|
|
for (unsigned i = 0, e = UnwindDestPHIValues.size(); i != e; ++i, ++I) {
|
|
|
|
PHINode *OuterPHI = cast<PHINode>(I);
|
|
|
|
PHINode *InnerPHI = PHINode::Create(OuterPHI->getType(), PHICapacity,
|
|
|
|
OuterPHI->getName() + ".lpad-body",
|
|
|
|
InsertPoint);
|
|
|
|
OuterPHI->replaceAllUsesWith(InnerPHI);
|
|
|
|
InnerPHI->addIncoming(OuterPHI, OuterResumeDest);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Create a PHI for the exception values.
|
|
|
|
InnerEHValuesPHI = PHINode::Create(CallerLPad->getType(), PHICapacity,
|
|
|
|
"eh.lpad-body", InsertPoint);
|
|
|
|
CallerLPad->replaceAllUsesWith(InnerEHValuesPHI);
|
|
|
|
InnerEHValuesPHI->addIncoming(CallerLPad, OuterResumeDest);
|
|
|
|
|
|
|
|
// All done.
|
|
|
|
return InnerResumeDest;
|
|
|
|
}
|
|
|
|
|
2015-03-11 03:42:57 +08:00
|
|
|
/// Forward the 'resume' instruction to the caller's landing pad block.
|
|
|
|
/// When the landing pad block has only one predecessor, this is a simple
|
2011-08-14 16:01:36 +08:00
|
|
|
/// branch. When there is more than one predecessor, we need to split the
|
|
|
|
/// landing pad block after the landingpad instruction and jump to there.
|
2015-08-01 01:58:14 +08:00
|
|
|
void LandingPadInliningInfo::forwardResume(
|
|
|
|
ResumeInst *RI, SmallPtrSetImpl<LandingPadInst *> &InlinedLPads) {
|
2012-01-31 09:48:40 +08:00
|
|
|
BasicBlock *Dest = getInnerResumeDest();
|
2011-08-14 16:01:36 +08:00
|
|
|
BasicBlock *Src = RI->getParent();
|
|
|
|
|
|
|
|
BranchInst::Create(Dest, Src);
|
|
|
|
|
|
|
|
// Update the PHIs in the destination. They were inserted in an order which
|
|
|
|
// makes this work.
|
|
|
|
addIncomingPHIValuesForInto(Src, Dest);
|
|
|
|
|
|
|
|
InnerEHValuesPHI->addIncoming(RI->getOperand(0), Src);
|
|
|
|
RI->eraseFromParent();
|
|
|
|
}
|
|
|
|
|
2015-03-11 03:42:57 +08:00
|
|
|
/// When we inline a basic block into an invoke,
|
|
|
|
/// we have to turn all of the calls that can throw into invokes.
|
|
|
|
/// This function analyze BB to see if there are any calls, and if so,
|
2009-08-27 11:51:50 +08:00
|
|
|
/// it rewrites them to be invokes that jump to InvokeDest and fills in the PHI
|
2009-09-02 02:44:06 +08:00
|
|
|
/// nodes in that block with the values specified in InvokeDestPHIValues.
|
2015-08-01 01:58:14 +08:00
|
|
|
static BasicBlock *
|
|
|
|
HandleCallsInBlockInlinedThroughInvoke(BasicBlock *BB, BasicBlock *UnwindEdge) {
|
2009-08-27 11:51:50 +08:00
|
|
|
for (BasicBlock::iterator BBI = BB->begin(), E = BB->end(); BBI != E; ) {
|
2015-10-13 10:39:05 +08:00
|
|
|
Instruction *I = &*BBI++;
|
2011-08-14 16:01:36 +08:00
|
|
|
|
2009-08-27 11:51:50 +08:00
|
|
|
// We only need to check for function calls: inlined invoke
|
|
|
|
// instructions require no special handling.
|
|
|
|
CallInst *CI = dyn_cast<CallInst>(I);
|
2012-01-31 09:05:20 +08:00
|
|
|
|
2013-11-01 05:56:03 +08:00
|
|
|
if (!CI || CI->doesNotThrow() || isa<InlineAsm>(CI->getCalledValue()))
|
2009-08-27 11:51:50 +08:00
|
|
|
continue;
|
2012-01-31 09:05:20 +08:00
|
|
|
|
|
|
|
// Convert this function call into an invoke instruction. First, split the
|
|
|
|
// basic block.
|
2015-10-13 10:39:05 +08:00
|
|
|
BasicBlock *Split =
|
|
|
|
BB->splitBasicBlock(CI->getIterator(), CI->getName() + ".noexc");
|
2011-05-28 02:34:38 +08:00
|
|
|
|
2011-05-28 15:45:59 +08:00
|
|
|
// Delete the unconditional branch inserted by splitBasicBlock
|
|
|
|
BB->getInstList().pop_back();
|
2011-05-28 02:34:38 +08:00
|
|
|
|
2012-01-31 09:14:49 +08:00
|
|
|
// Create the new invoke instruction.
|
2015-12-10 14:39:02 +08:00
|
|
|
SmallVector<Value*, 8> InvokeArgs(CI->arg_begin(), CI->arg_end());
|
2015-11-18 14:23:38 +08:00
|
|
|
SmallVector<OperandBundleDef, 1> OpBundles;
|
|
|
|
|
2015-12-10 14:39:02 +08:00
|
|
|
CI->getOperandBundlesAsDefs(OpBundles);
|
2015-11-18 14:23:38 +08:00
|
|
|
|
|
|
|
// Note: we're round tripping operand bundles through memory here, and that
|
|
|
|
// can potentially be avoided with a cleverer API design that we do not have
|
|
|
|
// as of this time.
|
|
|
|
|
|
|
|
InvokeInst *II =
|
|
|
|
InvokeInst::Create(CI->getCalledValue(), Split, UnwindEdge, InvokeArgs,
|
|
|
|
OpBundles, CI->getName(), BB);
|
2014-07-01 04:30:39 +08:00
|
|
|
II->setDebugLoc(CI->getDebugLoc());
|
2011-05-28 15:45:59 +08:00
|
|
|
II->setCallingConv(CI->getCallingConv());
|
|
|
|
II->setAttributes(CI->getAttributes());
|
2009-08-27 11:51:50 +08:00
|
|
|
|
2011-05-28 15:45:59 +08:00
|
|
|
// Make sure that anything using the call now uses the invoke! This also
|
|
|
|
// updates the CallGraph if present, because it uses a WeakVH.
|
|
|
|
CI->replaceAllUsesWith(II);
|
|
|
|
|
2012-01-31 09:01:16 +08:00
|
|
|
// Delete the original call
|
|
|
|
Split->getInstList().pop_front();
|
2015-08-01 01:58:14 +08:00
|
|
|
return BB;
|
2009-08-27 11:51:50 +08:00
|
|
|
}
|
2015-08-01 01:58:14 +08:00
|
|
|
return nullptr;
|
2009-08-27 11:51:50 +08:00
|
|
|
}
|
|
|
|
|
2015-03-11 03:42:57 +08:00
|
|
|
/// If we inlined an invoke site, we need to convert calls
|
2012-02-07 05:44:22 +08:00
|
|
|
/// in the body of the inlined function into invokes.
|
2006-01-14 03:05:59 +08:00
|
|
|
///
|
2009-02-03 12:34:40 +08:00
|
|
|
/// II is the invoke instruction being inlined. FirstNewBlock is the first
|
2006-01-14 03:05:59 +08:00
|
|
|
/// block of the inlined code (the last block is the end of the function),
|
|
|
|
/// and InlineCodeInfo is information about the code that got inlined.
|
2015-08-01 01:58:14 +08:00
|
|
|
static void HandleInlinedLandingPad(InvokeInst *II, BasicBlock *FirstNewBlock,
|
|
|
|
ClonedCodeInfo &InlinedCodeInfo) {
|
2006-01-14 03:05:59 +08:00
|
|
|
BasicBlock *InvokeDest = II->getUnwindDest();
|
|
|
|
|
|
|
|
Function *Caller = FirstNewBlock->getParent();
|
2008-09-05 20:37:12 +08:00
|
|
|
|
2006-01-14 03:05:59 +08:00
|
|
|
// The inlined code is currently at the end of the function, scan from the
|
|
|
|
// start of the inlined code to its end, checking for stuff we need to
|
2013-03-22 07:30:12 +08:00
|
|
|
// rewrite.
|
2015-08-01 01:58:14 +08:00
|
|
|
LandingPadInliningInfo Invoke(II);
|
2013-03-22 07:30:12 +08:00
|
|
|
|
2013-03-23 04:31:05 +08:00
|
|
|
// Get all of the inlined landing pad instructions.
|
|
|
|
SmallPtrSet<LandingPadInst*, 16> InlinedLPads;
|
2015-10-13 10:39:05 +08:00
|
|
|
for (Function::iterator I = FirstNewBlock->getIterator(), E = Caller->end();
|
|
|
|
I != E; ++I)
|
2013-03-23 04:31:05 +08:00
|
|
|
if (InvokeInst *II = dyn_cast<InvokeInst>(I->getTerminator()))
|
|
|
|
InlinedLPads.insert(II->getLandingPadInst());
|
|
|
|
|
2013-12-08 08:50:58 +08:00
|
|
|
// Append the clauses from the outer landing pad instruction into the inlined
|
|
|
|
// landing pad instructions.
|
|
|
|
LandingPadInst *OuterLPad = Invoke.getLandingPadInst();
|
2014-08-25 07:23:06 +08:00
|
|
|
for (LandingPadInst *InlinedLPad : InlinedLPads) {
|
2013-12-08 08:50:58 +08:00
|
|
|
unsigned OuterNum = OuterLPad->getNumClauses();
|
|
|
|
InlinedLPad->reserveClauses(OuterNum);
|
|
|
|
for (unsigned OuterIdx = 0; OuterIdx != OuterNum; ++OuterIdx)
|
|
|
|
InlinedLPad->addClause(OuterLPad->getClause(OuterIdx));
|
2013-12-08 08:51:21 +08:00
|
|
|
if (OuterLPad->isCleanup())
|
|
|
|
InlinedLPad->setCleanup(true);
|
2013-12-08 08:50:58 +08:00
|
|
|
}
|
|
|
|
|
2015-10-13 10:39:05 +08:00
|
|
|
for (Function::iterator BB = FirstNewBlock->getIterator(), E = Caller->end();
|
|
|
|
BB != E; ++BB) {
|
2009-08-27 11:51:50 +08:00
|
|
|
if (InlinedCodeInfo.ContainsCalls)
|
2015-08-01 01:58:14 +08:00
|
|
|
if (BasicBlock *NewBB = HandleCallsInBlockInlinedThroughInvoke(
|
2015-10-13 10:39:05 +08:00
|
|
|
&*BB, Invoke.getOuterResumeDest()))
|
2015-08-01 01:58:14 +08:00
|
|
|
// Update any PHI nodes in the exceptional block to indicate that there
|
|
|
|
// is now a new entry in them.
|
|
|
|
Invoke.addIncomingPHIValuesFor(NewBB);
|
2009-08-27 11:51:50 +08:00
|
|
|
|
2013-03-22 07:30:12 +08:00
|
|
|
// Forward any resumes that are remaining here.
|
2012-01-31 09:14:49 +08:00
|
|
|
if (ResumeInst *RI = dyn_cast<ResumeInst>(BB->getTerminator()))
|
2013-03-23 04:31:05 +08:00
|
|
|
Invoke.forwardResume(RI, InlinedLPads);
|
2006-01-14 03:05:59 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Now that everything is happy, we have one final detail. The PHI nodes in
|
|
|
|
// the exception destination block still have entries due to the original
|
2013-03-22 07:30:12 +08:00
|
|
|
// invoke instruction. Eliminate these entries (which might even delete the
|
2006-01-14 03:05:59 +08:00
|
|
|
// PHI node) now.
|
|
|
|
InvokeDest->removePredecessor(II->getParent());
|
|
|
|
}
|
|
|
|
|
2015-08-01 01:58:14 +08:00
|
|
|
/// If we inlined an invoke site, we need to convert calls
|
|
|
|
/// in the body of the inlined function into invokes.
|
|
|
|
///
|
|
|
|
/// II is the invoke instruction being inlined. FirstNewBlock is the first
|
|
|
|
/// block of the inlined code (the last block is the end of the function),
|
|
|
|
/// and InlineCodeInfo is information about the code that got inlined.
|
|
|
|
static void HandleInlinedEHPad(InvokeInst *II, BasicBlock *FirstNewBlock,
|
|
|
|
ClonedCodeInfo &InlinedCodeInfo) {
|
|
|
|
BasicBlock *UnwindDest = II->getUnwindDest();
|
|
|
|
Function *Caller = FirstNewBlock->getParent();
|
|
|
|
|
|
|
|
assert(UnwindDest->getFirstNonPHI()->isEHPad() && "unexpected BasicBlock!");
|
|
|
|
|
|
|
|
// If there are PHI nodes in the unwind destination block, we need to keep
|
|
|
|
// track of which values came into them from the invoke before removing the
|
|
|
|
// edge from this block.
|
|
|
|
SmallVector<Value *, 8> UnwindDestPHIValues;
|
|
|
|
llvm::BasicBlock *InvokeBB = II->getParent();
|
|
|
|
for (Instruction &I : *UnwindDest) {
|
|
|
|
// Save the value to use for this edge.
|
|
|
|
PHINode *PHI = dyn_cast<PHINode>(&I);
|
|
|
|
if (!PHI)
|
|
|
|
break;
|
|
|
|
UnwindDestPHIValues.push_back(PHI->getIncomingValueForBlock(InvokeBB));
|
|
|
|
}
|
|
|
|
|
|
|
|
// Add incoming-PHI values to the unwind destination block for the given basic
|
|
|
|
// block, using the values for the original invoke's source block.
|
|
|
|
auto UpdatePHINodes = [&](BasicBlock *Src) {
|
|
|
|
BasicBlock::iterator I = UnwindDest->begin();
|
|
|
|
for (Value *V : UnwindDestPHIValues) {
|
|
|
|
PHINode *PHI = cast<PHINode>(I);
|
|
|
|
PHI->addIncoming(V, Src);
|
|
|
|
++I;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
[IR] Reformulate LLVM's EH funclet IR
While we have successfully implemented a funclet-oriented EH scheme on
top of LLVM IR, our scheme has some notable deficiencies:
- catchendpad and cleanupendpad are necessary in the current design
but they are difficult to explain to others, even to seasoned LLVM
experts.
- catchendpad and cleanupendpad are optimization barriers. They cannot
be split and force all potentially throwing call-sites to be invokes.
This has a noticable effect on the quality of our code generation.
- catchpad, while similar in some aspects to invoke, is fairly awkward.
It is unsplittable, starts a funclet, and has control flow to other
funclets.
- The nesting relationship between funclets is currently a property of
control flow edges. Because of this, we are forced to carefully
analyze the flow graph to see if there might potentially exist illegal
nesting among funclets. While we have logic to clone funclets when
they are illegally nested, it would be nicer if we had a
representation which forbade them upfront.
Let's clean this up a bit by doing the following:
- Instead, make catchpad more like cleanuppad and landingpad: no control
flow, just a bunch of simple operands; catchpad would be splittable.
- Introduce catchswitch, a control flow instruction designed to model
the constraints of funclet oriented EH.
- Make funclet scoping explicit by having funclet instructions consume
the token produced by the funclet which contains them.
- Remove catchendpad and cleanupendpad. Their presence can be inferred
implicitly using coloring information.
N.B. The state numbering code for the CLR has been updated but the
veracity of it's output cannot be spoken for. An expert should take a
look to make sure the results are reasonable.
Reviewers: rnk, JosephTremoulet, andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D15139
llvm-svn: 255422
2015-12-12 13:38:55 +08:00
|
|
|
// This connects all the instructions which 'unwind to caller' to the invoke
|
|
|
|
// destination.
|
2015-10-13 10:39:05 +08:00
|
|
|
for (Function::iterator BB = FirstNewBlock->getIterator(), E = Caller->end();
|
|
|
|
BB != E; ++BB) {
|
2015-08-01 01:58:14 +08:00
|
|
|
if (auto *CRI = dyn_cast<CleanupReturnInst>(BB->getTerminator())) {
|
|
|
|
if (CRI->unwindsToCaller()) {
|
2015-08-23 08:26:33 +08:00
|
|
|
CleanupReturnInst::Create(CRI->getCleanupPad(), UnwindDest, CRI);
|
2015-08-01 01:58:14 +08:00
|
|
|
CRI->eraseFromParent();
|
2015-10-13 10:39:05 +08:00
|
|
|
UpdatePHINodes(&*BB);
|
2015-08-01 01:58:14 +08:00
|
|
|
}
|
|
|
|
}
|
[IR] Reformulate LLVM's EH funclet IR
While we have successfully implemented a funclet-oriented EH scheme on
top of LLVM IR, our scheme has some notable deficiencies:
- catchendpad and cleanupendpad are necessary in the current design
but they are difficult to explain to others, even to seasoned LLVM
experts.
- catchendpad and cleanupendpad are optimization barriers. They cannot
be split and force all potentially throwing call-sites to be invokes.
This has a noticable effect on the quality of our code generation.
- catchpad, while similar in some aspects to invoke, is fairly awkward.
It is unsplittable, starts a funclet, and has control flow to other
funclets.
- The nesting relationship between funclets is currently a property of
control flow edges. Because of this, we are forced to carefully
analyze the flow graph to see if there might potentially exist illegal
nesting among funclets. While we have logic to clone funclets when
they are illegally nested, it would be nicer if we had a
representation which forbade them upfront.
Let's clean this up a bit by doing the following:
- Instead, make catchpad more like cleanuppad and landingpad: no control
flow, just a bunch of simple operands; catchpad would be splittable.
- Introduce catchswitch, a control flow instruction designed to model
the constraints of funclet oriented EH.
- Make funclet scoping explicit by having funclet instructions consume
the token produced by the funclet which contains them.
- Remove catchendpad and cleanupendpad. Their presence can be inferred
implicitly using coloring information.
N.B. The state numbering code for the CLR has been updated but the
veracity of it's output cannot be spoken for. An expert should take a
look to make sure the results are reasonable.
Reviewers: rnk, JosephTremoulet, andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D15139
llvm-svn: 255422
2015-12-12 13:38:55 +08:00
|
|
|
|
|
|
|
Instruction *I = BB->getFirstNonPHI();
|
|
|
|
if (!I->isEHPad())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
Instruction *Replacement = nullptr;
|
|
|
|
if (auto *TPI = dyn_cast<TerminatePadInst>(I)) {
|
|
|
|
if (TPI->unwindsToCaller()) {
|
|
|
|
SmallVector<Value *, 3> TerminatePadArgs;
|
|
|
|
for (Value *ArgOperand : TPI->arg_operands())
|
|
|
|
TerminatePadArgs.push_back(ArgOperand);
|
|
|
|
Replacement = TerminatePadInst::Create(TPI->getParentPad(), UnwindDest,
|
|
|
|
TerminatePadArgs, TPI);
|
|
|
|
}
|
|
|
|
} else if (auto *CatchSwitch = dyn_cast<CatchSwitchInst>(I)) {
|
|
|
|
if (CatchSwitch->unwindsToCaller()) {
|
|
|
|
auto *NewCatchSwitch = CatchSwitchInst::Create(
|
|
|
|
CatchSwitch->getParentPad(), UnwindDest,
|
|
|
|
CatchSwitch->getNumHandlers(), CatchSwitch->getName(),
|
|
|
|
CatchSwitch);
|
|
|
|
for (BasicBlock *PadBB : CatchSwitch->handlers())
|
|
|
|
NewCatchSwitch->addHandler(PadBB);
|
|
|
|
Replacement = NewCatchSwitch;
|
|
|
|
}
|
|
|
|
} else if (!isa<FuncletPadInst>(I)) {
|
|
|
|
llvm_unreachable("unexpected EHPad!");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Replacement) {
|
|
|
|
Replacement->takeName(I);
|
|
|
|
I->replaceAllUsesWith(Replacement);
|
|
|
|
I->eraseFromParent();
|
|
|
|
UpdatePHINodes(&*BB);
|
|
|
|
}
|
2015-08-01 01:58:14 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (InlinedCodeInfo.ContainsCalls)
|
2015-10-13 10:39:05 +08:00
|
|
|
for (Function::iterator BB = FirstNewBlock->getIterator(),
|
|
|
|
E = Caller->end();
|
|
|
|
BB != E; ++BB)
|
2015-08-01 01:58:14 +08:00
|
|
|
if (BasicBlock *NewBB =
|
2015-10-13 10:39:05 +08:00
|
|
|
HandleCallsInBlockInlinedThroughInvoke(&*BB, UnwindDest))
|
2015-08-01 01:58:14 +08:00
|
|
|
// Update any PHI nodes in the exceptional block to indicate that there
|
|
|
|
// is now a new entry in them.
|
|
|
|
UpdatePHINodes(NewBB);
|
|
|
|
|
|
|
|
// Now that everything is happy, we have one final detail. The PHI nodes in
|
|
|
|
// the exception destination block still have entries due to the original
|
|
|
|
// invoke instruction. Eliminate these entries (which might even delete the
|
|
|
|
// PHI node) now.
|
|
|
|
UnwindDest->removePredecessor(InvokeBB);
|
|
|
|
}
|
|
|
|
|
2015-03-11 03:42:57 +08:00
|
|
|
/// When inlining a function that contains noalias scope metadata,
|
|
|
|
/// this metadata needs to be cloned so that the inlined blocks
|
Add scoped-noalias metadata
This commit adds scoped noalias metadata. The primary motivations for this
feature are:
1. To preserve noalias function attribute information when inlining
2. To provide the ability to model block-scope C99 restrict pointers
Neither of these two abilities are added here, only the necessary
infrastructure. In fact, there should be no change to existing functionality,
only the addition of new features. The logic that converts noalias function
parameters into this metadata during inlining will come in a follow-up commit.
What is added here is the ability to generally specify noalias memory-access
sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA
nodes:
!scope0 = metadata !{ metadata !"scope of foo()" }
!scope1 = metadata !{ metadata !"scope 1", metadata !scope0 }
!scope2 = metadata !{ metadata !"scope 2", metadata !scope0 }
!scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 }
!scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 }
Loads and stores can be tagged with an alias-analysis scope, and also, with a
noalias tag for a specific scope:
... = load %ptr1, !alias.scope !{ !scope1 }
... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 }
When evaluating an aliasing query, if one of the instructions is associated
with an alias.scope id that is identical to the noalias scope associated with
the other instruction, or is a descendant (in the scope hierarchy) of the
noalias scope associated with the other instruction, then the two memory
accesses are assumed not to alias.
Note that is the first element of the scope metadata is a string, then it can
be combined accross functions and translation units. The string can be replaced
by a self-reference to create globally unqiue scope identifiers.
[Note: This overview is slightly stylized, since the metadata nodes really need
to just be numbers (!0 instead of !scope0), and the scope lists are also global
unnamed metadata.]
Existing noalias metadata in a callee is "cloned" for use by the inlined code.
This is necessary because the aliasing scopes are unique to each call site
(because of possible control dependencies on the aliasing properties). For
example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets
inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } --
now just because we know that a1 does not alias with b1 at the first call site,
and a2 does not alias with b2 at the second call site, we cannot let inlining
these functons have the metadata imply that a1 does not alias with b2.
llvm-svn: 213864
2014-07-24 22:25:39 +08:00
|
|
|
/// have different "unqiue scopes" at every call site. Were this not done, then
|
|
|
|
/// aliasing scopes from a function inlined into a caller multiple times could
|
|
|
|
/// not be differentiated (and this would lead to miscompiles because the
|
|
|
|
/// non-aliasing property communicated by the metadata could have
|
|
|
|
/// call-site-specific control dependencies).
|
|
|
|
static void CloneAliasScopeMetadata(CallSite CS, ValueToValueMapTy &VMap) {
|
|
|
|
const Function *CalledFunc = CS.getCalledFunction();
|
|
|
|
SetVector<const MDNode *> MD;
|
|
|
|
|
|
|
|
// Note: We could only clone the metadata if it is already used in the
|
|
|
|
// caller. I'm omitting that check here because it might confuse
|
|
|
|
// inter-procedural alias analysis passes. We can revisit this if it becomes
|
|
|
|
// an efficiency or overhead problem.
|
|
|
|
|
|
|
|
for (Function::const_iterator I = CalledFunc->begin(), IE = CalledFunc->end();
|
|
|
|
I != IE; ++I)
|
|
|
|
for (BasicBlock::const_iterator J = I->begin(), JE = I->end(); J != JE; ++J) {
|
2014-11-12 05:30:22 +08:00
|
|
|
if (const MDNode *M = J->getMetadata(LLVMContext::MD_alias_scope))
|
Add scoped-noalias metadata
This commit adds scoped noalias metadata. The primary motivations for this
feature are:
1. To preserve noalias function attribute information when inlining
2. To provide the ability to model block-scope C99 restrict pointers
Neither of these two abilities are added here, only the necessary
infrastructure. In fact, there should be no change to existing functionality,
only the addition of new features. The logic that converts noalias function
parameters into this metadata during inlining will come in a follow-up commit.
What is added here is the ability to generally specify noalias memory-access
sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA
nodes:
!scope0 = metadata !{ metadata !"scope of foo()" }
!scope1 = metadata !{ metadata !"scope 1", metadata !scope0 }
!scope2 = metadata !{ metadata !"scope 2", metadata !scope0 }
!scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 }
!scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 }
Loads and stores can be tagged with an alias-analysis scope, and also, with a
noalias tag for a specific scope:
... = load %ptr1, !alias.scope !{ !scope1 }
... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 }
When evaluating an aliasing query, if one of the instructions is associated
with an alias.scope id that is identical to the noalias scope associated with
the other instruction, or is a descendant (in the scope hierarchy) of the
noalias scope associated with the other instruction, then the two memory
accesses are assumed not to alias.
Note that is the first element of the scope metadata is a string, then it can
be combined accross functions and translation units. The string can be replaced
by a self-reference to create globally unqiue scope identifiers.
[Note: This overview is slightly stylized, since the metadata nodes really need
to just be numbers (!0 instead of !scope0), and the scope lists are also global
unnamed metadata.]
Existing noalias metadata in a callee is "cloned" for use by the inlined code.
This is necessary because the aliasing scopes are unique to each call site
(because of possible control dependencies on the aliasing properties). For
example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets
inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } --
now just because we know that a1 does not alias with b1 at the first call site,
and a2 does not alias with b2 at the second call site, we cannot let inlining
these functons have the metadata imply that a1 does not alias with b2.
llvm-svn: 213864
2014-07-24 22:25:39 +08:00
|
|
|
MD.insert(M);
|
2014-11-12 05:30:22 +08:00
|
|
|
if (const MDNode *M = J->getMetadata(LLVMContext::MD_noalias))
|
Add scoped-noalias metadata
This commit adds scoped noalias metadata. The primary motivations for this
feature are:
1. To preserve noalias function attribute information when inlining
2. To provide the ability to model block-scope C99 restrict pointers
Neither of these two abilities are added here, only the necessary
infrastructure. In fact, there should be no change to existing functionality,
only the addition of new features. The logic that converts noalias function
parameters into this metadata during inlining will come in a follow-up commit.
What is added here is the ability to generally specify noalias memory-access
sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA
nodes:
!scope0 = metadata !{ metadata !"scope of foo()" }
!scope1 = metadata !{ metadata !"scope 1", metadata !scope0 }
!scope2 = metadata !{ metadata !"scope 2", metadata !scope0 }
!scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 }
!scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 }
Loads and stores can be tagged with an alias-analysis scope, and also, with a
noalias tag for a specific scope:
... = load %ptr1, !alias.scope !{ !scope1 }
... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 }
When evaluating an aliasing query, if one of the instructions is associated
with an alias.scope id that is identical to the noalias scope associated with
the other instruction, or is a descendant (in the scope hierarchy) of the
noalias scope associated with the other instruction, then the two memory
accesses are assumed not to alias.
Note that is the first element of the scope metadata is a string, then it can
be combined accross functions and translation units. The string can be replaced
by a self-reference to create globally unqiue scope identifiers.
[Note: This overview is slightly stylized, since the metadata nodes really need
to just be numbers (!0 instead of !scope0), and the scope lists are also global
unnamed metadata.]
Existing noalias metadata in a callee is "cloned" for use by the inlined code.
This is necessary because the aliasing scopes are unique to each call site
(because of possible control dependencies on the aliasing properties). For
example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets
inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } --
now just because we know that a1 does not alias with b1 at the first call site,
and a2 does not alias with b2 at the second call site, we cannot let inlining
these functons have the metadata imply that a1 does not alias with b2.
llvm-svn: 213864
2014-07-24 22:25:39 +08:00
|
|
|
MD.insert(M);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (MD.empty())
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Walk the existing metadata, adding the complete (perhaps cyclic) chain to
|
|
|
|
// the set.
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
SmallVector<const Metadata *, 16> Queue(MD.begin(), MD.end());
|
Add scoped-noalias metadata
This commit adds scoped noalias metadata. The primary motivations for this
feature are:
1. To preserve noalias function attribute information when inlining
2. To provide the ability to model block-scope C99 restrict pointers
Neither of these two abilities are added here, only the necessary
infrastructure. In fact, there should be no change to existing functionality,
only the addition of new features. The logic that converts noalias function
parameters into this metadata during inlining will come in a follow-up commit.
What is added here is the ability to generally specify noalias memory-access
sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA
nodes:
!scope0 = metadata !{ metadata !"scope of foo()" }
!scope1 = metadata !{ metadata !"scope 1", metadata !scope0 }
!scope2 = metadata !{ metadata !"scope 2", metadata !scope0 }
!scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 }
!scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 }
Loads and stores can be tagged with an alias-analysis scope, and also, with a
noalias tag for a specific scope:
... = load %ptr1, !alias.scope !{ !scope1 }
... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 }
When evaluating an aliasing query, if one of the instructions is associated
with an alias.scope id that is identical to the noalias scope associated with
the other instruction, or is a descendant (in the scope hierarchy) of the
noalias scope associated with the other instruction, then the two memory
accesses are assumed not to alias.
Note that is the first element of the scope metadata is a string, then it can
be combined accross functions and translation units. The string can be replaced
by a self-reference to create globally unqiue scope identifiers.
[Note: This overview is slightly stylized, since the metadata nodes really need
to just be numbers (!0 instead of !scope0), and the scope lists are also global
unnamed metadata.]
Existing noalias metadata in a callee is "cloned" for use by the inlined code.
This is necessary because the aliasing scopes are unique to each call site
(because of possible control dependencies on the aliasing properties). For
example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets
inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } --
now just because we know that a1 does not alias with b1 at the first call site,
and a2 does not alias with b2 at the second call site, we cannot let inlining
these functons have the metadata imply that a1 does not alias with b2.
llvm-svn: 213864
2014-07-24 22:25:39 +08:00
|
|
|
while (!Queue.empty()) {
|
|
|
|
const MDNode *M = cast<MDNode>(Queue.pop_back_val());
|
|
|
|
for (unsigned i = 0, ie = M->getNumOperands(); i != ie; ++i)
|
|
|
|
if (const MDNode *M1 = dyn_cast<MDNode>(M->getOperand(i)))
|
|
|
|
if (MD.insert(M1))
|
|
|
|
Queue.push_back(M1);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Now we have a complete set of all metadata in the chains used to specify
|
|
|
|
// the noalias scopes and the lists of those scopes.
|
2015-01-20 05:30:18 +08:00
|
|
|
SmallVector<TempMDTuple, 16> DummyNodes;
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
DenseMap<const MDNode *, TrackingMDNodeRef> MDMap;
|
Add scoped-noalias metadata
This commit adds scoped noalias metadata. The primary motivations for this
feature are:
1. To preserve noalias function attribute information when inlining
2. To provide the ability to model block-scope C99 restrict pointers
Neither of these two abilities are added here, only the necessary
infrastructure. In fact, there should be no change to existing functionality,
only the addition of new features. The logic that converts noalias function
parameters into this metadata during inlining will come in a follow-up commit.
What is added here is the ability to generally specify noalias memory-access
sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA
nodes:
!scope0 = metadata !{ metadata !"scope of foo()" }
!scope1 = metadata !{ metadata !"scope 1", metadata !scope0 }
!scope2 = metadata !{ metadata !"scope 2", metadata !scope0 }
!scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 }
!scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 }
Loads and stores can be tagged with an alias-analysis scope, and also, with a
noalias tag for a specific scope:
... = load %ptr1, !alias.scope !{ !scope1 }
... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 }
When evaluating an aliasing query, if one of the instructions is associated
with an alias.scope id that is identical to the noalias scope associated with
the other instruction, or is a descendant (in the scope hierarchy) of the
noalias scope associated with the other instruction, then the two memory
accesses are assumed not to alias.
Note that is the first element of the scope metadata is a string, then it can
be combined accross functions and translation units. The string can be replaced
by a self-reference to create globally unqiue scope identifiers.
[Note: This overview is slightly stylized, since the metadata nodes really need
to just be numbers (!0 instead of !scope0), and the scope lists are also global
unnamed metadata.]
Existing noalias metadata in a callee is "cloned" for use by the inlined code.
This is necessary because the aliasing scopes are unique to each call site
(because of possible control dependencies on the aliasing properties). For
example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets
inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } --
now just because we know that a1 does not alias with b1 at the first call site,
and a2 does not alias with b2 at the second call site, we cannot let inlining
these functons have the metadata imply that a1 does not alias with b2.
llvm-svn: 213864
2014-07-24 22:25:39 +08:00
|
|
|
for (SetVector<const MDNode *>::iterator I = MD.begin(), IE = MD.end();
|
|
|
|
I != IE; ++I) {
|
2015-01-20 05:30:18 +08:00
|
|
|
DummyNodes.push_back(MDTuple::getTemporary(CalledFunc->getContext(), None));
|
|
|
|
MDMap[*I].reset(DummyNodes.back().get());
|
Add scoped-noalias metadata
This commit adds scoped noalias metadata. The primary motivations for this
feature are:
1. To preserve noalias function attribute information when inlining
2. To provide the ability to model block-scope C99 restrict pointers
Neither of these two abilities are added here, only the necessary
infrastructure. In fact, there should be no change to existing functionality,
only the addition of new features. The logic that converts noalias function
parameters into this metadata during inlining will come in a follow-up commit.
What is added here is the ability to generally specify noalias memory-access
sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA
nodes:
!scope0 = metadata !{ metadata !"scope of foo()" }
!scope1 = metadata !{ metadata !"scope 1", metadata !scope0 }
!scope2 = metadata !{ metadata !"scope 2", metadata !scope0 }
!scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 }
!scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 }
Loads and stores can be tagged with an alias-analysis scope, and also, with a
noalias tag for a specific scope:
... = load %ptr1, !alias.scope !{ !scope1 }
... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 }
When evaluating an aliasing query, if one of the instructions is associated
with an alias.scope id that is identical to the noalias scope associated with
the other instruction, or is a descendant (in the scope hierarchy) of the
noalias scope associated with the other instruction, then the two memory
accesses are assumed not to alias.
Note that is the first element of the scope metadata is a string, then it can
be combined accross functions and translation units. The string can be replaced
by a self-reference to create globally unqiue scope identifiers.
[Note: This overview is slightly stylized, since the metadata nodes really need
to just be numbers (!0 instead of !scope0), and the scope lists are also global
unnamed metadata.]
Existing noalias metadata in a callee is "cloned" for use by the inlined code.
This is necessary because the aliasing scopes are unique to each call site
(because of possible control dependencies on the aliasing properties). For
example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets
inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } --
now just because we know that a1 does not alias with b1 at the first call site,
and a2 does not alias with b2 at the second call site, we cannot let inlining
these functons have the metadata imply that a1 does not alias with b2.
llvm-svn: 213864
2014-07-24 22:25:39 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Create new metadata nodes to replace the dummy nodes, replacing old
|
|
|
|
// metadata references with either a dummy node or an already-created new
|
|
|
|
// node.
|
|
|
|
for (SetVector<const MDNode *>::iterator I = MD.begin(), IE = MD.end();
|
|
|
|
I != IE; ++I) {
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
SmallVector<Metadata *, 4> NewOps;
|
Add scoped-noalias metadata
This commit adds scoped noalias metadata. The primary motivations for this
feature are:
1. To preserve noalias function attribute information when inlining
2. To provide the ability to model block-scope C99 restrict pointers
Neither of these two abilities are added here, only the necessary
infrastructure. In fact, there should be no change to existing functionality,
only the addition of new features. The logic that converts noalias function
parameters into this metadata during inlining will come in a follow-up commit.
What is added here is the ability to generally specify noalias memory-access
sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA
nodes:
!scope0 = metadata !{ metadata !"scope of foo()" }
!scope1 = metadata !{ metadata !"scope 1", metadata !scope0 }
!scope2 = metadata !{ metadata !"scope 2", metadata !scope0 }
!scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 }
!scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 }
Loads and stores can be tagged with an alias-analysis scope, and also, with a
noalias tag for a specific scope:
... = load %ptr1, !alias.scope !{ !scope1 }
... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 }
When evaluating an aliasing query, if one of the instructions is associated
with an alias.scope id that is identical to the noalias scope associated with
the other instruction, or is a descendant (in the scope hierarchy) of the
noalias scope associated with the other instruction, then the two memory
accesses are assumed not to alias.
Note that is the first element of the scope metadata is a string, then it can
be combined accross functions and translation units. The string can be replaced
by a self-reference to create globally unqiue scope identifiers.
[Note: This overview is slightly stylized, since the metadata nodes really need
to just be numbers (!0 instead of !scope0), and the scope lists are also global
unnamed metadata.]
Existing noalias metadata in a callee is "cloned" for use by the inlined code.
This is necessary because the aliasing scopes are unique to each call site
(because of possible control dependencies on the aliasing properties). For
example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets
inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } --
now just because we know that a1 does not alias with b1 at the first call site,
and a2 does not alias with b2 at the second call site, we cannot let inlining
these functons have the metadata imply that a1 does not alias with b2.
llvm-svn: 213864
2014-07-24 22:25:39 +08:00
|
|
|
for (unsigned i = 0, ie = (*I)->getNumOperands(); i != ie; ++i) {
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
const Metadata *V = (*I)->getOperand(i);
|
Add scoped-noalias metadata
This commit adds scoped noalias metadata. The primary motivations for this
feature are:
1. To preserve noalias function attribute information when inlining
2. To provide the ability to model block-scope C99 restrict pointers
Neither of these two abilities are added here, only the necessary
infrastructure. In fact, there should be no change to existing functionality,
only the addition of new features. The logic that converts noalias function
parameters into this metadata during inlining will come in a follow-up commit.
What is added here is the ability to generally specify noalias memory-access
sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA
nodes:
!scope0 = metadata !{ metadata !"scope of foo()" }
!scope1 = metadata !{ metadata !"scope 1", metadata !scope0 }
!scope2 = metadata !{ metadata !"scope 2", metadata !scope0 }
!scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 }
!scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 }
Loads and stores can be tagged with an alias-analysis scope, and also, with a
noalias tag for a specific scope:
... = load %ptr1, !alias.scope !{ !scope1 }
... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 }
When evaluating an aliasing query, if one of the instructions is associated
with an alias.scope id that is identical to the noalias scope associated with
the other instruction, or is a descendant (in the scope hierarchy) of the
noalias scope associated with the other instruction, then the two memory
accesses are assumed not to alias.
Note that is the first element of the scope metadata is a string, then it can
be combined accross functions and translation units. The string can be replaced
by a self-reference to create globally unqiue scope identifiers.
[Note: This overview is slightly stylized, since the metadata nodes really need
to just be numbers (!0 instead of !scope0), and the scope lists are also global
unnamed metadata.]
Existing noalias metadata in a callee is "cloned" for use by the inlined code.
This is necessary because the aliasing scopes are unique to each call site
(because of possible control dependencies on the aliasing properties). For
example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets
inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } --
now just because we know that a1 does not alias with b1 at the first call site,
and a2 does not alias with b2 at the second call site, we cannot let inlining
these functons have the metadata imply that a1 does not alias with b2.
llvm-svn: 213864
2014-07-24 22:25:39 +08:00
|
|
|
if (const MDNode *M = dyn_cast<MDNode>(V))
|
|
|
|
NewOps.push_back(MDMap[M]);
|
|
|
|
else
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
NewOps.push_back(const_cast<Metadata *>(V));
|
Add scoped-noalias metadata
This commit adds scoped noalias metadata. The primary motivations for this
feature are:
1. To preserve noalias function attribute information when inlining
2. To provide the ability to model block-scope C99 restrict pointers
Neither of these two abilities are added here, only the necessary
infrastructure. In fact, there should be no change to existing functionality,
only the addition of new features. The logic that converts noalias function
parameters into this metadata during inlining will come in a follow-up commit.
What is added here is the ability to generally specify noalias memory-access
sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA
nodes:
!scope0 = metadata !{ metadata !"scope of foo()" }
!scope1 = metadata !{ metadata !"scope 1", metadata !scope0 }
!scope2 = metadata !{ metadata !"scope 2", metadata !scope0 }
!scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 }
!scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 }
Loads and stores can be tagged with an alias-analysis scope, and also, with a
noalias tag for a specific scope:
... = load %ptr1, !alias.scope !{ !scope1 }
... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 }
When evaluating an aliasing query, if one of the instructions is associated
with an alias.scope id that is identical to the noalias scope associated with
the other instruction, or is a descendant (in the scope hierarchy) of the
noalias scope associated with the other instruction, then the two memory
accesses are assumed not to alias.
Note that is the first element of the scope metadata is a string, then it can
be combined accross functions and translation units. The string can be replaced
by a self-reference to create globally unqiue scope identifiers.
[Note: This overview is slightly stylized, since the metadata nodes really need
to just be numbers (!0 instead of !scope0), and the scope lists are also global
unnamed metadata.]
Existing noalias metadata in a callee is "cloned" for use by the inlined code.
This is necessary because the aliasing scopes are unique to each call site
(because of possible control dependencies on the aliasing properties). For
example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets
inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } --
now just because we know that a1 does not alias with b1 at the first call site,
and a2 does not alias with b2 at the second call site, we cannot let inlining
these functons have the metadata imply that a1 does not alias with b2.
llvm-svn: 213864
2014-07-24 22:25:39 +08:00
|
|
|
}
|
|
|
|
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
MDNode *NewM = MDNode::get(CalledFunc->getContext(), NewOps);
|
IR: Remove MDNodeFwdDecl
Remove `MDNodeFwdDecl` (as promised in r226481). Aside from API
changes, there's no real functionality change here.
`MDNode::getTemporary()` now forwards to `MDTuple::getTemporary()`,
which returns a tuple with `isTemporary()` equal to true.
The main point is that we can now add temporaries of other `MDNode`
subclasses, needed for PR22235 (I introduced `MDNodeFwdDecl` in the
first place because I didn't recognize this need, and thought they were
only needed to handle forward references).
A few things left out of (or highlighted by) this commit:
- I've had to remove the (few) uses of `std::unique_ptr<>` to deal
with temporaries, since the destructor is no longer public.
`getTemporary()` should probably return the equivalent of
`std::unique_ptr<T, MDNode::deleteTemporary>`.
- `MDLocation::getTemporary()` doesn't exist yet (worse, it actually
does exist, but does the wrong thing: `MDNode::getTemporary()` is
inherited and returns an `MDTuple`).
- `MDNode` now only has one subclass, `UniquableMDNode`, and the
distinction between them is actually somewhat confusing.
I'll fix those up next.
llvm-svn: 226501
2015-01-20 04:36:39 +08:00
|
|
|
MDTuple *TempM = cast<MDTuple>(MDMap[*I]);
|
|
|
|
assert(TempM->isTemporary() && "Expected temporary node");
|
Add scoped-noalias metadata
This commit adds scoped noalias metadata. The primary motivations for this
feature are:
1. To preserve noalias function attribute information when inlining
2. To provide the ability to model block-scope C99 restrict pointers
Neither of these two abilities are added here, only the necessary
infrastructure. In fact, there should be no change to existing functionality,
only the addition of new features. The logic that converts noalias function
parameters into this metadata during inlining will come in a follow-up commit.
What is added here is the ability to generally specify noalias memory-access
sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA
nodes:
!scope0 = metadata !{ metadata !"scope of foo()" }
!scope1 = metadata !{ metadata !"scope 1", metadata !scope0 }
!scope2 = metadata !{ metadata !"scope 2", metadata !scope0 }
!scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 }
!scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 }
Loads and stores can be tagged with an alias-analysis scope, and also, with a
noalias tag for a specific scope:
... = load %ptr1, !alias.scope !{ !scope1 }
... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 }
When evaluating an aliasing query, if one of the instructions is associated
with an alias.scope id that is identical to the noalias scope associated with
the other instruction, or is a descendant (in the scope hierarchy) of the
noalias scope associated with the other instruction, then the two memory
accesses are assumed not to alias.
Note that is the first element of the scope metadata is a string, then it can
be combined accross functions and translation units. The string can be replaced
by a self-reference to create globally unqiue scope identifiers.
[Note: This overview is slightly stylized, since the metadata nodes really need
to just be numbers (!0 instead of !scope0), and the scope lists are also global
unnamed metadata.]
Existing noalias metadata in a callee is "cloned" for use by the inlined code.
This is necessary because the aliasing scopes are unique to each call site
(because of possible control dependencies on the aliasing properties). For
example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets
inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } --
now just because we know that a1 does not alias with b1 at the first call site,
and a2 does not alias with b2 at the second call site, we cannot let inlining
these functons have the metadata imply that a1 does not alias with b2.
llvm-svn: 213864
2014-07-24 22:25:39 +08:00
|
|
|
|
|
|
|
TempM->replaceAllUsesWith(NewM);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Now replace the metadata in the new inlined instructions with the
|
|
|
|
// repacements from the map.
|
|
|
|
for (ValueToValueMapTy::iterator VMI = VMap.begin(), VMIE = VMap.end();
|
|
|
|
VMI != VMIE; ++VMI) {
|
|
|
|
if (!VMI->second)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
Instruction *NI = dyn_cast<Instruction>(VMI->second);
|
|
|
|
if (!NI)
|
|
|
|
continue;
|
|
|
|
|
2014-11-12 05:30:22 +08:00
|
|
|
if (MDNode *M = NI->getMetadata(LLVMContext::MD_alias_scope)) {
|
2014-08-15 05:09:37 +08:00
|
|
|
MDNode *NewMD = MDMap[M];
|
|
|
|
// If the call site also had alias scope metadata (a list of scopes to
|
|
|
|
// which instructions inside it might belong), propagate those scopes to
|
|
|
|
// the inlined instructions.
|
|
|
|
if (MDNode *CSM =
|
2014-11-12 05:30:22 +08:00
|
|
|
CS.getInstruction()->getMetadata(LLVMContext::MD_alias_scope))
|
2014-08-15 05:09:37 +08:00
|
|
|
NewMD = MDNode::concatenate(NewMD, CSM);
|
|
|
|
NI->setMetadata(LLVMContext::MD_alias_scope, NewMD);
|
|
|
|
} else if (NI->mayReadOrWriteMemory()) {
|
|
|
|
if (MDNode *M =
|
2014-11-12 05:30:22 +08:00
|
|
|
CS.getInstruction()->getMetadata(LLVMContext::MD_alias_scope))
|
2014-08-15 05:09:37 +08:00
|
|
|
NI->setMetadata(LLVMContext::MD_alias_scope, M);
|
|
|
|
}
|
Add scoped-noalias metadata
This commit adds scoped noalias metadata. The primary motivations for this
feature are:
1. To preserve noalias function attribute information when inlining
2. To provide the ability to model block-scope C99 restrict pointers
Neither of these two abilities are added here, only the necessary
infrastructure. In fact, there should be no change to existing functionality,
only the addition of new features. The logic that converts noalias function
parameters into this metadata during inlining will come in a follow-up commit.
What is added here is the ability to generally specify noalias memory-access
sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA
nodes:
!scope0 = metadata !{ metadata !"scope of foo()" }
!scope1 = metadata !{ metadata !"scope 1", metadata !scope0 }
!scope2 = metadata !{ metadata !"scope 2", metadata !scope0 }
!scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 }
!scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 }
Loads and stores can be tagged with an alias-analysis scope, and also, with a
noalias tag for a specific scope:
... = load %ptr1, !alias.scope !{ !scope1 }
... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 }
When evaluating an aliasing query, if one of the instructions is associated
with an alias.scope id that is identical to the noalias scope associated with
the other instruction, or is a descendant (in the scope hierarchy) of the
noalias scope associated with the other instruction, then the two memory
accesses are assumed not to alias.
Note that is the first element of the scope metadata is a string, then it can
be combined accross functions and translation units. The string can be replaced
by a self-reference to create globally unqiue scope identifiers.
[Note: This overview is slightly stylized, since the metadata nodes really need
to just be numbers (!0 instead of !scope0), and the scope lists are also global
unnamed metadata.]
Existing noalias metadata in a callee is "cloned" for use by the inlined code.
This is necessary because the aliasing scopes are unique to each call site
(because of possible control dependencies on the aliasing properties). For
example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets
inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } --
now just because we know that a1 does not alias with b1 at the first call site,
and a2 does not alias with b2 at the second call site, we cannot let inlining
these functons have the metadata imply that a1 does not alias with b2.
llvm-svn: 213864
2014-07-24 22:25:39 +08:00
|
|
|
|
2014-11-12 05:30:22 +08:00
|
|
|
if (MDNode *M = NI->getMetadata(LLVMContext::MD_noalias)) {
|
2014-08-15 05:09:37 +08:00
|
|
|
MDNode *NewMD = MDMap[M];
|
|
|
|
// If the call site also had noalias metadata (a list of scopes with
|
|
|
|
// which instructions inside it don't alias), propagate those scopes to
|
|
|
|
// the inlined instructions.
|
2014-11-12 05:30:22 +08:00
|
|
|
if (MDNode *CSM =
|
|
|
|
CS.getInstruction()->getMetadata(LLVMContext::MD_noalias))
|
2014-08-15 05:09:37 +08:00
|
|
|
NewMD = MDNode::concatenate(NewMD, CSM);
|
|
|
|
NI->setMetadata(LLVMContext::MD_noalias, NewMD);
|
|
|
|
} else if (NI->mayReadOrWriteMemory()) {
|
2014-11-12 05:30:22 +08:00
|
|
|
if (MDNode *M = CS.getInstruction()->getMetadata(LLVMContext::MD_noalias))
|
2014-08-15 05:09:37 +08:00
|
|
|
NI->setMetadata(LLVMContext::MD_noalias, M);
|
|
|
|
}
|
Add scoped-noalias metadata
This commit adds scoped noalias metadata. The primary motivations for this
feature are:
1. To preserve noalias function attribute information when inlining
2. To provide the ability to model block-scope C99 restrict pointers
Neither of these two abilities are added here, only the necessary
infrastructure. In fact, there should be no change to existing functionality,
only the addition of new features. The logic that converts noalias function
parameters into this metadata during inlining will come in a follow-up commit.
What is added here is the ability to generally specify noalias memory-access
sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA
nodes:
!scope0 = metadata !{ metadata !"scope of foo()" }
!scope1 = metadata !{ metadata !"scope 1", metadata !scope0 }
!scope2 = metadata !{ metadata !"scope 2", metadata !scope0 }
!scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 }
!scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 }
Loads and stores can be tagged with an alias-analysis scope, and also, with a
noalias tag for a specific scope:
... = load %ptr1, !alias.scope !{ !scope1 }
... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 }
When evaluating an aliasing query, if one of the instructions is associated
with an alias.scope id that is identical to the noalias scope associated with
the other instruction, or is a descendant (in the scope hierarchy) of the
noalias scope associated with the other instruction, then the two memory
accesses are assumed not to alias.
Note that is the first element of the scope metadata is a string, then it can
be combined accross functions and translation units. The string can be replaced
by a self-reference to create globally unqiue scope identifiers.
[Note: This overview is slightly stylized, since the metadata nodes really need
to just be numbers (!0 instead of !scope0), and the scope lists are also global
unnamed metadata.]
Existing noalias metadata in a callee is "cloned" for use by the inlined code.
This is necessary because the aliasing scopes are unique to each call site
(because of possible control dependencies on the aliasing properties). For
example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets
inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } --
now just because we know that a1 does not alias with b1 at the first call site,
and a2 does not alias with b2 at the second call site, we cannot let inlining
these functons have the metadata imply that a1 does not alias with b2.
llvm-svn: 213864
2014-07-24 22:25:39 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-03-11 03:42:57 +08:00
|
|
|
/// If the inlined function has noalias arguments,
|
|
|
|
/// then add new alias scopes for each noalias argument, tag the mapped noalias
|
2014-07-25 23:50:08 +08:00
|
|
|
/// parameters with noalias metadata specifying the new scope, and tag all
|
|
|
|
/// non-derived loads, stores and memory intrinsics with the new alias scopes.
|
|
|
|
static void AddAliasScopeMetadata(CallSite CS, ValueToValueMapTy &VMap,
|
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
with the new pass manager, and no longer relying on analysis groups.
This builds essentially a ground-up new AA infrastructure stack for
LLVM. The core ideas are the same that are used throughout the new pass
manager: type erased polymorphism and direct composition. The design is
as follows:
- FunctionAAResults is a type-erasing alias analysis results aggregation
interface to walk a single query across a range of results from
different alias analyses. Currently this is function-specific as we
always assume that aliasing queries are *within* a function.
- AAResultBase is a CRTP utility providing stub implementations of
various parts of the alias analysis result concept, notably in several
cases in terms of other more general parts of the interface. This can
be used to implement only a narrow part of the interface rather than
the entire interface. This isn't really ideal, this logic should be
hoisted into FunctionAAResults as currently it will cause
a significant amount of redundant work, but it faithfully models the
behavior of the prior infrastructure.
- All the alias analysis passes are ported to be wrapper passes for the
legacy PM and new-style analysis passes for the new PM with a shared
result object. In some cases (most notably CFL), this is an extremely
naive approach that we should revisit when we can specialize for the
new pass manager.
- BasicAA has been restructured to reflect that it is much more
fundamentally a function analysis because it uses dominator trees and
loop info that need to be constructed for each function.
All of the references to getting alias analysis results have been
updated to use the new aggregation interface. All the preservation and
other pass management code has been updated accordingly.
The way the FunctionAAResultsWrapperPass works is to detect the
available alias analyses when run, and add them to the results object.
This means that we should be able to continue to respect when various
passes are added to the pipeline, for example adding CFL or adding TBAA
passes should just cause their results to be available and to get folded
into this. The exception to this rule is BasicAA which really needs to
be a function pass due to using dominator trees and loop info. As
a consequence, the FunctionAAResultsWrapperPass directly depends on
BasicAA and always includes it in the aggregation.
This has significant implications for preserving analyses. Generally,
most passes shouldn't bother preserving FunctionAAResultsWrapperPass
because rebuilding the results just updates the set of known AA passes.
The exception to this rule are LoopPass instances which need to preserve
all the function analyses that the loop pass manager will end up
needing. This means preserving both BasicAAWrapperPass and the
aggregating FunctionAAResultsWrapperPass.
Now, when preserving an alias analysis, you do so by directly preserving
that analysis. This is only necessary for non-immutable-pass-provided
alias analyses though, and there are only three of interest: BasicAA,
GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
preserved when needed because it (like DominatorTree and LoopInfo) is
marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
set everywhere we previously were preserving all of AliasAnalysis, and
I've added SCEVAA in the intersection of that with where we preserve
SCEV itself.
One significant challenge to all of this is that the CGSCC passes were
actually using the alias analysis implementations by taking advantage of
a pretty amazing set of loop holes in the old pass manager's analysis
management code which allowed analysis groups to slide through in many
cases. Moving away from analysis groups makes this problem much more
obvious. To fix it, I've leveraged the flexibility the design of the new
PM components provides to just directly construct the relevant alias
analyses for the relevant functions in the IPO passes that need them.
This is a bit hacky, but should go away with the new pass manager, and
is already in many ways cleaner than the prior state.
Another significant challenge is that various facilities of the old
alias analysis infrastructure just don't fit any more. The most
significant of these is the alias analysis 'counter' pass. That pass
relied on the ability to snoop on AA queries at different points in the
analysis group chain. Instead, I'm planning to build printing
functionality directly into the aggregation layer. I've not included
that in this patch merely to keep it smaller.
Note that all of this needs a nearly complete rewrite of the AA
documentation. I'm planning to do that, but I'd like to make sure the
new design settles, and to flesh out a bit more of what it looks like in
the new pass manager first.
Differential Revision: http://reviews.llvm.org/D12080
llvm-svn: 247167
2015-09-10 01:55:00 +08:00
|
|
|
const DataLayout &DL, AAResults *CalleeAAR) {
|
2014-07-25 23:50:08 +08:00
|
|
|
if (!EnableNoAliasConversion)
|
|
|
|
return;
|
|
|
|
|
|
|
|
const Function *CalledFunc = CS.getCalledFunction();
|
|
|
|
SmallVector<const Argument *, 4> NoAliasArgs;
|
|
|
|
|
2015-10-13 10:39:05 +08:00
|
|
|
for (const Argument &I : CalledFunc->args()) {
|
|
|
|
if (I.hasNoAliasAttr() && !I.hasNUses(0))
|
|
|
|
NoAliasArgs.push_back(&I);
|
2014-07-25 23:50:08 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (NoAliasArgs.empty())
|
|
|
|
return;
|
|
|
|
|
|
|
|
// To do a good job, if a noalias variable is captured, we need to know if
|
|
|
|
// the capture point dominates the particular use we're considering.
|
|
|
|
DominatorTree DT;
|
|
|
|
DT.recalculate(const_cast<Function&>(*CalledFunc));
|
|
|
|
|
|
|
|
// noalias indicates that pointer values based on the argument do not alias
|
|
|
|
// pointer values which are not based on it. So we add a new "scope" for each
|
|
|
|
// noalias function argument. Accesses using pointers based on that argument
|
|
|
|
// become part of that alias scope, accesses using pointers not based on that
|
|
|
|
// argument are tagged as noalias with that scope.
|
|
|
|
|
|
|
|
DenseMap<const Argument *, MDNode *> NewScopes;
|
|
|
|
MDBuilder MDB(CalledFunc->getContext());
|
|
|
|
|
|
|
|
// Create a new scope domain for this function.
|
|
|
|
MDNode *NewDomain =
|
|
|
|
MDB.createAnonymousAliasScopeDomain(CalledFunc->getName());
|
|
|
|
for (unsigned i = 0, e = NoAliasArgs.size(); i != e; ++i) {
|
|
|
|
const Argument *A = NoAliasArgs[i];
|
|
|
|
|
|
|
|
std::string Name = CalledFunc->getName();
|
|
|
|
if (A->hasName()) {
|
|
|
|
Name += ": %";
|
|
|
|
Name += A->getName();
|
|
|
|
} else {
|
|
|
|
Name += ": argument ";
|
|
|
|
Name += utostr(i);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Note: We always create a new anonymous root here. This is true regardless
|
|
|
|
// of the linkage of the callee because the aliasing "scope" is not just a
|
|
|
|
// property of the callee, but also all control dependencies in the caller.
|
|
|
|
MDNode *NewScope = MDB.createAnonymousAliasScope(NewDomain, Name);
|
|
|
|
NewScopes.insert(std::make_pair(A, NewScope));
|
|
|
|
}
|
|
|
|
|
|
|
|
// Iterate over all new instructions in the map; for all memory-access
|
|
|
|
// instructions, add the alias scope metadata.
|
|
|
|
for (ValueToValueMapTy::iterator VMI = VMap.begin(), VMIE = VMap.end();
|
|
|
|
VMI != VMIE; ++VMI) {
|
|
|
|
if (const Instruction *I = dyn_cast<Instruction>(VMI->first)) {
|
|
|
|
if (!VMI->second)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
Instruction *NI = dyn_cast<Instruction>(VMI->second);
|
|
|
|
if (!NI)
|
|
|
|
continue;
|
|
|
|
|
2014-09-01 17:01:39 +08:00
|
|
|
bool IsArgMemOnlyCall = false, IsFuncCall = false;
|
2014-07-25 23:50:08 +08:00
|
|
|
SmallVector<const Value *, 2> PtrArgs;
|
|
|
|
|
|
|
|
if (const LoadInst *LI = dyn_cast<LoadInst>(I))
|
|
|
|
PtrArgs.push_back(LI->getPointerOperand());
|
|
|
|
else if (const StoreInst *SI = dyn_cast<StoreInst>(I))
|
|
|
|
PtrArgs.push_back(SI->getPointerOperand());
|
|
|
|
else if (const VAArgInst *VAAI = dyn_cast<VAArgInst>(I))
|
|
|
|
PtrArgs.push_back(VAAI->getPointerOperand());
|
|
|
|
else if (const AtomicCmpXchgInst *CXI = dyn_cast<AtomicCmpXchgInst>(I))
|
|
|
|
PtrArgs.push_back(CXI->getPointerOperand());
|
|
|
|
else if (const AtomicRMWInst *RMWI = dyn_cast<AtomicRMWInst>(I))
|
|
|
|
PtrArgs.push_back(RMWI->getPointerOperand());
|
2014-08-15 00:44:03 +08:00
|
|
|
else if (ImmutableCallSite ICS = ImmutableCallSite(I)) {
|
2014-08-30 20:48:33 +08:00
|
|
|
// If we know that the call does not access memory, then we'll still
|
|
|
|
// know that about the inlined clone of this call site, and we don't
|
|
|
|
// need to add metadata.
|
2014-08-15 00:44:03 +08:00
|
|
|
if (ICS.doesNotAccessMemory())
|
|
|
|
continue;
|
|
|
|
|
2014-09-01 17:01:39 +08:00
|
|
|
IsFuncCall = true;
|
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
with the new pass manager, and no longer relying on analysis groups.
This builds essentially a ground-up new AA infrastructure stack for
LLVM. The core ideas are the same that are used throughout the new pass
manager: type erased polymorphism and direct composition. The design is
as follows:
- FunctionAAResults is a type-erasing alias analysis results aggregation
interface to walk a single query across a range of results from
different alias analyses. Currently this is function-specific as we
always assume that aliasing queries are *within* a function.
- AAResultBase is a CRTP utility providing stub implementations of
various parts of the alias analysis result concept, notably in several
cases in terms of other more general parts of the interface. This can
be used to implement only a narrow part of the interface rather than
the entire interface. This isn't really ideal, this logic should be
hoisted into FunctionAAResults as currently it will cause
a significant amount of redundant work, but it faithfully models the
behavior of the prior infrastructure.
- All the alias analysis passes are ported to be wrapper passes for the
legacy PM and new-style analysis passes for the new PM with a shared
result object. In some cases (most notably CFL), this is an extremely
naive approach that we should revisit when we can specialize for the
new pass manager.
- BasicAA has been restructured to reflect that it is much more
fundamentally a function analysis because it uses dominator trees and
loop info that need to be constructed for each function.
All of the references to getting alias analysis results have been
updated to use the new aggregation interface. All the preservation and
other pass management code has been updated accordingly.
The way the FunctionAAResultsWrapperPass works is to detect the
available alias analyses when run, and add them to the results object.
This means that we should be able to continue to respect when various
passes are added to the pipeline, for example adding CFL or adding TBAA
passes should just cause their results to be available and to get folded
into this. The exception to this rule is BasicAA which really needs to
be a function pass due to using dominator trees and loop info. As
a consequence, the FunctionAAResultsWrapperPass directly depends on
BasicAA and always includes it in the aggregation.
This has significant implications for preserving analyses. Generally,
most passes shouldn't bother preserving FunctionAAResultsWrapperPass
because rebuilding the results just updates the set of known AA passes.
The exception to this rule are LoopPass instances which need to preserve
all the function analyses that the loop pass manager will end up
needing. This means preserving both BasicAAWrapperPass and the
aggregating FunctionAAResultsWrapperPass.
Now, when preserving an alias analysis, you do so by directly preserving
that analysis. This is only necessary for non-immutable-pass-provided
alias analyses though, and there are only three of interest: BasicAA,
GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
preserved when needed because it (like DominatorTree and LoopInfo) is
marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
set everywhere we previously were preserving all of AliasAnalysis, and
I've added SCEVAA in the intersection of that with where we preserve
SCEV itself.
One significant challenge to all of this is that the CGSCC passes were
actually using the alias analysis implementations by taking advantage of
a pretty amazing set of loop holes in the old pass manager's analysis
management code which allowed analysis groups to slide through in many
cases. Moving away from analysis groups makes this problem much more
obvious. To fix it, I've leveraged the flexibility the design of the new
PM components provides to just directly construct the relevant alias
analyses for the relevant functions in the IPO passes that need them.
This is a bit hacky, but should go away with the new pass manager, and
is already in many ways cleaner than the prior state.
Another significant challenge is that various facilities of the old
alias analysis infrastructure just don't fit any more. The most
significant of these is the alias analysis 'counter' pass. That pass
relied on the ability to snoop on AA queries at different points in the
analysis group chain. Instead, I'm planning to build printing
functionality directly into the aggregation layer. I've not included
that in this patch merely to keep it smaller.
Note that all of this needs a nearly complete rewrite of the AA
documentation. I'm planning to do that, but I'd like to make sure the
new design settles, and to flesh out a bit more of what it looks like in
the new pass manager first.
Differential Revision: http://reviews.llvm.org/D12080
llvm-svn: 247167
2015-09-10 01:55:00 +08:00
|
|
|
if (CalleeAAR) {
|
|
|
|
FunctionModRefBehavior MRB = CalleeAAR->getModRefBehavior(ICS);
|
2015-07-23 07:15:57 +08:00
|
|
|
if (MRB == FMRB_OnlyAccessesArgumentPointees ||
|
|
|
|
MRB == FMRB_OnlyReadsArgumentPointees)
|
2014-09-01 17:01:39 +08:00
|
|
|
IsArgMemOnlyCall = true;
|
|
|
|
}
|
|
|
|
|
2014-08-15 00:44:03 +08:00
|
|
|
for (ImmutableCallSite::arg_iterator AI = ICS.arg_begin(),
|
2014-09-01 17:01:39 +08:00
|
|
|
AE = ICS.arg_end(); AI != AE; ++AI) {
|
2014-08-30 20:48:33 +08:00
|
|
|
// We need to check the underlying objects of all arguments, not just
|
|
|
|
// the pointer arguments, because we might be passing pointers as
|
|
|
|
// integers, etc.
|
2014-09-01 17:01:39 +08:00
|
|
|
// However, if we know that the call only accesses pointer arguments,
|
2014-08-15 00:44:03 +08:00
|
|
|
// then we only need to check the pointer arguments.
|
2014-09-01 17:01:39 +08:00
|
|
|
if (IsArgMemOnlyCall && !(*AI)->getType()->isPointerTy())
|
|
|
|
continue;
|
|
|
|
|
2014-08-15 00:44:03 +08:00
|
|
|
PtrArgs.push_back(*AI);
|
2014-09-01 17:01:39 +08:00
|
|
|
}
|
2014-07-25 23:50:08 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// If we found no pointers, then this instruction is not suitable for
|
|
|
|
// pairing with an instruction to receive aliasing metadata.
|
2014-08-15 00:44:03 +08:00
|
|
|
// However, if this is a call, this we might just alias with none of the
|
|
|
|
// noalias arguments.
|
2014-09-01 12:26:40 +08:00
|
|
|
if (PtrArgs.empty() && !IsFuncCall)
|
2014-07-25 23:50:08 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
// It is possible that there is only one underlying object, but you
|
|
|
|
// need to go through several PHIs to see it, and thus could be
|
|
|
|
// repeated in the Objects list.
|
|
|
|
SmallPtrSet<const Value *, 4> ObjSet;
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
SmallVector<Metadata *, 4> Scopes, NoAliases;
|
2014-07-25 23:50:08 +08:00
|
|
|
|
|
|
|
SmallSetVector<const Argument *, 4> NAPtrArgs;
|
|
|
|
for (unsigned i = 0, ie = PtrArgs.size(); i != ie; ++i) {
|
|
|
|
SmallVector<Value *, 4> Objects;
|
|
|
|
GetUnderlyingObjects(const_cast<Value*>(PtrArgs[i]),
|
2015-10-07 07:24:35 +08:00
|
|
|
Objects, DL, /* LI = */ nullptr);
|
2014-07-25 23:50:08 +08:00
|
|
|
|
|
|
|
for (Value *O : Objects)
|
|
|
|
ObjSet.insert(O);
|
|
|
|
}
|
|
|
|
|
2014-08-30 00:33:41 +08:00
|
|
|
// Figure out if we're derived from anything that is not a noalias
|
2014-07-25 23:50:08 +08:00
|
|
|
// argument.
|
2014-08-30 20:48:33 +08:00
|
|
|
bool CanDeriveViaCapture = false, UsesAliasingPtr = false;
|
|
|
|
for (const Value *V : ObjSet) {
|
|
|
|
// Is this value a constant that cannot be derived from any pointer
|
|
|
|
// value (we need to exclude constant expressions, for example, that
|
|
|
|
// are formed from arithmetic on global symbols).
|
|
|
|
bool IsNonPtrConst = isa<ConstantInt>(V) || isa<ConstantFP>(V) ||
|
|
|
|
isa<ConstantPointerNull>(V) ||
|
|
|
|
isa<ConstantDataVector>(V) || isa<UndefValue>(V);
|
2014-09-01 12:26:40 +08:00
|
|
|
if (IsNonPtrConst)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// If this is anything other than a noalias argument, then we cannot
|
|
|
|
// completely describe the aliasing properties using alias.scope
|
|
|
|
// metadata (and, thus, won't add any).
|
|
|
|
if (const Argument *A = dyn_cast<Argument>(V)) {
|
|
|
|
if (!A->hasNoAliasAttr())
|
|
|
|
UsesAliasingPtr = true;
|
|
|
|
} else {
|
2014-08-30 20:48:33 +08:00
|
|
|
UsesAliasingPtr = true;
|
2014-07-25 23:50:08 +08:00
|
|
|
}
|
2014-09-01 12:26:40 +08:00
|
|
|
|
|
|
|
// If this is not some identified function-local object (which cannot
|
|
|
|
// directly alias a noalias argument), or some other argument (which,
|
|
|
|
// by definition, also cannot alias a noalias argument), then we could
|
|
|
|
// alias a noalias argument that has been captured).
|
|
|
|
if (!isa<Argument>(V) &&
|
|
|
|
!isIdentifiedFunctionLocal(const_cast<Value*>(V)))
|
|
|
|
CanDeriveViaCapture = true;
|
2014-08-30 20:48:33 +08:00
|
|
|
}
|
2014-09-01 12:26:40 +08:00
|
|
|
|
|
|
|
// A function call can always get captured noalias pointers (via other
|
|
|
|
// parameters, globals, etc.).
|
|
|
|
if (IsFuncCall && !IsArgMemOnlyCall)
|
|
|
|
CanDeriveViaCapture = true;
|
|
|
|
|
2014-07-25 23:50:08 +08:00
|
|
|
// First, we want to figure out all of the sets with which we definitely
|
|
|
|
// don't alias. Iterate over all noalias set, and add those for which:
|
|
|
|
// 1. The noalias argument is not in the set of objects from which we
|
|
|
|
// definitely derive.
|
|
|
|
// 2. The noalias argument has not yet been captured.
|
2014-09-01 12:26:40 +08:00
|
|
|
// An arbitrary function that might load pointers could see captured
|
|
|
|
// noalias arguments via other noalias arguments or globals, and so we
|
|
|
|
// must always check for prior capture.
|
2014-07-25 23:50:08 +08:00
|
|
|
for (const Argument *A : NoAliasArgs) {
|
|
|
|
if (!ObjSet.count(A) && (!CanDeriveViaCapture ||
|
2014-08-30 20:48:33 +08:00
|
|
|
// It might be tempting to skip the
|
|
|
|
// PointerMayBeCapturedBefore check if
|
|
|
|
// A->hasNoCaptureAttr() is true, but this is
|
|
|
|
// incorrect because nocapture only guarantees
|
|
|
|
// that no copies outlive the function, not
|
|
|
|
// that the value cannot be locally captured.
|
2014-07-25 23:50:08 +08:00
|
|
|
!PointerMayBeCapturedBefore(A,
|
|
|
|
/* ReturnCaptures */ false,
|
|
|
|
/* StoreCaptures */ false, I, &DT)))
|
|
|
|
NoAliases.push_back(NewScopes[A]);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!NoAliases.empty())
|
2014-11-01 08:10:31 +08:00
|
|
|
NI->setMetadata(LLVMContext::MD_noalias,
|
|
|
|
MDNode::concatenate(
|
2014-11-12 05:30:22 +08:00
|
|
|
NI->getMetadata(LLVMContext::MD_noalias),
|
2014-11-01 08:10:31 +08:00
|
|
|
MDNode::get(CalledFunc->getContext(), NoAliases)));
|
2014-08-30 20:48:33 +08:00
|
|
|
|
2014-07-25 23:50:08 +08:00
|
|
|
// Next, we want to figure out all of the sets to which we might belong.
|
2014-08-30 20:48:33 +08:00
|
|
|
// We might belong to a set if the noalias argument is in the set of
|
|
|
|
// underlying objects. If there is some non-noalias argument in our list
|
|
|
|
// of underlying objects, then we cannot add a scope because the fact
|
|
|
|
// that some access does not alias with any set of our noalias arguments
|
|
|
|
// cannot itself guarantee that it does not alias with this access
|
|
|
|
// (because there is some pointer of unknown origin involved and the
|
|
|
|
// other access might also depend on this pointer). We also cannot add
|
|
|
|
// scopes to arbitrary functions unless we know they don't access any
|
|
|
|
// non-parameter pointer-values.
|
|
|
|
bool CanAddScopes = !UsesAliasingPtr;
|
2014-09-01 12:26:40 +08:00
|
|
|
if (CanAddScopes && IsFuncCall)
|
|
|
|
CanAddScopes = IsArgMemOnlyCall;
|
2014-07-25 23:50:08 +08:00
|
|
|
|
2014-08-30 20:48:33 +08:00
|
|
|
if (CanAddScopes)
|
|
|
|
for (const Argument *A : NoAliasArgs) {
|
|
|
|
if (ObjSet.count(A))
|
|
|
|
Scopes.push_back(NewScopes[A]);
|
|
|
|
}
|
|
|
|
|
2014-07-25 23:50:08 +08:00
|
|
|
if (!Scopes.empty())
|
2014-11-01 08:10:31 +08:00
|
|
|
NI->setMetadata(
|
|
|
|
LLVMContext::MD_alias_scope,
|
2014-11-12 05:30:22 +08:00
|
|
|
MDNode::concatenate(NI->getMetadata(LLVMContext::MD_alias_scope),
|
2014-11-01 08:10:31 +08:00
|
|
|
MDNode::get(CalledFunc->getContext(), Scopes)));
|
2014-07-25 23:50:08 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-10-16 07:44:41 +08:00
|
|
|
/// If the inlined function has non-byval align arguments, then
|
|
|
|
/// add @llvm.assume-based alignment assumptions to preserve this information.
|
|
|
|
static void AddAlignmentAssumptions(CallSite CS, InlineFunctionInfo &IFI) {
|
2015-03-05 02:43:29 +08:00
|
|
|
if (!PreserveAlignmentAssumptions)
|
2014-10-16 07:44:41 +08:00
|
|
|
return;
|
2015-03-05 02:43:29 +08:00
|
|
|
auto &DL = CS.getCaller()->getParent()->getDataLayout();
|
2014-10-16 07:44:41 +08:00
|
|
|
|
|
|
|
// To avoid inserting redundant assumptions, we should check for assumptions
|
|
|
|
// already in the caller. To do this, we might need a DT of the caller.
|
|
|
|
DominatorTree DT;
|
|
|
|
bool DTCalculated = false;
|
|
|
|
|
2015-01-04 20:03:27 +08:00
|
|
|
Function *CalledFunc = CS.getCalledFunction();
|
|
|
|
for (Function::arg_iterator I = CalledFunc->arg_begin(),
|
|
|
|
E = CalledFunc->arg_end();
|
|
|
|
I != E; ++I) {
|
2014-10-16 07:44:41 +08:00
|
|
|
unsigned Align = I->getType()->isPointerTy() ? I->getParamAlignment() : 0;
|
|
|
|
if (Align && !I->hasByValOrInAllocaAttr() && !I->hasNUses(0)) {
|
|
|
|
if (!DTCalculated) {
|
|
|
|
DT.recalculate(const_cast<Function&>(*CS.getInstruction()->getParent()
|
|
|
|
->getParent()));
|
|
|
|
DTCalculated = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we can already prove the asserted alignment in the context of the
|
|
|
|
// caller, then don't bother inserting the assumption.
|
|
|
|
Value *Arg = CS.getArgument(I->getArgNo());
|
2015-03-10 10:37:25 +08:00
|
|
|
if (getKnownAlignment(Arg, DL, CS.getInstruction(),
|
2015-09-23 23:49:08 +08:00
|
|
|
&IFI.ACT->getAssumptionCache(*CS.getCaller()),
|
2015-03-10 10:37:25 +08:00
|
|
|
&DT) >= Align)
|
2014-10-16 07:44:41 +08:00
|
|
|
continue;
|
|
|
|
|
2015-03-05 02:43:29 +08:00
|
|
|
IRBuilder<>(CS.getInstruction())
|
|
|
|
.CreateAlignmentAssumption(DL, Arg, Align);
|
2014-10-16 07:44:41 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-03-11 03:42:57 +08:00
|
|
|
/// Once we have cloned code over from a callee into the caller,
|
|
|
|
/// update the specified callgraph to reflect the changes we made.
|
|
|
|
/// Note that it's possible that not all code was copied over, so only
|
2008-09-08 19:05:51 +08:00
|
|
|
/// some edges of the callgraph may remain.
|
|
|
|
static void UpdateCallGraphAfterInlining(CallSite CS,
|
2006-07-13 02:29:36 +08:00
|
|
|
Function::iterator FirstNewBlock,
|
2010-10-13 09:36:30 +08:00
|
|
|
ValueToValueMapTy &VMap,
|
2010-04-23 07:37:35 +08:00
|
|
|
InlineFunctionInfo &IFI) {
|
|
|
|
CallGraph &CG = *IFI.CG;
|
2008-09-08 19:05:51 +08:00
|
|
|
const Function *Caller = CS.getInstruction()->getParent()->getParent();
|
|
|
|
const Function *Callee = CS.getCalledFunction();
|
2006-01-15 04:07:50 +08:00
|
|
|
CallGraphNode *CalleeNode = CG[Callee];
|
|
|
|
CallGraphNode *CallerNode = CG[Caller];
|
2008-09-05 20:37:12 +08:00
|
|
|
|
2006-07-13 02:29:36 +08:00
|
|
|
// Since we inlined some uninlined call sites in the callee into the caller,
|
2006-01-15 04:07:50 +08:00
|
|
|
// add edges from the caller to all of the callees of the callee.
|
2009-01-16 02:40:09 +08:00
|
|
|
CallGraphNode::iterator I = CalleeNode->begin(), E = CalleeNode->end();
|
|
|
|
|
|
|
|
// Consider the case where CalleeNode == CallerNode.
|
2009-01-17 08:09:08 +08:00
|
|
|
CallGraphNode::CalledFunctionsVector CallCache;
|
2009-01-16 02:40:09 +08:00
|
|
|
if (CalleeNode == CallerNode) {
|
|
|
|
CallCache.assign(I, E);
|
|
|
|
I = CallCache.begin();
|
|
|
|
E = CallCache.end();
|
|
|
|
}
|
|
|
|
|
|
|
|
for (; I != E; ++I) {
|
2009-09-01 14:31:31 +08:00
|
|
|
const Value *OrigCall = I->first;
|
2008-09-05 20:37:12 +08:00
|
|
|
|
2010-10-13 09:36:30 +08:00
|
|
|
ValueToValueMapTy::iterator VMI = VMap.find(OrigCall);
|
2006-07-13 05:37:11 +08:00
|
|
|
// Only copy the edge if the call was inlined!
|
2014-04-25 13:29:35 +08:00
|
|
|
if (VMI == VMap.end() || VMI->second == nullptr)
|
2009-08-27 11:51:50 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
// If the call was inlined, but then constant folded, there is no edge to
|
|
|
|
// add. Check for this case.
|
2010-04-23 05:31:00 +08:00
|
|
|
Instruction *NewCall = dyn_cast<Instruction>(VMI->second);
|
2015-03-11 23:12:32 +08:00
|
|
|
if (!NewCall)
|
|
|
|
continue;
|
2010-05-01 09:26:13 +08:00
|
|
|
|
2015-03-11 23:12:32 +08:00
|
|
|
// We do not treat intrinsic calls like real function calls because we
|
|
|
|
// expect them to become inline code; do not add an edge for an intrinsic.
|
|
|
|
CallSite CS = CallSite(NewCall);
|
|
|
|
if (CS && CS.getCalledFunction() && CS.getCalledFunction()->isIntrinsic())
|
|
|
|
continue;
|
|
|
|
|
2010-05-01 09:26:13 +08:00
|
|
|
// Remember that this call site got inlined for the client of
|
|
|
|
// InlineFunction.
|
|
|
|
IFI.InlinedCalls.push_back(NewCall);
|
|
|
|
|
2010-04-23 05:31:00 +08:00
|
|
|
// It's possible that inlining the callsite will cause it to go from an
|
|
|
|
// indirect to a direct call by resolving a function pointer. If this
|
|
|
|
// happens, set the callee of the new call site to a more precise
|
|
|
|
// destination. This can also happen if the call graph node of the caller
|
|
|
|
// was just unnecessarily imprecise.
|
2014-04-25 13:29:35 +08:00
|
|
|
if (!I->second->getFunction())
|
2010-04-23 05:31:00 +08:00
|
|
|
if (Function *F = CallSite(NewCall).getCalledFunction()) {
|
|
|
|
// Indirect call site resolved to direct call.
|
2010-07-27 23:02:37 +08:00
|
|
|
CallerNode->addCalledFunction(CallSite(NewCall), CG[F]);
|
|
|
|
|
2010-04-23 05:31:00 +08:00
|
|
|
continue;
|
|
|
|
}
|
2010-07-27 23:02:37 +08:00
|
|
|
|
|
|
|
CallerNode->addCalledFunction(CallSite(NewCall), I->second);
|
2006-07-13 02:29:36 +08:00
|
|
|
}
|
2009-08-27 11:51:50 +08:00
|
|
|
|
2009-01-14 06:43:37 +08:00
|
|
|
// Update the call graph by deleting the edge from Callee to Caller. We must
|
|
|
|
// do this after the loop above in case Caller and Callee are the same.
|
|
|
|
CallerNode->removeCallEdgeFor(CS);
|
2006-01-15 04:07:50 +08:00
|
|
|
}
|
|
|
|
|
2014-04-16 02:01:54 +08:00
|
|
|
static void HandleByValArgumentInit(Value *Dst, Value *Src, Module *M,
|
|
|
|
BasicBlock *InsertBlock,
|
|
|
|
InlineFunctionInfo &IFI) {
|
|
|
|
Type *AggTy = cast<PointerType>(Src->getType())->getElementType();
|
2015-10-13 10:39:05 +08:00
|
|
|
IRBuilder<> Builder(InsertBlock, InsertBlock->begin());
|
2014-04-16 02:01:54 +08:00
|
|
|
|
2015-03-05 02:43:29 +08:00
|
|
|
Value *Size = Builder.getInt64(M->getDataLayout().getTypeStoreSize(AggTy));
|
2014-04-16 02:01:54 +08:00
|
|
|
|
|
|
|
// Always generate a memcpy of alignment 1 here because we don't know
|
|
|
|
// the alignment of the src pointer. Other optimizations can infer
|
|
|
|
// better alignment.
|
2015-11-19 13:56:52 +08:00
|
|
|
Builder.CreateMemCpy(Dst, Src, Size, /*Align=*/1);
|
2014-04-16 02:01:54 +08:00
|
|
|
}
|
|
|
|
|
2015-03-11 03:42:57 +08:00
|
|
|
/// When inlining a call site that has a byval argument,
|
2010-12-20 16:10:40 +08:00
|
|
|
/// we have to make the implicit memcpy explicit by adding it.
|
2013-11-03 20:22:13 +08:00
|
|
|
static Value *HandleByValArgument(Value *Arg, Instruction *TheCall,
|
2010-12-20 15:57:41 +08:00
|
|
|
const Function *CalledFunc,
|
|
|
|
InlineFunctionInfo &IFI,
|
2014-11-04 10:02:14 +08:00
|
|
|
unsigned ByValAlignment) {
|
2014-04-24 04:58:57 +08:00
|
|
|
PointerType *ArgTy = cast<PointerType>(Arg->getType());
|
|
|
|
Type *AggTy = ArgTy->getElementType();
|
2010-12-20 16:10:40 +08:00
|
|
|
|
2015-01-04 20:03:27 +08:00
|
|
|
Function *Caller = TheCall->getParent()->getParent();
|
|
|
|
|
2010-12-20 16:10:40 +08:00
|
|
|
// If the called function is readonly, then it could not mutate the caller's
|
|
|
|
// copy of the byval'd memory. In this case, it is safe to elide the copy and
|
|
|
|
// temporary.
|
2013-11-03 20:22:13 +08:00
|
|
|
if (CalledFunc->onlyReadsMemory()) {
|
2010-12-20 16:10:40 +08:00
|
|
|
// If the byval argument has a specified alignment that is greater than the
|
|
|
|
// passed in pointer, then we either have to round up the input pointer or
|
|
|
|
// give up on this transformation.
|
|
|
|
if (ByValAlignment <= 1) // 0 = unspecified, 1 = no particular alignment.
|
2013-11-03 20:22:13 +08:00
|
|
|
return Arg;
|
2010-12-20 16:10:40 +08:00
|
|
|
|
2015-03-10 10:37:25 +08:00
|
|
|
const DataLayout &DL = Caller->getParent()->getDataLayout();
|
|
|
|
|
2010-12-26 04:42:38 +08:00
|
|
|
// If the pointer is already known to be sufficiently aligned, or if we can
|
|
|
|
// round it up to a larger alignment, then we don't need a temporary.
|
2015-03-10 10:37:25 +08:00
|
|
|
if (getOrEnforceKnownAlignment(Arg, ByValAlignment, DL, TheCall,
|
|
|
|
&IFI.ACT->getAssumptionCache(*Caller)) >=
|
|
|
|
ByValAlignment)
|
2013-11-03 20:22:13 +08:00
|
|
|
return Arg;
|
2010-12-20 16:10:40 +08:00
|
|
|
|
2010-12-26 04:42:38 +08:00
|
|
|
// Otherwise, we have to make a memcpy to get a safe alignment. This is bad
|
|
|
|
// for code quality, but rarely happens and is required for correctness.
|
2010-12-20 16:10:40 +08:00
|
|
|
}
|
2010-12-20 15:57:41 +08:00
|
|
|
|
2012-10-09 00:38:25 +08:00
|
|
|
// Create the alloca. If we have DataLayout, use nice alignment.
|
2015-03-05 02:43:29 +08:00
|
|
|
unsigned Align =
|
|
|
|
Caller->getParent()->getDataLayout().getPrefTypeAlignment(AggTy);
|
|
|
|
|
2010-12-20 15:57:41 +08:00
|
|
|
// If the byval had an alignment specified, we *must* use at least that
|
|
|
|
// alignment, as it is required by the byval argument (and uses of the
|
|
|
|
// pointer inside the callee).
|
|
|
|
Align = std::max(Align, ByValAlignment);
|
|
|
|
|
2014-04-25 13:29:35 +08:00
|
|
|
Value *NewAlloca = new AllocaInst(AggTy, nullptr, Align, Arg->getName(),
|
2010-12-20 15:57:41 +08:00
|
|
|
&*Caller->begin()->begin());
|
2014-04-16 02:06:46 +08:00
|
|
|
IFI.StaticAllocas.push_back(cast<AllocaInst>(NewAlloca));
|
2010-12-20 15:57:41 +08:00
|
|
|
|
|
|
|
// Uses of the argument in the function should use our new alloca
|
|
|
|
// instead.
|
|
|
|
return NewAlloca;
|
|
|
|
}
|
|
|
|
|
2015-03-11 03:42:57 +08:00
|
|
|
// Check whether this Value is used by a lifetime intrinsic.
|
2011-05-22 13:22:10 +08:00
|
|
|
static bool isUsedByLifetimeMarker(Value *V) {
|
2014-03-09 11:16:01 +08:00
|
|
|
for (User *U : V->users()) {
|
|
|
|
if (IntrinsicInst *II = dyn_cast<IntrinsicInst>(U)) {
|
2011-05-22 13:22:10 +08:00
|
|
|
switch (II->getIntrinsicID()) {
|
|
|
|
default: break;
|
|
|
|
case Intrinsic::lifetime_start:
|
|
|
|
case Intrinsic::lifetime_end:
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-03-11 03:42:57 +08:00
|
|
|
// Check whether the given alloca already has
|
2011-05-22 13:22:10 +08:00
|
|
|
// lifetime.start or lifetime.end intrinsics.
|
|
|
|
static bool hasLifetimeMarkers(AllocaInst *AI) {
|
2014-04-24 04:58:57 +08:00
|
|
|
Type *Ty = AI->getType();
|
|
|
|
Type *Int8PtrTy = Type::getInt8PtrTy(Ty->getContext(),
|
|
|
|
Ty->getPointerAddressSpace());
|
|
|
|
if (Ty == Int8PtrTy)
|
2011-05-22 13:22:10 +08:00
|
|
|
return isUsedByLifetimeMarker(AI);
|
|
|
|
|
2011-06-14 08:59:24 +08:00
|
|
|
// Do a scan to find all the casts to i8*.
|
2014-03-09 11:16:01 +08:00
|
|
|
for (User *U : AI->users()) {
|
|
|
|
if (U->getType() != Int8PtrTy) continue;
|
|
|
|
if (U->stripPointerCasts() != AI) continue;
|
|
|
|
if (isUsedByLifetimeMarker(U))
|
2011-05-22 13:22:10 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-01-22 06:57:29 +08:00
|
|
|
/// Rebuild the entire inlined-at chain for this instruction so that the top of
|
|
|
|
/// the chain now is inlined-at the new call site.
|
|
|
|
static DebugLoc
|
2015-04-30 00:38:44 +08:00
|
|
|
updateInlinedAtInfo(DebugLoc DL, DILocation *InlinedAtNode, LLVMContext &Ctx,
|
|
|
|
DenseMap<const DILocation *, DILocation *> &IANodes) {
|
|
|
|
SmallVector<DILocation *, 3> InlinedAtLocations;
|
|
|
|
DILocation *Last = InlinedAtNode;
|
|
|
|
DILocation *CurInlinedAt = DL;
|
2015-01-22 06:57:29 +08:00
|
|
|
|
|
|
|
// Gather all the inlined-at nodes
|
2015-04-30 00:38:44 +08:00
|
|
|
while (DILocation *IA = CurInlinedAt->getInlinedAt()) {
|
2015-01-22 06:57:29 +08:00
|
|
|
// Skip any we've already built nodes for
|
2015-04-30 00:38:44 +08:00
|
|
|
if (DILocation *Found = IANodes[IA]) {
|
2015-01-22 06:57:29 +08:00
|
|
|
Last = Found;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
InlinedAtLocations.push_back(IA);
|
2015-03-31 03:49:49 +08:00
|
|
|
CurInlinedAt = IA;
|
2015-01-22 06:57:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Starting from the top, rebuild the nodes to point to the new inlined-at
|
|
|
|
// location (then rebuilding the rest of the chain behind it) and update the
|
|
|
|
// map of already-constructed inlined-at nodes.
|
2015-07-25 05:13:43 +08:00
|
|
|
for (const DILocation *MD : make_range(InlinedAtLocations.rbegin(),
|
|
|
|
InlinedAtLocations.rend())) {
|
2015-04-30 00:38:44 +08:00
|
|
|
Last = IANodes[MD] = DILocation::getDistinct(
|
2015-01-22 06:57:29 +08:00
|
|
|
Ctx, MD->getLine(), MD->getColumn(), MD->getScope(), Last);
|
2011-07-09 02:01:31 +08:00
|
|
|
}
|
2012-03-27 03:09:38 +08:00
|
|
|
|
2015-01-22 06:57:29 +08:00
|
|
|
// And finally create the normal location for this instruction, referring to
|
|
|
|
// the new inlined-at chain.
|
2015-03-31 03:49:49 +08:00
|
|
|
return DebugLoc::get(DL.getLine(), DL.getCol(), DL.getScope(), Last);
|
2011-07-09 02:01:31 +08:00
|
|
|
}
|
|
|
|
|
2015-03-11 03:42:57 +08:00
|
|
|
/// Update inlined instructions' line numbers to
|
2011-07-09 02:01:31 +08:00
|
|
|
/// to encode location where these instructions are inlined.
|
|
|
|
static void fixupLineNumbers(Function *Fn, Function::iterator FI,
|
2012-03-27 03:09:40 +08:00
|
|
|
Instruction *TheCall) {
|
2011-07-09 02:01:31 +08:00
|
|
|
DebugLoc TheCallDL = TheCall->getDebugLoc();
|
2015-03-31 03:49:49 +08:00
|
|
|
if (!TheCallDL)
|
2011-07-09 02:01:31 +08:00
|
|
|
return;
|
|
|
|
|
2015-01-22 06:57:29 +08:00
|
|
|
auto &Ctx = Fn->getContext();
|
2015-04-30 00:38:44 +08:00
|
|
|
DILocation *InlinedAtNode = TheCallDL;
|
2015-01-22 06:57:29 +08:00
|
|
|
|
|
|
|
// Create a unique call site, not to be confused with any other call from the
|
|
|
|
// same location.
|
2015-04-30 00:38:44 +08:00
|
|
|
InlinedAtNode = DILocation::getDistinct(
|
2015-01-22 06:57:29 +08:00
|
|
|
Ctx, InlinedAtNode->getLine(), InlinedAtNode->getColumn(),
|
|
|
|
InlinedAtNode->getScope(), InlinedAtNode->getInlinedAt());
|
|
|
|
|
|
|
|
// Cache the inlined-at nodes as they're built so they are reused, without
|
|
|
|
// this every instruction's inlined-at chain would become distinct from each
|
|
|
|
// other.
|
2015-04-30 00:38:44 +08:00
|
|
|
DenseMap<const DILocation *, DILocation *> IANodes;
|
2015-01-22 06:57:29 +08:00
|
|
|
|
2011-07-09 02:01:31 +08:00
|
|
|
for (; FI != Fn->end(); ++FI) {
|
|
|
|
for (BasicBlock::iterator BI = FI->begin(), BE = FI->end();
|
|
|
|
BI != BE; ++BI) {
|
|
|
|
DebugLoc DL = BI->getDebugLoc();
|
2015-03-31 03:49:49 +08:00
|
|
|
if (!DL) {
|
2014-06-09 17:09:19 +08:00
|
|
|
// If the inlined instruction has no line number, make it look as if it
|
|
|
|
// originates from the call location. This is important for
|
|
|
|
// ((__always_inline__, __nodebug__)) functions which must use caller
|
|
|
|
// location for all instructions in their function body.
|
2014-10-21 09:00:55 +08:00
|
|
|
|
|
|
|
// Don't update static allocas, as they may get moved later.
|
|
|
|
if (auto *AI = dyn_cast<AllocaInst>(BI))
|
|
|
|
if (isa<Constant>(AI->getArraySize()))
|
|
|
|
continue;
|
|
|
|
|
2014-06-09 17:09:19 +08:00
|
|
|
BI->setDebugLoc(TheCallDL);
|
|
|
|
} else {
|
2015-01-22 06:57:29 +08:00
|
|
|
BI->setDebugLoc(updateInlinedAtInfo(DL, InlinedAtNode, BI->getContext(), IANodes));
|
2011-08-11 05:50:54 +08:00
|
|
|
}
|
2011-07-09 02:01:31 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-03-11 03:42:57 +08:00
|
|
|
/// This function inlines the called function into the basic block of the
|
|
|
|
/// caller. This returns false if it is not possible to inline this call.
|
|
|
|
/// The program is still in a well defined state if this occurs though.
|
2012-01-31 09:01:16 +08:00
|
|
|
///
|
|
|
|
/// Note that this only does one level of inlining. For example, if the
|
|
|
|
/// instruction 'call B' is inlined, and 'B' calls 'C', then the call to 'C' now
|
|
|
|
/// exists in the instruction stream. Similarly this will inline a recursive
|
|
|
|
/// function by one level.
|
2012-03-27 03:09:38 +08:00
|
|
|
bool llvm::InlineFunction(CallSite CS, InlineFunctionInfo &IFI,
|
[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
|
|
|
AAResults *CalleeAAR, bool InsertLifetime) {
|
2003-08-24 14:59:16 +08:00
|
|
|
Instruction *TheCall = CS.getInstruction();
|
|
|
|
assert(TheCall->getParent() && TheCall->getParent()->getParent() &&
|
|
|
|
"Instruction not in function!");
|
2003-05-29 23:11:31 +08:00
|
|
|
|
2010-04-23 07:07:58 +08:00
|
|
|
// If IFI has any state in it, zap it before we fill it in.
|
|
|
|
IFI.reset();
|
|
|
|
|
2003-08-24 14:59:16 +08:00
|
|
|
const Function *CalledFunc = CS.getCalledFunction();
|
2014-04-25 13:29:35 +08:00
|
|
|
if (!CalledFunc || // Can't inline external function or indirect
|
2007-01-31 04:08:39 +08:00
|
|
|
CalledFunc->isDeclaration() || // call, or call to a vararg function!
|
2010-03-25 07:35:21 +08:00
|
|
|
CalledFunc->getFunctionType()->isVarArg()) return false;
|
2003-05-29 23:11:31 +08:00
|
|
|
|
2015-11-18 14:23:38 +08:00
|
|
|
// The inliner does not know how to inline through calls with operand bundles
|
|
|
|
// in general ...
|
|
|
|
if (CS.hasOperandBundles()) {
|
|
|
|
// ... but it knows how to inline through "deopt" operand bundles.
|
|
|
|
bool CanInline =
|
|
|
|
CS.getNumOperandBundles() == 1 &&
|
|
|
|
CS.getOperandBundleAt(0).getTagID() == LLVMContext::OB_deopt;
|
|
|
|
if (!CanInline)
|
|
|
|
return false;
|
|
|
|
}
|
2015-10-24 04:09:55 +08:00
|
|
|
|
2007-12-20 05:13:37 +08:00
|
|
|
// If the call to the callee cannot throw, set the 'nounwind' flag on any
|
|
|
|
// calls that we inline.
|
|
|
|
bool MarkNoUnwind = CS.doesNotThrow();
|
|
|
|
|
2003-08-24 14:59:16 +08:00
|
|
|
BasicBlock *OrigBB = TheCall->getParent();
|
2003-05-29 23:11:31 +08:00
|
|
|
Function *Caller = OrigBB->getParent();
|
|
|
|
|
2007-12-25 11:10:07 +08:00
|
|
|
// GC poses two hazards to inlining, which only occur when the callee has GC:
|
|
|
|
// 1. If the caller has no GC, then the callee's GC must be propagated to the
|
|
|
|
// caller.
|
|
|
|
// 2. If the caller has a differing GC, it is invalid to inline.
|
2008-08-18 02:44:35 +08:00
|
|
|
if (CalledFunc->hasGC()) {
|
|
|
|
if (!Caller->hasGC())
|
|
|
|
Caller->setGC(CalledFunc->getGC());
|
|
|
|
else if (CalledFunc->getGC() != Caller->getGC())
|
2007-12-25 11:10:07 +08:00
|
|
|
return false;
|
|
|
|
}
|
2008-09-05 20:37:12 +08:00
|
|
|
|
2011-12-03 02:37:31 +08:00
|
|
|
// Get the personality function from the callee if it contains a landing pad.
|
2015-06-18 04:52:32 +08:00
|
|
|
Constant *CalledPersonality =
|
2015-10-14 06:08:17 +08:00
|
|
|
CalledFunc->hasPersonalityFn()
|
|
|
|
? CalledFunc->getPersonalityFn()->stripPointerCasts()
|
|
|
|
: nullptr;
|
2011-08-14 16:01:36 +08:00
|
|
|
|
2011-12-03 02:37:31 +08:00
|
|
|
// Find the personality function used by the landing pads of the caller. If it
|
|
|
|
// exists, then check to see that it matches the personality function used in
|
|
|
|
// the callee.
|
2015-06-18 04:52:32 +08:00
|
|
|
Constant *CallerPersonality =
|
2015-10-14 06:08:17 +08:00
|
|
|
Caller->hasPersonalityFn()
|
|
|
|
? Caller->getPersonalityFn()->stripPointerCasts()
|
|
|
|
: nullptr;
|
2015-06-18 04:52:32 +08:00
|
|
|
if (CalledPersonality) {
|
|
|
|
if (!CallerPersonality)
|
|
|
|
Caller->setPersonalityFn(CalledPersonality);
|
|
|
|
// If the personality functions match, then we can perform the
|
|
|
|
// inlining. Otherwise, we can't inline.
|
|
|
|
// TODO: This isn't 100% true. Some personality functions are proper
|
|
|
|
// supersets of others and can be used in place of the other.
|
|
|
|
else if (CalledPersonality != CallerPersonality)
|
|
|
|
return false;
|
2012-01-31 09:01:16 +08:00
|
|
|
}
|
2011-12-03 02:37:31 +08:00
|
|
|
|
[IR] Reformulate LLVM's EH funclet IR
While we have successfully implemented a funclet-oriented EH scheme on
top of LLVM IR, our scheme has some notable deficiencies:
- catchendpad and cleanupendpad are necessary in the current design
but they are difficult to explain to others, even to seasoned LLVM
experts.
- catchendpad and cleanupendpad are optimization barriers. They cannot
be split and force all potentially throwing call-sites to be invokes.
This has a noticable effect on the quality of our code generation.
- catchpad, while similar in some aspects to invoke, is fairly awkward.
It is unsplittable, starts a funclet, and has control flow to other
funclets.
- The nesting relationship between funclets is currently a property of
control flow edges. Because of this, we are forced to carefully
analyze the flow graph to see if there might potentially exist illegal
nesting among funclets. While we have logic to clone funclets when
they are illegally nested, it would be nicer if we had a
representation which forbade them upfront.
Let's clean this up a bit by doing the following:
- Instead, make catchpad more like cleanuppad and landingpad: no control
flow, just a bunch of simple operands; catchpad would be splittable.
- Introduce catchswitch, a control flow instruction designed to model
the constraints of funclet oriented EH.
- Make funclet scoping explicit by having funclet instructions consume
the token produced by the funclet which contains them.
- Remove catchendpad and cleanupendpad. Their presence can be inferred
implicitly using coloring information.
N.B. The state numbering code for the CLR has been updated but the
veracity of it's output cannot be spoken for. An expert should take a
look to make sure the results are reasonable.
Reviewers: rnk, JosephTremoulet, andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D15139
llvm-svn: 255422
2015-12-12 13:38:55 +08:00
|
|
|
// We need to figure out which funclet the callsite was in so that we may
|
|
|
|
// properly nest the callee.
|
|
|
|
Instruction *CallSiteEHPad = nullptr;
|
|
|
|
if (CalledPersonality && CallerPersonality) {
|
|
|
|
EHPersonality Personality = classifyEHPersonality(CalledPersonality);
|
|
|
|
if (isFuncletEHPersonality(Personality)) {
|
|
|
|
DenseMap<BasicBlock *, ColorVector> CallerBlockColors =
|
|
|
|
colorEHFunclets(*Caller);
|
|
|
|
ColorVector &CallSiteColors = CallerBlockColors[OrigBB];
|
|
|
|
size_t NumColors = CallSiteColors.size();
|
|
|
|
// There is no single parent, inlining will not succeed.
|
|
|
|
if (NumColors > 1)
|
|
|
|
return false;
|
|
|
|
if (NumColors == 1) {
|
|
|
|
BasicBlock *CallSiteFuncletBB = CallSiteColors.front();
|
|
|
|
if (CallSiteFuncletBB != Caller->begin()) {
|
|
|
|
CallSiteEHPad = CallSiteFuncletBB->getFirstNonPHI();
|
|
|
|
assert(CallSiteEHPad->isEHPad() && "Expected an EHPad!");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// OK, the inlining site is legal. What about the target function?
|
|
|
|
|
|
|
|
if (CallSiteEHPad) {
|
|
|
|
if (Personality == EHPersonality::MSVC_CXX) {
|
|
|
|
// The MSVC personality cannot tolerate catches getting inlined into
|
|
|
|
// cleanup funclets.
|
|
|
|
if (isa<CleanupPadInst>(CallSiteEHPad)) {
|
|
|
|
// Ok, the call site is within a cleanuppad. Let's check the callee
|
|
|
|
// for catchpads.
|
|
|
|
for (const BasicBlock &CalledBB : *CalledFunc) {
|
|
|
|
if (isa<CatchPadInst>(CalledBB.getFirstNonPHI()))
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else if (isAsynchronousEHPersonality(Personality)) {
|
|
|
|
// SEH is even less tolerant, there may not be any sort of exceptional
|
|
|
|
// funclet in the callee.
|
|
|
|
for (const BasicBlock &CalledBB : *CalledFunc) {
|
|
|
|
if (CalledBB.isEHPad())
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2004-02-04 09:41:09 +08:00
|
|
|
// Get an iterator to the last basic block in the function, which will have
|
|
|
|
// the new function inlined after it.
|
2015-10-13 10:39:05 +08:00
|
|
|
Function::iterator LastBlock = --Caller->end();
|
2004-02-04 09:41:09 +08:00
|
|
|
|
2004-02-04 10:51:48 +08:00
|
|
|
// Make sure to capture all of the return instructions from the cloned
|
|
|
|
// function.
|
2009-08-27 12:02:30 +08:00
|
|
|
SmallVector<ReturnInst*, 8> Returns;
|
2006-01-14 03:05:59 +08:00
|
|
|
ClonedCodeInfo InlinedFunctionInfo;
|
2009-03-04 10:09:48 +08:00
|
|
|
Function::iterator FirstNewBlock;
|
2007-12-20 05:13:37 +08:00
|
|
|
|
2010-06-24 07:55:51 +08:00
|
|
|
{ // Scope to destroy VMap after cloning.
|
2010-10-13 09:36:30 +08:00
|
|
|
ValueToValueMapTy VMap;
|
2014-04-16 02:01:54 +08:00
|
|
|
// Keep a list of pair (dst, src) to emit byval initializations.
|
|
|
|
SmallVector<std::pair<Value*, Value*>, 4> ByValInit;
|
2006-05-27 09:28:04 +08:00
|
|
|
|
2015-03-05 02:43:29 +08:00
|
|
|
auto &DL = Caller->getParent()->getDataLayout();
|
|
|
|
|
2008-06-21 01:11:32 +08:00
|
|
|
assert(CalledFunc->arg_size() == CS.arg_size() &&
|
2004-02-04 10:51:48 +08:00
|
|
|
"No varargs calls can be inlined!");
|
2008-09-05 20:37:12 +08:00
|
|
|
|
2008-01-11 14:09:30 +08:00
|
|
|
// Calculate the vector of arguments to pass into the function cloner, which
|
|
|
|
// matches up the formal to the actual argument values.
|
2004-02-04 10:51:48 +08:00
|
|
|
CallSite::arg_iterator AI = CS.arg_begin();
|
2008-01-11 14:09:30 +08:00
|
|
|
unsigned ArgNo = 0;
|
2005-03-15 12:54:21 +08:00
|
|
|
for (Function::const_arg_iterator I = CalledFunc->arg_begin(),
|
2008-01-11 14:09:30 +08:00
|
|
|
E = CalledFunc->arg_end(); I != E; ++I, ++AI, ++ArgNo) {
|
|
|
|
Value *ActualArg = *AI;
|
2008-09-05 20:37:12 +08:00
|
|
|
|
2008-01-28 02:12:58 +08:00
|
|
|
// When byval arguments actually inlined, we need to make the copy implied
|
|
|
|
// by them explicit. However, we don't do this if the callee is readonly
|
|
|
|
// or readnone, because the copy would be unneeded: the callee doesn't
|
|
|
|
// modify the struct.
|
2011-11-21 03:09:04 +08:00
|
|
|
if (CS.isByValArgument(ArgNo)) {
|
2013-11-03 20:22:13 +08:00
|
|
|
ActualArg = HandleByValArgument(ActualArg, TheCall, CalledFunc, IFI,
|
2014-11-04 10:02:14 +08:00
|
|
|
CalledFunc->getParamAlignment(ArgNo+1));
|
2014-04-22 04:48:47 +08:00
|
|
|
if (ActualArg != *AI)
|
2014-04-16 02:01:54 +08:00
|
|
|
ByValInit.push_back(std::make_pair(ActualArg, (Value*) *AI));
|
2008-01-11 14:09:30 +08:00
|
|
|
}
|
2008-09-05 20:37:12 +08:00
|
|
|
|
2015-10-13 10:39:05 +08:00
|
|
|
VMap[&*I] = ActualArg;
|
2008-01-11 14:09:30 +08:00
|
|
|
}
|
2005-04-22 07:48:37 +08:00
|
|
|
|
2014-10-16 07:44:41 +08:00
|
|
|
// Add alignment assumptions if necessary. We do this before the inlined
|
|
|
|
// instructions are actually cloned into the caller so that we can easily
|
|
|
|
// check what will be known at the start of the inlined code.
|
|
|
|
AddAlignmentAssumptions(CS, IFI);
|
|
|
|
|
2006-05-27 09:28:04 +08:00
|
|
|
// We want the inliner to prune the code as it copies. We would LOVE to
|
|
|
|
// have no dead or constant instructions leftover after inlining occurs
|
|
|
|
// (which can happen, e.g., because an argument was constant), but we'll be
|
|
|
|
// happy with whatever the cloner can do.
|
2015-03-05 02:43:29 +08:00
|
|
|
CloneAndPruneFunctionInto(Caller, CalledFunc, VMap,
|
2010-08-26 23:41:53 +08:00
|
|
|
/*ModuleLevelChanges=*/false, Returns, ".i",
|
2015-03-10 10:37:25 +08:00
|
|
|
&InlinedFunctionInfo, TheCall);
|
2008-09-05 20:37:12 +08:00
|
|
|
|
2006-07-13 02:29:36 +08:00
|
|
|
// Remember the first block that is newly cloned over.
|
|
|
|
FirstNewBlock = LastBlock; ++FirstNewBlock;
|
2008-09-05 20:37:12 +08:00
|
|
|
|
2014-04-16 02:01:54 +08:00
|
|
|
// Inject byval arguments initialization.
|
|
|
|
for (std::pair<Value*, Value*> &Init : ByValInit)
|
|
|
|
HandleByValArgumentInit(Init.first, Init.second, Caller->getParent(),
|
2015-10-13 10:39:05 +08:00
|
|
|
&*FirstNewBlock, IFI);
|
2014-04-16 02:01:54 +08:00
|
|
|
|
2015-11-18 14:23:38 +08:00
|
|
|
if (CS.hasOperandBundles()) {
|
|
|
|
auto ParentDeopt = CS.getOperandBundleAt(0);
|
|
|
|
assert(ParentDeopt.getTagID() == LLVMContext::OB_deopt &&
|
|
|
|
"Checked on entry!");
|
|
|
|
|
|
|
|
SmallVector<OperandBundleDef, 2> OpDefs;
|
|
|
|
|
|
|
|
for (auto &VH : InlinedFunctionInfo.OperandBundleCallSites) {
|
2015-12-10 04:33:52 +08:00
|
|
|
if (!VH) continue; // instruction was DCE'd after being cloned
|
|
|
|
|
|
|
|
Instruction *I = cast<Instruction>(VH);
|
2015-11-18 14:23:38 +08:00
|
|
|
|
|
|
|
OpDefs.clear();
|
|
|
|
|
|
|
|
CallSite ICS(I);
|
|
|
|
OpDefs.reserve(ICS.getNumOperandBundles());
|
|
|
|
|
|
|
|
for (unsigned i = 0, e = ICS.getNumOperandBundles(); i < e; ++i) {
|
|
|
|
auto ChildOB = ICS.getOperandBundleAt(i);
|
|
|
|
if (ChildOB.getTagID() != LLVMContext::OB_deopt) {
|
|
|
|
// If the inlined call has other operand bundles, let them be
|
|
|
|
OpDefs.emplace_back(ChildOB);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// It may be useful to separate this logic (of handling operand
|
|
|
|
// bundles) out to a separate "policy" component if this gets crowded.
|
|
|
|
// Prepend the parent's deoptimization continuation to the newly
|
|
|
|
// inlined call's deoptimization continuation.
|
|
|
|
std::vector<Value *> MergedDeoptArgs;
|
|
|
|
MergedDeoptArgs.reserve(ParentDeopt.Inputs.size() +
|
|
|
|
ChildOB.Inputs.size());
|
|
|
|
|
|
|
|
MergedDeoptArgs.insert(MergedDeoptArgs.end(),
|
|
|
|
ParentDeopt.Inputs.begin(),
|
|
|
|
ParentDeopt.Inputs.end());
|
|
|
|
MergedDeoptArgs.insert(MergedDeoptArgs.end(), ChildOB.Inputs.begin(),
|
|
|
|
ChildOB.Inputs.end());
|
|
|
|
|
2015-12-08 11:50:32 +08:00
|
|
|
OpDefs.emplace_back("deopt", std::move(MergedDeoptArgs));
|
2015-11-18 14:23:38 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
Instruction *NewI = nullptr;
|
|
|
|
if (isa<CallInst>(I))
|
|
|
|
NewI = CallInst::Create(cast<CallInst>(I), OpDefs, I);
|
|
|
|
else
|
|
|
|
NewI = InvokeInst::Create(cast<InvokeInst>(I), OpDefs, I);
|
|
|
|
|
|
|
|
// Note: the RAUW does the appropriate fixup in VMap, so we need to do
|
|
|
|
// this even if the call returns void.
|
|
|
|
I->replaceAllUsesWith(NewI);
|
|
|
|
|
|
|
|
VH = nullptr;
|
|
|
|
I->eraseFromParent();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-07-13 02:29:36 +08:00
|
|
|
// Update the callgraph if requested.
|
2010-04-23 07:07:58 +08:00
|
|
|
if (IFI.CG)
|
2010-06-24 07:55:51 +08:00
|
|
|
UpdateCallGraphAfterInlining(CS, FirstNewBlock, VMap, IFI);
|
2011-07-09 02:01:31 +08:00
|
|
|
|
|
|
|
// Update inlined instructions' line number information.
|
|
|
|
fixupLineNumbers(Caller, FirstNewBlock, TheCall);
|
Add scoped-noalias metadata
This commit adds scoped noalias metadata. The primary motivations for this
feature are:
1. To preserve noalias function attribute information when inlining
2. To provide the ability to model block-scope C99 restrict pointers
Neither of these two abilities are added here, only the necessary
infrastructure. In fact, there should be no change to existing functionality,
only the addition of new features. The logic that converts noalias function
parameters into this metadata during inlining will come in a follow-up commit.
What is added here is the ability to generally specify noalias memory-access
sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA
nodes:
!scope0 = metadata !{ metadata !"scope of foo()" }
!scope1 = metadata !{ metadata !"scope 1", metadata !scope0 }
!scope2 = metadata !{ metadata !"scope 2", metadata !scope0 }
!scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 }
!scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 }
Loads and stores can be tagged with an alias-analysis scope, and also, with a
noalias tag for a specific scope:
... = load %ptr1, !alias.scope !{ !scope1 }
... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 }
When evaluating an aliasing query, if one of the instructions is associated
with an alias.scope id that is identical to the noalias scope associated with
the other instruction, or is a descendant (in the scope hierarchy) of the
noalias scope associated with the other instruction, then the two memory
accesses are assumed not to alias.
Note that is the first element of the scope metadata is a string, then it can
be combined accross functions and translation units. The string can be replaced
by a self-reference to create globally unqiue scope identifiers.
[Note: This overview is slightly stylized, since the metadata nodes really need
to just be numbers (!0 instead of !scope0), and the scope lists are also global
unnamed metadata.]
Existing noalias metadata in a callee is "cloned" for use by the inlined code.
This is necessary because the aliasing scopes are unique to each call site
(because of possible control dependencies on the aliasing properties). For
example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets
inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } --
now just because we know that a1 does not alias with b1 at the first call site,
and a2 does not alias with b2 at the second call site, we cannot let inlining
these functons have the metadata imply that a1 does not alias with b2.
llvm-svn: 213864
2014-07-24 22:25:39 +08:00
|
|
|
|
|
|
|
// Clone existing noalias metadata if necessary.
|
|
|
|
CloneAliasScopeMetadata(CS, VMap);
|
2014-07-25 23:50:08 +08:00
|
|
|
|
|
|
|
// Add noalias metadata if necessary.
|
[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
|
|
|
AddAliasScopeMetadata(CS, VMap, DL, CalleeAAR);
|
2014-09-07 20:44:26 +08:00
|
|
|
|
|
|
|
// FIXME: We could register any cloned assumptions instead of clearing the
|
|
|
|
// whole function's cache.
|
2015-01-04 20:03:27 +08:00
|
|
|
if (IFI.ACT)
|
|
|
|
IFI.ACT->getAssumptionCache(*Caller).clear();
|
2005-04-22 07:48:37 +08:00
|
|
|
}
|
2008-09-05 20:37:12 +08:00
|
|
|
|
2003-05-29 23:11:31 +08:00
|
|
|
// If there are any alloca instructions in the block that used to be the entry
|
|
|
|
// block for the callee, move them to the entry block of the caller. First
|
|
|
|
// calculate which instruction they should be inserted before. We insert the
|
|
|
|
// instructions at the end of the current alloca list.
|
2006-01-14 02:16:48 +08:00
|
|
|
{
|
2003-08-24 14:59:16 +08:00
|
|
|
BasicBlock::iterator InsertPoint = Caller->begin()->begin();
|
2004-02-04 10:51:48 +08:00
|
|
|
for (BasicBlock::iterator I = FirstNewBlock->begin(),
|
2009-08-27 11:51:50 +08:00
|
|
|
E = FirstNewBlock->end(); I != E; ) {
|
|
|
|
AllocaInst *AI = dyn_cast<AllocaInst>(I++);
|
2014-04-25 13:29:35 +08:00
|
|
|
if (!AI) continue;
|
2009-08-27 11:51:50 +08:00
|
|
|
|
|
|
|
// If the alloca is now dead, remove it. This often occurs due to code
|
|
|
|
// specialization.
|
|
|
|
if (AI->use_empty()) {
|
|
|
|
AI->eraseFromParent();
|
|
|
|
continue;
|
2006-09-14 03:23:57 +08:00
|
|
|
}
|
2009-08-27 11:51:50 +08:00
|
|
|
|
|
|
|
if (!isa<Constant>(AI->getArraySize()))
|
|
|
|
continue;
|
|
|
|
|
2010-12-06 15:43:04 +08:00
|
|
|
// Keep track of the static allocas that we inline into the caller.
|
2010-04-23 07:07:58 +08:00
|
|
|
IFI.StaticAllocas.push_back(AI);
|
2009-08-27 12:20:52 +08:00
|
|
|
|
2009-08-27 11:51:50 +08:00
|
|
|
// Scan for the block of allocas that we can move over, and move them
|
|
|
|
// all at once.
|
|
|
|
while (isa<AllocaInst>(I) &&
|
2009-08-27 12:20:52 +08:00
|
|
|
isa<Constant>(cast<AllocaInst>(I)->getArraySize())) {
|
2010-04-23 07:07:58 +08:00
|
|
|
IFI.StaticAllocas.push_back(cast<AllocaInst>(I));
|
2009-08-27 11:51:50 +08:00
|
|
|
++I;
|
2009-08-27 12:20:52 +08:00
|
|
|
}
|
2009-08-27 11:51:50 +08:00
|
|
|
|
|
|
|
// Transfer all of the allocas over in a block. Using splice means
|
|
|
|
// that the instructions aren't removed from the symbol table, then
|
|
|
|
// reinserted.
|
2015-10-13 10:39:05 +08:00
|
|
|
Caller->getEntryBlock().getInstList().splice(
|
|
|
|
InsertPoint, FirstNewBlock->getInstList(), AI->getIterator(), I);
|
2009-08-27 11:51:50 +08:00
|
|
|
}
|
2015-01-30 09:55:25 +08:00
|
|
|
// Move any dbg.declares describing the allocas into the entry basic block.
|
2015-01-31 03:37:48 +08:00
|
|
|
DIBuilder DIB(*Caller->getParent());
|
2015-01-31 03:42:59 +08:00
|
|
|
for (auto &AI : IFI.StaticAllocas)
|
|
|
|
replaceDbgDeclareForAlloca(AI, AI, DIB, /*Deref=*/false);
|
2003-08-24 14:59:16 +08:00
|
|
|
}
|
|
|
|
|
2014-05-16 04:11:28 +08:00
|
|
|
bool InlinedMustTailCalls = false;
|
|
|
|
if (InlinedFunctionInfo.ContainsCalls) {
|
2014-05-16 04:39:42 +08:00
|
|
|
CallInst::TailCallKind CallSiteTailKind = CallInst::TCK_None;
|
|
|
|
if (CallInst *CI = dyn_cast<CallInst>(TheCall))
|
|
|
|
CallSiteTailKind = CI->getTailCallKind();
|
|
|
|
|
2014-05-16 04:11:28 +08:00
|
|
|
for (Function::iterator BB = FirstNewBlock, E = Caller->end(); BB != E;
|
|
|
|
++BB) {
|
|
|
|
for (Instruction &I : *BB) {
|
|
|
|
CallInst *CI = dyn_cast<CallInst>(&I);
|
|
|
|
if (!CI)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// We need to reduce the strength of any inlined tail calls. For
|
|
|
|
// musttail, we have to avoid introducing potential unbounded stack
|
|
|
|
// growth. For example, if functions 'f' and 'g' are mutually recursive
|
|
|
|
// with musttail, we can inline 'g' into 'f' so long as we preserve
|
|
|
|
// musttail on the cloned call to 'f'. If either the inlined call site
|
|
|
|
// or the cloned call site is *not* musttail, the program already has
|
|
|
|
// one frame of stack growth, so it's safe to remove musttail. Here is
|
|
|
|
// a table of example transformations:
|
|
|
|
//
|
|
|
|
// f -> musttail g -> musttail f ==> f -> musttail f
|
|
|
|
// f -> musttail g -> tail f ==> f -> tail f
|
|
|
|
// f -> g -> musttail f ==> f -> f
|
|
|
|
// f -> g -> tail f ==> f -> f
|
|
|
|
CallInst::TailCallKind ChildTCK = CI->getTailCallKind();
|
|
|
|
ChildTCK = std::min(CallSiteTailKind, ChildTCK);
|
2014-11-04 10:02:14 +08:00
|
|
|
CI->setTailCallKind(ChildTCK);
|
2014-05-16 04:11:28 +08:00
|
|
|
InlinedMustTailCalls |= CI->isMustTailCall();
|
|
|
|
|
|
|
|
// Calls inlined through a 'nounwind' call site should be marked
|
|
|
|
// 'nounwind'.
|
|
|
|
if (MarkNoUnwind)
|
|
|
|
CI->setDoesNotThrow();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-05-22 13:22:10 +08:00
|
|
|
// Leave lifetime markers for the static alloca's, scoping them to the
|
|
|
|
// function we just inlined.
|
2012-02-25 10:56:01 +08:00
|
|
|
if (InsertLifetime && !IFI.StaticAllocas.empty()) {
|
2015-10-13 10:39:05 +08:00
|
|
|
IRBuilder<> builder(&FirstNewBlock->front());
|
2011-05-22 13:22:10 +08:00
|
|
|
for (unsigned ai = 0, ae = IFI.StaticAllocas.size(); ai != ae; ++ai) {
|
|
|
|
AllocaInst *AI = IFI.StaticAllocas[ai];
|
|
|
|
|
|
|
|
// If the alloca is already scoped to something smaller than the whole
|
|
|
|
// function then there's no need to add redundant, less accurate markers.
|
|
|
|
if (hasLifetimeMarkers(AI))
|
|
|
|
continue;
|
|
|
|
|
2012-11-13 15:15:32 +08:00
|
|
|
// Try to determine the size of the allocation.
|
2014-04-25 13:29:35 +08:00
|
|
|
ConstantInt *AllocaSize = nullptr;
|
2012-11-13 15:15:32 +08:00
|
|
|
if (ConstantInt *AIArraySize =
|
|
|
|
dyn_cast<ConstantInt>(AI->getArraySize())) {
|
2015-03-05 02:43:29 +08:00
|
|
|
auto &DL = Caller->getParent()->getDataLayout();
|
|
|
|
Type *AllocaType = AI->getAllocatedType();
|
|
|
|
uint64_t AllocaTypeSize = DL.getTypeAllocSize(AllocaType);
|
|
|
|
uint64_t AllocaArraySize = AIArraySize->getLimitedValue();
|
2015-04-21 00:11:05 +08:00
|
|
|
|
|
|
|
// Don't add markers for zero-sized allocas.
|
|
|
|
if (AllocaArraySize == 0)
|
|
|
|
continue;
|
|
|
|
|
2015-03-05 02:43:29 +08:00
|
|
|
// Check that array size doesn't saturate uint64_t and doesn't
|
|
|
|
// overflow when it's multiplied by type size.
|
|
|
|
if (AllocaArraySize != ~0ULL &&
|
|
|
|
UINT64_MAX / AllocaArraySize >= AllocaTypeSize) {
|
|
|
|
AllocaSize = ConstantInt::get(Type::getInt64Ty(AI->getContext()),
|
|
|
|
AllocaArraySize * AllocaTypeSize);
|
2012-11-13 15:15:32 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
builder.CreateLifetimeStart(AI, AllocaSize);
|
2014-05-16 05:10:46 +08:00
|
|
|
for (ReturnInst *RI : Returns) {
|
|
|
|
// Don't insert llvm.lifetime.end calls between a musttail call and a
|
|
|
|
// return. The return kills all local allocas.
|
2014-08-12 08:05:15 +08:00
|
|
|
if (InlinedMustTailCalls &&
|
|
|
|
RI->getParent()->getTerminatingMustTailCall())
|
2014-05-16 05:10:46 +08:00
|
|
|
continue;
|
2014-05-16 04:11:28 +08:00
|
|
|
IRBuilder<>(RI).CreateLifetimeEnd(AI, AllocaSize);
|
2014-05-16 05:10:46 +08:00
|
|
|
}
|
2011-05-22 13:22:10 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-01-14 03:34:14 +08:00
|
|
|
// If the inlined code contained dynamic alloca instructions, wrap the inlined
|
|
|
|
// code with llvm.stacksave/llvm.stackrestore intrinsics.
|
|
|
|
if (InlinedFunctionInfo.ContainsDynamicAllocas) {
|
|
|
|
Module *M = Caller->getParent();
|
|
|
|
// Get the two intrinsics we care about.
|
2009-10-17 13:39:39 +08:00
|
|
|
Function *StackSave = Intrinsic::getDeclaration(M, Intrinsic::stacksave);
|
|
|
|
Function *StackRestore=Intrinsic::getDeclaration(M,Intrinsic::stackrestore);
|
2006-07-13 02:29:36 +08:00
|
|
|
|
2006-01-14 03:34:14 +08:00
|
|
|
// Insert the llvm.stacksave.
|
2015-10-13 10:39:05 +08:00
|
|
|
CallInst *SavedPtr = IRBuilder<>(&*FirstNewBlock, FirstNewBlock->begin())
|
2015-05-19 06:13:54 +08:00
|
|
|
.CreateCall(StackSave, {}, "savedstack");
|
2008-09-05 20:37:12 +08:00
|
|
|
|
2006-01-14 03:34:14 +08:00
|
|
|
// Insert a call to llvm.stackrestore before any return instructions in the
|
|
|
|
// inlined function.
|
2014-05-16 05:10:46 +08:00
|
|
|
for (ReturnInst *RI : Returns) {
|
|
|
|
// Don't insert llvm.stackrestore calls between a musttail call and a
|
|
|
|
// return. The return will restore the stack pointer.
|
2014-08-12 08:05:15 +08:00
|
|
|
if (InlinedMustTailCalls && RI->getParent()->getTerminatingMustTailCall())
|
2014-05-16 05:10:46 +08:00
|
|
|
continue;
|
2014-05-16 04:11:28 +08:00
|
|
|
IRBuilder<>(RI).CreateCall(StackRestore, SavedPtr);
|
2014-05-16 05:10:46 +08:00
|
|
|
}
|
2005-05-06 14:47:52 +08:00
|
|
|
}
|
|
|
|
|
[IR] Reformulate LLVM's EH funclet IR
While we have successfully implemented a funclet-oriented EH scheme on
top of LLVM IR, our scheme has some notable deficiencies:
- catchendpad and cleanupendpad are necessary in the current design
but they are difficult to explain to others, even to seasoned LLVM
experts.
- catchendpad and cleanupendpad are optimization barriers. They cannot
be split and force all potentially throwing call-sites to be invokes.
This has a noticable effect on the quality of our code generation.
- catchpad, while similar in some aspects to invoke, is fairly awkward.
It is unsplittable, starts a funclet, and has control flow to other
funclets.
- The nesting relationship between funclets is currently a property of
control flow edges. Because of this, we are forced to carefully
analyze the flow graph to see if there might potentially exist illegal
nesting among funclets. While we have logic to clone funclets when
they are illegally nested, it would be nicer if we had a
representation which forbade them upfront.
Let's clean this up a bit by doing the following:
- Instead, make catchpad more like cleanuppad and landingpad: no control
flow, just a bunch of simple operands; catchpad would be splittable.
- Introduce catchswitch, a control flow instruction designed to model
the constraints of funclet oriented EH.
- Make funclet scoping explicit by having funclet instructions consume
the token produced by the funclet which contains them.
- Remove catchendpad and cleanupendpad. Their presence can be inferred
implicitly using coloring information.
N.B. The state numbering code for the CLR has been updated but the
veracity of it's output cannot be spoken for. An expert should take a
look to make sure the results are reasonable.
Reviewers: rnk, JosephTremoulet, andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D15139
llvm-svn: 255422
2015-12-12 13:38:55 +08:00
|
|
|
// Update the lexical scopes of the new funclets. Anything that had 'none' as
|
|
|
|
// its parent is now nested inside the callsite's EHPad.
|
|
|
|
if (CallSiteEHPad) {
|
|
|
|
for (Function::iterator BB = FirstNewBlock->getIterator(),
|
|
|
|
E = Caller->end();
|
|
|
|
BB != E; ++BB) {
|
|
|
|
Instruction *I = BB->getFirstNonPHI();
|
|
|
|
if (!I->isEHPad())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (auto *TPI = dyn_cast<TerminatePadInst>(I)) {
|
|
|
|
if (isa<ConstantTokenNone>(TPI->getParentPad()))
|
|
|
|
TPI->setParentPad(CallSiteEHPad);
|
|
|
|
} else if (auto *CatchSwitch = dyn_cast<CatchSwitchInst>(I)) {
|
|
|
|
if (isa<ConstantTokenNone>(CatchSwitch->getParentPad()))
|
|
|
|
CatchSwitch->setParentPad(CallSiteEHPad);
|
|
|
|
} else {
|
|
|
|
auto *FPI = cast<FuncletPadInst>(I);
|
|
|
|
if (isa<ConstantTokenNone>(FPI->getParentPad()))
|
|
|
|
FPI->setParentPad(CallSiteEHPad);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2004-02-04 10:51:48 +08:00
|
|
|
// If we are inlining for an invoke instruction, we must make sure to rewrite
|
2012-02-07 05:44:22 +08:00
|
|
|
// any call instructions into invoke instructions.
|
2015-08-01 01:58:14 +08:00
|
|
|
if (auto *II = dyn_cast<InvokeInst>(TheCall)) {
|
|
|
|
BasicBlock *UnwindDest = II->getUnwindDest();
|
|
|
|
Instruction *FirstNonPHI = UnwindDest->getFirstNonPHI();
|
|
|
|
if (isa<LandingPadInst>(FirstNonPHI)) {
|
2015-10-13 10:39:05 +08:00
|
|
|
HandleInlinedLandingPad(II, &*FirstNewBlock, InlinedFunctionInfo);
|
2015-08-01 01:58:14 +08:00
|
|
|
} else {
|
2015-10-13 10:39:05 +08:00
|
|
|
HandleInlinedEHPad(II, &*FirstNewBlock, InlinedFunctionInfo);
|
2015-08-01 01:58:14 +08:00
|
|
|
}
|
|
|
|
}
|
2004-02-04 10:51:48 +08:00
|
|
|
|
2014-05-16 04:11:28 +08:00
|
|
|
// Handle any inlined musttail call sites. In order for a new call site to be
|
|
|
|
// musttail, the source of the clone and the inlined call site must have been
|
|
|
|
// musttail. Therefore it's safe to return without merging control into the
|
|
|
|
// phi below.
|
|
|
|
if (InlinedMustTailCalls) {
|
|
|
|
// Check if we need to bitcast the result of any musttail calls.
|
|
|
|
Type *NewRetTy = Caller->getReturnType();
|
|
|
|
bool NeedBitCast = !TheCall->use_empty() && TheCall->getType() != NewRetTy;
|
|
|
|
|
|
|
|
// Handle the returns preceded by musttail calls separately.
|
|
|
|
SmallVector<ReturnInst *, 8> NormalReturns;
|
|
|
|
for (ReturnInst *RI : Returns) {
|
2014-08-12 08:05:15 +08:00
|
|
|
CallInst *ReturnedMustTail =
|
|
|
|
RI->getParent()->getTerminatingMustTailCall();
|
2014-05-16 04:11:28 +08:00
|
|
|
if (!ReturnedMustTail) {
|
|
|
|
NormalReturns.push_back(RI);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!NeedBitCast)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Delete the old return and any preceding bitcast.
|
|
|
|
BasicBlock *CurBB = RI->getParent();
|
|
|
|
auto *OldCast = dyn_cast_or_null<BitCastInst>(RI->getReturnValue());
|
|
|
|
RI->eraseFromParent();
|
|
|
|
if (OldCast)
|
|
|
|
OldCast->eraseFromParent();
|
|
|
|
|
|
|
|
// Insert a new bitcast and return with the right type.
|
|
|
|
IRBuilder<> Builder(CurBB);
|
|
|
|
Builder.CreateRet(Builder.CreateBitCast(ReturnedMustTail, NewRetTy));
|
|
|
|
}
|
|
|
|
|
|
|
|
// Leave behind the normal returns so we can merge control flow.
|
|
|
|
std::swap(Returns, NormalReturns);
|
|
|
|
}
|
|
|
|
|
2004-02-04 12:17:06 +08:00
|
|
|
// If we cloned in _exactly one_ basic block, and if that block ends in a
|
|
|
|
// return instruction, we splice the body of the inlined callee directly into
|
|
|
|
// the calling basic block.
|
|
|
|
if (Returns.size() == 1 && std::distance(FirstNewBlock, Caller->end()) == 1) {
|
|
|
|
// Move all of the instructions right before the call.
|
2015-10-13 10:39:05 +08:00
|
|
|
OrigBB->getInstList().splice(TheCall->getIterator(),
|
|
|
|
FirstNewBlock->getInstList(),
|
2004-02-04 12:17:06 +08:00
|
|
|
FirstNewBlock->begin(), FirstNewBlock->end());
|
|
|
|
// Remove the cloned basic block.
|
|
|
|
Caller->getBasicBlockList().pop_back();
|
2005-04-22 07:48:37 +08:00
|
|
|
|
2004-02-04 12:17:06 +08:00
|
|
|
// If the call site was an invoke instruction, add a branch to the normal
|
|
|
|
// destination.
|
2013-04-24 03:56:03 +08:00
|
|
|
if (InvokeInst *II = dyn_cast<InvokeInst>(TheCall)) {
|
|
|
|
BranchInst *NewBr = BranchInst::Create(II->getNormalDest(), TheCall);
|
|
|
|
NewBr->setDebugLoc(Returns[0]->getDebugLoc());
|
|
|
|
}
|
2004-02-04 12:17:06 +08:00
|
|
|
|
|
|
|
// If the return instruction returned a value, replace uses of the call with
|
|
|
|
// uses of the returned value.
|
2008-03-05 05:15:15 +08:00
|
|
|
if (!TheCall->use_empty()) {
|
|
|
|
ReturnInst *R = Returns[0];
|
2009-05-08 08:22:04 +08:00
|
|
|
if (TheCall == R->getReturnValue())
|
2009-07-31 07:03:37 +08:00
|
|
|
TheCall->replaceAllUsesWith(UndefValue::get(TheCall->getType()));
|
2009-05-08 08:22:04 +08:00
|
|
|
else
|
|
|
|
TheCall->replaceAllUsesWith(R->getReturnValue());
|
2008-03-05 05:15:15 +08:00
|
|
|
}
|
2004-02-04 12:17:06 +08:00
|
|
|
// Since we are now done with the Call/Invoke, we can delete it.
|
2008-06-22 06:08:46 +08:00
|
|
|
TheCall->eraseFromParent();
|
2004-02-04 12:17:06 +08:00
|
|
|
|
|
|
|
// Since we are now done with the return instruction, delete it also.
|
2008-06-22 06:08:46 +08:00
|
|
|
Returns[0]->eraseFromParent();
|
2004-02-04 12:17:06 +08:00
|
|
|
|
|
|
|
// We are now done with the inlining.
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Otherwise, we have the normal case, of more than one block to inline or
|
|
|
|
// multiple return sites.
|
|
|
|
|
2004-02-04 10:51:48 +08:00
|
|
|
// We want to clone the entire callee function into the hole between the
|
|
|
|
// "starter" and "ender" blocks. How we accomplish this depends on whether
|
|
|
|
// this is an invoke instruction or a call instruction.
|
|
|
|
BasicBlock *AfterCallBB;
|
2014-04-25 13:29:35 +08:00
|
|
|
BranchInst *CreatedBranchToNormalDest = nullptr;
|
2004-02-04 10:51:48 +08:00
|
|
|
if (InvokeInst *II = dyn_cast<InvokeInst>(TheCall)) {
|
2005-04-22 07:48:37 +08:00
|
|
|
|
2004-02-04 10:51:48 +08:00
|
|
|
// Add an unconditional branch to make this look like the CallInst case...
|
2013-04-24 03:56:03 +08:00
|
|
|
CreatedBranchToNormalDest = BranchInst::Create(II->getNormalDest(), TheCall);
|
2005-04-22 07:48:37 +08:00
|
|
|
|
2004-02-04 10:51:48 +08:00
|
|
|
// Split the basic block. This guarantees that no PHI nodes will have to be
|
|
|
|
// updated due to new incoming edges, and make the invoke case more
|
|
|
|
// symmetric to the call case.
|
2015-10-13 10:39:05 +08:00
|
|
|
AfterCallBB =
|
|
|
|
OrigBB->splitBasicBlock(CreatedBranchToNormalDest->getIterator(),
|
|
|
|
CalledFunc->getName() + ".exit");
|
2005-04-22 07:48:37 +08:00
|
|
|
|
2004-02-04 10:51:48 +08:00
|
|
|
} else { // It's a call
|
2004-02-04 12:17:06 +08:00
|
|
|
// If this is a call instruction, we need to split the basic block that
|
|
|
|
// the call lives in.
|
2004-02-04 10:51:48 +08:00
|
|
|
//
|
2015-10-13 10:39:05 +08:00
|
|
|
AfterCallBB = OrigBB->splitBasicBlock(TheCall->getIterator(),
|
|
|
|
CalledFunc->getName() + ".exit");
|
2004-02-04 10:51:48 +08:00
|
|
|
}
|
|
|
|
|
2004-02-04 12:17:06 +08:00
|
|
|
// Change the branch that used to go to AfterCallBB to branch to the first
|
|
|
|
// basic block of the inlined function.
|
|
|
|
//
|
|
|
|
TerminatorInst *Br = OrigBB->getTerminator();
|
2005-04-22 07:48:37 +08:00
|
|
|
assert(Br && Br->getOpcode() == Instruction::Br &&
|
2004-02-04 12:17:06 +08:00
|
|
|
"splitBasicBlock broken!");
|
2015-10-13 10:39:05 +08:00
|
|
|
Br->setOperand(0, &*FirstNewBlock);
|
2004-02-04 12:17:06 +08:00
|
|
|
|
|
|
|
// Now that the function is correct, make it a little bit nicer. In
|
|
|
|
// particular, move the basic blocks inserted from the end of the function
|
|
|
|
// into the space made by splitting the source basic block.
|
2015-10-13 10:39:05 +08:00
|
|
|
Caller->getBasicBlockList().splice(AfterCallBB->getIterator(),
|
|
|
|
Caller->getBasicBlockList(), FirstNewBlock,
|
|
|
|
Caller->end());
|
2004-02-04 12:17:06 +08:00
|
|
|
|
2004-02-04 10:51:48 +08:00
|
|
|
// Handle all of the return instructions that we just cloned in, and eliminate
|
|
|
|
// any users of the original call/invoke instruction.
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *RTy = CalledFunc->getReturnType();
|
2008-06-20 09:03:44 +08:00
|
|
|
|
2014-04-25 13:29:35 +08:00
|
|
|
PHINode *PHI = nullptr;
|
2008-07-23 08:34:11 +08:00
|
|
|
if (Returns.size() > 1) {
|
2004-02-04 10:51:48 +08:00
|
|
|
// The PHI node should go at the front of the new basic block to merge all
|
|
|
|
// possible incoming values.
|
|
|
|
if (!TheCall->use_empty()) {
|
2011-03-30 19:28:46 +08:00
|
|
|
PHI = PHINode::Create(RTy, Returns.size(), TheCall->getName(),
|
2015-10-13 10:39:05 +08:00
|
|
|
&AfterCallBB->front());
|
2008-07-23 08:34:11 +08:00
|
|
|
// Anything that used the result of the function call should now use the
|
|
|
|
// PHI node as their operand.
|
2008-09-05 20:37:12 +08:00
|
|
|
TheCall->replaceAllUsesWith(PHI);
|
2004-02-04 10:51:48 +08:00
|
|
|
}
|
2005-04-22 07:48:37 +08:00
|
|
|
|
2009-01-16 02:40:09 +08:00
|
|
|
// Loop over all of the return instructions adding entries to the PHI node
|
|
|
|
// as appropriate.
|
2008-07-23 08:34:11 +08:00
|
|
|
if (PHI) {
|
|
|
|
for (unsigned i = 0, e = Returns.size(); i != e; ++i) {
|
|
|
|
ReturnInst *RI = Returns[i];
|
|
|
|
assert(RI->getReturnValue()->getType() == PHI->getType() &&
|
|
|
|
"Ret value not consistent in function!");
|
|
|
|
PHI->addIncoming(RI->getReturnValue(), RI->getParent());
|
2004-02-04 10:51:48 +08:00
|
|
|
}
|
2008-03-08 04:06:16 +08:00
|
|
|
}
|
2005-04-22 07:48:37 +08:00
|
|
|
|
2009-01-17 07:08:50 +08:00
|
|
|
// Add a branch to the merge points and remove return instructions.
|
2013-05-01 06:45:10 +08:00
|
|
|
DebugLoc Loc;
|
2008-03-08 04:06:16 +08:00
|
|
|
for (unsigned i = 0, e = Returns.size(); i != e; ++i) {
|
2013-05-01 06:45:10 +08:00
|
|
|
ReturnInst *RI = Returns[i];
|
2013-05-01 01:08:16 +08:00
|
|
|
BranchInst* BI = BranchInst::Create(AfterCallBB, RI);
|
2013-05-01 06:45:10 +08:00
|
|
|
Loc = RI->getDebugLoc();
|
|
|
|
BI->setDebugLoc(Loc);
|
2008-03-11 02:34:00 +08:00
|
|
|
RI->eraseFromParent();
|
2004-02-04 10:51:48 +08:00
|
|
|
}
|
2013-05-01 01:08:16 +08:00
|
|
|
// We need to set the debug location to *somewhere* inside the
|
2013-05-01 01:33:32 +08:00
|
|
|
// inlined function. The line number may be nonsensical, but the
|
2013-05-01 01:08:16 +08:00
|
|
|
// instruction will at least be associated with the right
|
|
|
|
// function.
|
|
|
|
if (CreatedBranchToNormalDest)
|
2013-05-01 06:45:10 +08:00
|
|
|
CreatedBranchToNormalDest->setDebugLoc(Loc);
|
2008-03-11 02:34:00 +08:00
|
|
|
} else if (!Returns.empty()) {
|
|
|
|
// Otherwise, if there is exactly one return value, just replace anything
|
|
|
|
// using the return value of the call with the computed value.
|
2009-05-08 08:22:04 +08:00
|
|
|
if (!TheCall->use_empty()) {
|
|
|
|
if (TheCall == Returns[0]->getReturnValue())
|
2009-07-31 07:03:37 +08:00
|
|
|
TheCall->replaceAllUsesWith(UndefValue::get(TheCall->getType()));
|
2009-05-08 08:22:04 +08:00
|
|
|
else
|
|
|
|
TheCall->replaceAllUsesWith(Returns[0]->getReturnValue());
|
|
|
|
}
|
2008-09-05 20:37:12 +08:00
|
|
|
|
2011-06-23 17:09:15 +08:00
|
|
|
// Update PHI nodes that use the ReturnBB to use the AfterCallBB.
|
|
|
|
BasicBlock *ReturnBB = Returns[0]->getParent();
|
|
|
|
ReturnBB->replaceAllUsesWith(AfterCallBB);
|
|
|
|
|
2008-03-11 02:34:00 +08:00
|
|
|
// Splice the code from the return block into the block that it will return
|
|
|
|
// to, which contains the code that was after the call.
|
|
|
|
AfterCallBB->getInstList().splice(AfterCallBB->begin(),
|
|
|
|
ReturnBB->getInstList());
|
2008-09-05 20:37:12 +08:00
|
|
|
|
2013-04-24 03:56:03 +08:00
|
|
|
if (CreatedBranchToNormalDest)
|
|
|
|
CreatedBranchToNormalDest->setDebugLoc(Returns[0]->getDebugLoc());
|
|
|
|
|
2008-03-11 02:34:00 +08:00
|
|
|
// Delete the return instruction now and empty ReturnBB now.
|
|
|
|
Returns[0]->eraseFromParent();
|
|
|
|
ReturnBB->eraseFromParent();
|
2004-10-18 07:21:07 +08:00
|
|
|
} else if (!TheCall->use_empty()) {
|
|
|
|
// No returns, but something is using the return value of the call. Just
|
|
|
|
// nuke the result.
|
2009-07-31 07:03:37 +08:00
|
|
|
TheCall->replaceAllUsesWith(UndefValue::get(TheCall->getType()));
|
2004-02-04 10:51:48 +08:00
|
|
|
}
|
2005-04-22 07:48:37 +08:00
|
|
|
|
2004-02-04 10:51:48 +08:00
|
|
|
// Since we are now done with the Call/Invoke, we can delete it.
|
2004-10-18 07:21:07 +08:00
|
|
|
TheCall->eraseFromParent();
|
2003-05-29 23:11:31 +08:00
|
|
|
|
2014-05-16 04:11:28 +08:00
|
|
|
// If we inlined any musttail calls and the original return is now
|
|
|
|
// unreachable, delete it. It can only contain a bitcast and ret.
|
|
|
|
if (InlinedMustTailCalls && pred_begin(AfterCallBB) == pred_end(AfterCallBB))
|
|
|
|
AfterCallBB->eraseFromParent();
|
|
|
|
|
2003-08-24 12:06:56 +08:00
|
|
|
// We should always be able to fold the entry block of the function into the
|
|
|
|
// single predecessor of the block...
|
2004-04-16 13:17:59 +08:00
|
|
|
assert(cast<BranchInst>(Br)->isUnconditional() && "splitBasicBlock broken!");
|
2003-08-24 12:06:56 +08:00
|
|
|
BasicBlock *CalleeEntry = cast<BranchInst>(Br)->getSuccessor(0);
|
2004-02-04 12:17:06 +08:00
|
|
|
|
2004-04-16 13:17:59 +08:00
|
|
|
// Splice the code entry block into calling block, right before the
|
|
|
|
// unconditional branch.
|
2011-06-23 14:24:52 +08:00
|
|
|
CalleeEntry->replaceAllUsesWith(OrigBB); // Update PHI nodes
|
2015-10-13 10:39:05 +08:00
|
|
|
OrigBB->getInstList().splice(Br->getIterator(), CalleeEntry->getInstList());
|
2004-04-16 13:17:59 +08:00
|
|
|
|
|
|
|
// Remove the unconditional branch.
|
|
|
|
OrigBB->getInstList().erase(Br);
|
|
|
|
|
|
|
|
// Now we can remove the CalleeEntry block, which is now empty.
|
|
|
|
Caller->getBasicBlockList().erase(CalleeEntry);
|
2008-09-05 20:37:12 +08:00
|
|
|
|
2010-11-17 19:16:23 +08:00
|
|
|
// If we inserted a phi node, check to see if it has a single value (e.g. all
|
|
|
|
// the entries are the same or undef). If so, remove the PHI so it doesn't
|
|
|
|
// block other optimizations.
|
2012-01-31 09:01:16 +08:00
|
|
|
if (PHI) {
|
2015-03-05 02:43:29 +08:00
|
|
|
auto &DL = Caller->getParent()->getDataLayout();
|
2015-03-10 10:37:25 +08:00
|
|
|
if (Value *V = SimplifyInstruction(PHI, DL, nullptr, nullptr,
|
2015-01-04 20:03:27 +08:00
|
|
|
&IFI.ACT->getAssumptionCache(*Caller))) {
|
2010-11-17 19:16:23 +08:00
|
|
|
PHI->replaceAllUsesWith(V);
|
|
|
|
PHI->eraseFromParent();
|
|
|
|
}
|
2012-01-31 09:01:16 +08:00
|
|
|
}
|
2010-11-17 19:16:23 +08:00
|
|
|
|
2003-05-29 23:11:31 +08:00
|
|
|
return true;
|
|
|
|
}
|