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();
|
|
|
|
}
|
|
|
|
|
[Inliner/WinEH] Honor implicit nounwinds
Summary:
Funclet EH tables require that a given funclet have only one unwind
destination for exceptional exits. The verifier will therefore reject
e.g. two cleanuprets with different unwind dests for the same cleanup, or
two invokes exiting the same funclet but to different unwind dests.
Because catchswitch has no 'nounwind' variant, and because IR producers
are not *required* to annotate calls which will not unwind as 'nounwind',
it is legal to nest a call or an "unwind to caller" catchswitch within a
funclet pad that has an unwind destination other than caller; it is
undefined behavior for such a call or catchswitch to unwind.
Normally when inlining an invoke, calls in the inlined sequence are
rewritten to invokes that unwind to the callsite invoke's unwind
destination, and "unwind to caller" catchswitches in the inlined sequence
are rewritten to unwind to the callsite invoke's unwind destination.
However, if such a call or "unwind to caller" catchswitch is located in a
callee funclet that has another exceptional exit with an unwind
destination within the callee, applying the normal transformation would
give that callee funclet multiple unwind destinations for its exceptional
exits. There would be no way for EH table generation to determine which
is the "true" exit, and the verifier would reject the function
accordingly.
Add logic to the inliner to detect these cases and leave such calls and
"unwind to caller" catchswitches as calls and "unwind to caller"
catchswitches in the inlined sequence.
This fixes PR26147.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: alexcrichton, llvm-commits
Differential Revision: http://reviews.llvm.org/D16319
llvm-svn: 258273
2016-01-20 10:15:15 +08:00
|
|
|
/// Helper for getUnwindDestToken/getUnwindDestTokenHelper.
|
|
|
|
static Value *getParentPad(Value *EHPad) {
|
|
|
|
if (auto *FPI = dyn_cast<FuncletPadInst>(EHPad))
|
|
|
|
return FPI->getParentPad();
|
|
|
|
return cast<CatchSwitchInst>(EHPad)->getParentPad();
|
|
|
|
}
|
|
|
|
|
|
|
|
typedef DenseMap<Instruction *, Value *> UnwindDestMemoTy;
|
|
|
|
|
|
|
|
/// Helper for getUnwindDestToken that does the descendant-ward part of
|
|
|
|
/// the search.
|
|
|
|
static Value *getUnwindDestTokenHelper(Instruction *EHPad,
|
|
|
|
UnwindDestMemoTy &MemoMap) {
|
|
|
|
SmallVector<Instruction *, 8> Worklist(1, EHPad);
|
|
|
|
|
|
|
|
while (!Worklist.empty()) {
|
|
|
|
Instruction *CurrentPad = Worklist.pop_back_val();
|
|
|
|
// We only put pads on the worklist that aren't in the MemoMap. When
|
|
|
|
// we find an unwind dest for a pad we may update its ancestors, but
|
|
|
|
// the queue only ever contains uncles/great-uncles/etc. of CurrentPad,
|
|
|
|
// so they should never get updated while queued on the worklist.
|
|
|
|
assert(!MemoMap.count(CurrentPad));
|
|
|
|
Value *UnwindDestToken = nullptr;
|
|
|
|
if (auto *CatchSwitch = dyn_cast<CatchSwitchInst>(CurrentPad)) {
|
|
|
|
if (CatchSwitch->hasUnwindDest()) {
|
|
|
|
UnwindDestToken = CatchSwitch->getUnwindDest()->getFirstNonPHI();
|
|
|
|
} else {
|
|
|
|
// Catchswitch doesn't have a 'nounwind' variant, and one might be
|
|
|
|
// annotated as "unwinds to caller" when really it's nounwind (see
|
|
|
|
// e.g. SimplifyCFGOpt::SimplifyUnreachable), so we can't infer the
|
|
|
|
// parent's unwind dest from this. We can check its catchpads'
|
|
|
|
// descendants, since they might include a cleanuppad with an
|
|
|
|
// "unwinds to caller" cleanupret, which can be trusted.
|
|
|
|
for (auto HI = CatchSwitch->handler_begin(),
|
|
|
|
HE = CatchSwitch->handler_end();
|
|
|
|
HI != HE && !UnwindDestToken; ++HI) {
|
|
|
|
BasicBlock *HandlerBlock = *HI;
|
|
|
|
auto *CatchPad = cast<CatchPadInst>(HandlerBlock->getFirstNonPHI());
|
|
|
|
for (User *Child : CatchPad->users()) {
|
|
|
|
// Intentionally ignore invokes here -- since the catchswitch is
|
|
|
|
// marked "unwind to caller", it would be a verifier error if it
|
|
|
|
// contained an invoke which unwinds out of it, so any invoke we'd
|
|
|
|
// encounter must unwind to some child of the catch.
|
|
|
|
if (!isa<CleanupPadInst>(Child) && !isa<CatchSwitchInst>(Child))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
Instruction *ChildPad = cast<Instruction>(Child);
|
|
|
|
auto Memo = MemoMap.find(ChildPad);
|
|
|
|
if (Memo == MemoMap.end()) {
|
|
|
|
// Haven't figure out this child pad yet; queue it.
|
|
|
|
Worklist.push_back(ChildPad);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
// We've already checked this child, but might have found that
|
|
|
|
// it offers no proof either way.
|
|
|
|
Value *ChildUnwindDestToken = Memo->second;
|
|
|
|
if (!ChildUnwindDestToken)
|
|
|
|
continue;
|
|
|
|
// We already know the child's unwind dest, which can either
|
|
|
|
// be ConstantTokenNone to indicate unwind to caller, or can
|
|
|
|
// be another child of the catchpad. Only the former indicates
|
|
|
|
// the unwind dest of the catchswitch.
|
|
|
|
if (isa<ConstantTokenNone>(ChildUnwindDestToken)) {
|
|
|
|
UnwindDestToken = ChildUnwindDestToken;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
assert(getParentPad(ChildUnwindDestToken) == CatchPad);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
auto *CleanupPad = cast<CleanupPadInst>(CurrentPad);
|
|
|
|
for (User *U : CleanupPad->users()) {
|
|
|
|
if (auto *CleanupRet = dyn_cast<CleanupReturnInst>(U)) {
|
|
|
|
if (BasicBlock *RetUnwindDest = CleanupRet->getUnwindDest())
|
|
|
|
UnwindDestToken = RetUnwindDest->getFirstNonPHI();
|
|
|
|
else
|
|
|
|
UnwindDestToken = ConstantTokenNone::get(CleanupPad->getContext());
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
Value *ChildUnwindDestToken;
|
|
|
|
if (auto *Invoke = dyn_cast<InvokeInst>(U)) {
|
|
|
|
ChildUnwindDestToken = Invoke->getUnwindDest()->getFirstNonPHI();
|
|
|
|
} else if (isa<CleanupPadInst>(U) || isa<CatchSwitchInst>(U)) {
|
|
|
|
Instruction *ChildPad = cast<Instruction>(U);
|
|
|
|
auto Memo = MemoMap.find(ChildPad);
|
|
|
|
if (Memo == MemoMap.end()) {
|
|
|
|
// Haven't resolved this child yet; queue it and keep searching.
|
|
|
|
Worklist.push_back(ChildPad);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
// We've checked this child, but still need to ignore it if it
|
|
|
|
// had no proof either way.
|
|
|
|
ChildUnwindDestToken = Memo->second;
|
|
|
|
if (!ChildUnwindDestToken)
|
|
|
|
continue;
|
|
|
|
} else {
|
|
|
|
// Not a relevant user of the cleanuppad
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
// In a well-formed program, the child/invoke must either unwind to
|
|
|
|
// an(other) child of the cleanup, or exit the cleanup. In the
|
|
|
|
// first case, continue searching.
|
|
|
|
if (isa<Instruction>(ChildUnwindDestToken) &&
|
|
|
|
getParentPad(ChildUnwindDestToken) == CleanupPad)
|
|
|
|
continue;
|
|
|
|
UnwindDestToken = ChildUnwindDestToken;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
// If we haven't found an unwind dest for CurrentPad, we may have queued its
|
|
|
|
// children, so move on to the next in the worklist.
|
|
|
|
if (!UnwindDestToken)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Now we know that CurrentPad unwinds to UnwindDestToken. It also exits
|
|
|
|
// any ancestors of CurrentPad up to but not including UnwindDestToken's
|
|
|
|
// parent pad. Record this in the memo map, and check to see if the
|
|
|
|
// original EHPad being queried is one of the ones exited.
|
|
|
|
Value *UnwindParent;
|
|
|
|
if (auto *UnwindPad = dyn_cast<Instruction>(UnwindDestToken))
|
|
|
|
UnwindParent = getParentPad(UnwindPad);
|
|
|
|
else
|
|
|
|
UnwindParent = nullptr;
|
|
|
|
bool ExitedOriginalPad = false;
|
|
|
|
for (Instruction *ExitedPad = CurrentPad;
|
|
|
|
ExitedPad && ExitedPad != UnwindParent;
|
|
|
|
ExitedPad = dyn_cast<Instruction>(getParentPad(ExitedPad))) {
|
|
|
|
// Skip over catchpads since they just follow their catchswitches.
|
|
|
|
if (isa<CatchPadInst>(ExitedPad))
|
|
|
|
continue;
|
|
|
|
MemoMap[ExitedPad] = UnwindDestToken;
|
|
|
|
ExitedOriginalPad |= (ExitedPad == EHPad);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ExitedOriginalPad)
|
|
|
|
return UnwindDestToken;
|
|
|
|
|
|
|
|
// Continue the search.
|
|
|
|
}
|
|
|
|
|
|
|
|
// No definitive information is contained within this funclet.
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Given an EH pad, find where it unwinds. If it unwinds to an EH pad,
|
|
|
|
/// return that pad instruction. If it unwinds to caller, return
|
|
|
|
/// ConstantTokenNone. If it does not have a definitive unwind destination,
|
|
|
|
/// return nullptr.
|
|
|
|
///
|
|
|
|
/// This routine gets invoked for calls in funclets in inlinees when inlining
|
|
|
|
/// an invoke. Since many funclets don't have calls inside them, it's queried
|
|
|
|
/// on-demand rather than building a map of pads to unwind dests up front.
|
|
|
|
/// Determining a funclet's unwind dest may require recursively searching its
|
|
|
|
/// descendants, and also ancestors and cousins if the descendants don't provide
|
|
|
|
/// an answer. Since most funclets will have their unwind dest immediately
|
|
|
|
/// available as the unwind dest of a catchswitch or cleanupret, this routine
|
|
|
|
/// searches top-down from the given pad and then up. To avoid worst-case
|
|
|
|
/// quadratic run-time given that approach, it uses a memo map to avoid
|
|
|
|
/// re-processing funclet trees. The callers that rewrite the IR as they go
|
|
|
|
/// take advantage of this, for correctness, by checking/forcing rewritten
|
|
|
|
/// pads' entries to match the original callee view.
|
|
|
|
static Value *getUnwindDestToken(Instruction *EHPad,
|
|
|
|
UnwindDestMemoTy &MemoMap) {
|
|
|
|
// Catchpads unwind to the same place as their catchswitch;
|
|
|
|
// redirct any queries on catchpads so the code below can
|
|
|
|
// deal with just catchswitches and cleanuppads.
|
|
|
|
if (auto *CPI = dyn_cast<CatchPadInst>(EHPad))
|
|
|
|
EHPad = CPI->getCatchSwitch();
|
|
|
|
|
|
|
|
// Check if we've already determined the unwind dest for this pad.
|
|
|
|
auto Memo = MemoMap.find(EHPad);
|
|
|
|
if (Memo != MemoMap.end())
|
|
|
|
return Memo->second;
|
|
|
|
|
|
|
|
// Search EHPad and, if necessary, its descendants.
|
|
|
|
Value *UnwindDestToken = getUnwindDestTokenHelper(EHPad, MemoMap);
|
|
|
|
assert((UnwindDestToken == nullptr) != (MemoMap.count(EHPad) != 0));
|
|
|
|
if (UnwindDestToken)
|
|
|
|
return UnwindDestToken;
|
|
|
|
|
|
|
|
// No information is available for this EHPad from itself or any of its
|
|
|
|
// descendants. An unwind all the way out to a pad in the caller would
|
|
|
|
// need also to agree with the unwind dest of the parent funclet, so
|
|
|
|
// search up the chain to try to find a funclet with information. Put
|
|
|
|
// null entries in the memo map to avoid re-processing as we go up.
|
|
|
|
MemoMap[EHPad] = nullptr;
|
|
|
|
Instruction *LastUselessPad = EHPad;
|
|
|
|
Value *AncestorToken;
|
|
|
|
for (AncestorToken = getParentPad(EHPad);
|
|
|
|
auto *AncestorPad = dyn_cast<Instruction>(AncestorToken);
|
|
|
|
AncestorToken = getParentPad(AncestorToken)) {
|
|
|
|
// Skip over catchpads since they just follow their catchswitches.
|
|
|
|
if (isa<CatchPadInst>(AncestorPad))
|
|
|
|
continue;
|
|
|
|
assert(!MemoMap.count(AncestorPad) || MemoMap[AncestorPad]);
|
|
|
|
auto AncestorMemo = MemoMap.find(AncestorPad);
|
|
|
|
if (AncestorMemo == MemoMap.end()) {
|
|
|
|
UnwindDestToken = getUnwindDestTokenHelper(AncestorPad, MemoMap);
|
|
|
|
} else {
|
|
|
|
UnwindDestToken = AncestorMemo->second;
|
|
|
|
}
|
|
|
|
if (UnwindDestToken)
|
|
|
|
break;
|
|
|
|
LastUselessPad = AncestorPad;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Since the whole tree under LastUselessPad has no information, it all must
|
|
|
|
// match UnwindDestToken; record that to avoid repeating the search.
|
|
|
|
SmallVector<Instruction *, 8> Worklist(1, LastUselessPad);
|
|
|
|
while (!Worklist.empty()) {
|
|
|
|
Instruction *UselessPad = Worklist.pop_back_val();
|
|
|
|
assert(!MemoMap.count(UselessPad) || MemoMap[UselessPad] == nullptr);
|
|
|
|
MemoMap[UselessPad] = UnwindDestToken;
|
|
|
|
if (auto *CatchSwitch = dyn_cast<CatchSwitchInst>(UselessPad)) {
|
|
|
|
for (BasicBlock *HandlerBlock : CatchSwitch->handlers())
|
|
|
|
for (User *U : HandlerBlock->getFirstNonPHI()->users())
|
|
|
|
if (isa<CatchSwitchInst>(U) || isa<CleanupPadInst>(U))
|
|
|
|
Worklist.push_back(cast<Instruction>(U));
|
|
|
|
} else {
|
|
|
|
assert(isa<CleanupPadInst>(UselessPad));
|
|
|
|
for (User *U : UselessPad->users())
|
|
|
|
if (isa<CatchSwitchInst>(U) || isa<CleanupPadInst>(U))
|
|
|
|
Worklist.push_back(cast<Instruction>(U));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return UnwindDestToken;
|
|
|
|
}
|
|
|
|
|
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.
|
[Inliner/WinEH] Honor implicit nounwinds
Summary:
Funclet EH tables require that a given funclet have only one unwind
destination for exceptional exits. The verifier will therefore reject
e.g. two cleanuprets with different unwind dests for the same cleanup, or
two invokes exiting the same funclet but to different unwind dests.
Because catchswitch has no 'nounwind' variant, and because IR producers
are not *required* to annotate calls which will not unwind as 'nounwind',
it is legal to nest a call or an "unwind to caller" catchswitch within a
funclet pad that has an unwind destination other than caller; it is
undefined behavior for such a call or catchswitch to unwind.
Normally when inlining an invoke, calls in the inlined sequence are
rewritten to invokes that unwind to the callsite invoke's unwind
destination, and "unwind to caller" catchswitches in the inlined sequence
are rewritten to unwind to the callsite invoke's unwind destination.
However, if such a call or "unwind to caller" catchswitch is located in a
callee funclet that has another exceptional exit with an unwind
destination within the callee, applying the normal transformation would
give that callee funclet multiple unwind destinations for its exceptional
exits. There would be no way for EH table generation to determine which
is the "true" exit, and the verifier would reject the function
accordingly.
Add logic to the inliner to detect these cases and leave such calls and
"unwind to caller" catchswitches as calls and "unwind to caller"
catchswitches in the inlined sequence.
This fixes PR26147.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: alexcrichton, llvm-commits
Differential Revision: http://reviews.llvm.org/D16319
llvm-svn: 258273
2016-01-20 10:15:15 +08:00
|
|
|
static BasicBlock *HandleCallsInBlockInlinedThroughInvoke(
|
|
|
|
BasicBlock *BB, BasicBlock *UnwindEdge,
|
|
|
|
UnwindDestMemoTy *FuncletUnwindMap = nullptr) {
|
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
|
|
|
|
Introduce @llvm.experimental.deoptimize
Summary:
This intrinsic, together with deoptimization operand bundles, allow
frontends to express transfer of control and frame-local state from
one (typically more specialized, hence faster) version of a function
into another (typically more generic, hence slower) version.
In languages with a fully integrated managed runtime this intrinsic can
be used to implement "uncommon trap" like functionality. In unmanaged
languages like C and C++, this intrinsic can be used to represent the
slow paths of specialized functions.
Note: this change does not address how `@llvm.experimental_deoptimize`
is lowered. That will be done in a later change.
Reviewers: chandlerc, rnk, atrick, reames
Subscribers: llvm-commits, kmod, mjacob, maksfb, mcrosier, JosephTremoulet
Differential Revision: http://reviews.llvm.org/D17732
llvm-svn: 263281
2016-03-12 03:08:34 +08:00
|
|
|
// We do not need to (and in fact, cannot) convert possibly throwing calls
|
2016-03-31 08:18:46 +08:00
|
|
|
// to @llvm.experimental_deoptimize (resp. @llvm.experimental.guard) into
|
|
|
|
// invokes. The caller's "segment" of the deoptimization continuation
|
|
|
|
// attached to the newly inlined @llvm.experimental_deoptimize
|
|
|
|
// (resp. @llvm.experimental.guard) call should contain the exception
|
|
|
|
// handling logic, if any.
|
Introduce @llvm.experimental.deoptimize
Summary:
This intrinsic, together with deoptimization operand bundles, allow
frontends to express transfer of control and frame-local state from
one (typically more specialized, hence faster) version of a function
into another (typically more generic, hence slower) version.
In languages with a fully integrated managed runtime this intrinsic can
be used to implement "uncommon trap" like functionality. In unmanaged
languages like C and C++, this intrinsic can be used to represent the
slow paths of specialized functions.
Note: this change does not address how `@llvm.experimental_deoptimize`
is lowered. That will be done in a later change.
Reviewers: chandlerc, rnk, atrick, reames
Subscribers: llvm-commits, kmod, mjacob, maksfb, mcrosier, JosephTremoulet
Differential Revision: http://reviews.llvm.org/D17732
llvm-svn: 263281
2016-03-12 03:08:34 +08:00
|
|
|
if (auto *F = CI->getCalledFunction())
|
2016-03-31 08:18:46 +08:00
|
|
|
if (F->getIntrinsicID() == Intrinsic::experimental_deoptimize ||
|
|
|
|
F->getIntrinsicID() == Intrinsic::experimental_guard)
|
Introduce @llvm.experimental.deoptimize
Summary:
This intrinsic, together with deoptimization operand bundles, allow
frontends to express transfer of control and frame-local state from
one (typically more specialized, hence faster) version of a function
into another (typically more generic, hence slower) version.
In languages with a fully integrated managed runtime this intrinsic can
be used to implement "uncommon trap" like functionality. In unmanaged
languages like C and C++, this intrinsic can be used to represent the
slow paths of specialized functions.
Note: this change does not address how `@llvm.experimental_deoptimize`
is lowered. That will be done in a later change.
Reviewers: chandlerc, rnk, atrick, reames
Subscribers: llvm-commits, kmod, mjacob, maksfb, mcrosier, JosephTremoulet
Differential Revision: http://reviews.llvm.org/D17732
llvm-svn: 263281
2016-03-12 03:08:34 +08:00
|
|
|
continue;
|
|
|
|
|
[Inliner/WinEH] Honor implicit nounwinds
Summary:
Funclet EH tables require that a given funclet have only one unwind
destination for exceptional exits. The verifier will therefore reject
e.g. two cleanuprets with different unwind dests for the same cleanup, or
two invokes exiting the same funclet but to different unwind dests.
Because catchswitch has no 'nounwind' variant, and because IR producers
are not *required* to annotate calls which will not unwind as 'nounwind',
it is legal to nest a call or an "unwind to caller" catchswitch within a
funclet pad that has an unwind destination other than caller; it is
undefined behavior for such a call or catchswitch to unwind.
Normally when inlining an invoke, calls in the inlined sequence are
rewritten to invokes that unwind to the callsite invoke's unwind
destination, and "unwind to caller" catchswitches in the inlined sequence
are rewritten to unwind to the callsite invoke's unwind destination.
However, if such a call or "unwind to caller" catchswitch is located in a
callee funclet that has another exceptional exit with an unwind
destination within the callee, applying the normal transformation would
give that callee funclet multiple unwind destinations for its exceptional
exits. There would be no way for EH table generation to determine which
is the "true" exit, and the verifier would reject the function
accordingly.
Add logic to the inliner to detect these cases and leave such calls and
"unwind to caller" catchswitches as calls and "unwind to caller"
catchswitches in the inlined sequence.
This fixes PR26147.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: alexcrichton, llvm-commits
Differential Revision: http://reviews.llvm.org/D16319
llvm-svn: 258273
2016-01-20 10:15:15 +08:00
|
|
|
if (auto FuncletBundle = CI->getOperandBundle(LLVMContext::OB_funclet)) {
|
|
|
|
// This call is nested inside a funclet. If that funclet has an unwind
|
|
|
|
// destination within the inlinee, then unwinding out of this call would
|
|
|
|
// be UB. Rewriting this call to an invoke which targets the inlined
|
|
|
|
// invoke's unwind dest would give the call's parent funclet multiple
|
|
|
|
// unwind destinations, which is something that subsequent EH table
|
|
|
|
// generation can't handle and that the veirifer rejects. So when we
|
|
|
|
// see such a call, leave it as a call.
|
|
|
|
auto *FuncletPad = cast<Instruction>(FuncletBundle->Inputs[0]);
|
|
|
|
Value *UnwindDestToken =
|
|
|
|
getUnwindDestToken(FuncletPad, *FuncletUnwindMap);
|
|
|
|
if (UnwindDestToken && !isa<ConstantTokenNone>(UnwindDestToken))
|
|
|
|
continue;
|
|
|
|
#ifndef NDEBUG
|
|
|
|
Instruction *MemoKey;
|
|
|
|
if (auto *CatchPad = dyn_cast<CatchPadInst>(FuncletPad))
|
|
|
|
MemoKey = CatchPad->getCatchSwitch();
|
|
|
|
else
|
|
|
|
MemoKey = FuncletPad;
|
|
|
|
assert(FuncletUnwindMap->count(MemoKey) &&
|
|
|
|
(*FuncletUnwindMap)[MemoKey] == UnwindDestToken &&
|
|
|
|
"must get memoized to avoid confusing later searches");
|
|
|
|
#endif // NDEBUG
|
|
|
|
}
|
|
|
|
|
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.
|
[Inliner/WinEH] Honor implicit nounwinds
Summary:
Funclet EH tables require that a given funclet have only one unwind
destination for exceptional exits. The verifier will therefore reject
e.g. two cleanuprets with different unwind dests for the same cleanup, or
two invokes exiting the same funclet but to different unwind dests.
Because catchswitch has no 'nounwind' variant, and because IR producers
are not *required* to annotate calls which will not unwind as 'nounwind',
it is legal to nest a call or an "unwind to caller" catchswitch within a
funclet pad that has an unwind destination other than caller; it is
undefined behavior for such a call or catchswitch to unwind.
Normally when inlining an invoke, calls in the inlined sequence are
rewritten to invokes that unwind to the callsite invoke's unwind
destination, and "unwind to caller" catchswitches in the inlined sequence
are rewritten to unwind to the callsite invoke's unwind destination.
However, if such a call or "unwind to caller" catchswitch is located in a
callee funclet that has another exceptional exit with an unwind
destination within the callee, applying the normal transformation would
give that callee funclet multiple unwind destinations for its exceptional
exits. There would be no way for EH table generation to determine which
is the "true" exit, and the verifier would reject the function
accordingly.
Add logic to the inliner to detect these cases and leave such calls and
"unwind to caller" catchswitches as calls and "unwind to caller"
catchswitches in the inlined sequence.
This fixes PR26147.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: alexcrichton, llvm-commits
Differential Revision: http://reviews.llvm.org/D16319
llvm-svn: 258273
2016-01-20 10:15:15 +08:00
|
|
|
UnwindDestMemoTy FuncletUnwindMap;
|
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()) {
|
[Inliner/WinEH] Honor implicit nounwinds
Summary:
Funclet EH tables require that a given funclet have only one unwind
destination for exceptional exits. The verifier will therefore reject
e.g. two cleanuprets with different unwind dests for the same cleanup, or
two invokes exiting the same funclet but to different unwind dests.
Because catchswitch has no 'nounwind' variant, and because IR producers
are not *required* to annotate calls which will not unwind as 'nounwind',
it is legal to nest a call or an "unwind to caller" catchswitch within a
funclet pad that has an unwind destination other than caller; it is
undefined behavior for such a call or catchswitch to unwind.
Normally when inlining an invoke, calls in the inlined sequence are
rewritten to invokes that unwind to the callsite invoke's unwind
destination, and "unwind to caller" catchswitches in the inlined sequence
are rewritten to unwind to the callsite invoke's unwind destination.
However, if such a call or "unwind to caller" catchswitch is located in a
callee funclet that has another exceptional exit with an unwind
destination within the callee, applying the normal transformation would
give that callee funclet multiple unwind destinations for its exceptional
exits. There would be no way for EH table generation to determine which
is the "true" exit, and the verifier would reject the function
accordingly.
Add logic to the inliner to detect these cases and leave such calls and
"unwind to caller" catchswitches as calls and "unwind to caller"
catchswitches in the inlined sequence.
This fixes PR26147.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: alexcrichton, llvm-commits
Differential Revision: http://reviews.llvm.org/D16319
llvm-svn: 258273
2016-01-20 10:15:15 +08:00
|
|
|
auto *CleanupPad = CRI->getCleanupPad();
|
|
|
|
CleanupReturnInst::Create(CleanupPad, UnwindDest, CRI);
|
2015-08-01 01:58:14 +08:00
|
|
|
CRI->eraseFromParent();
|
2015-10-13 10:39:05 +08:00
|
|
|
UpdatePHINodes(&*BB);
|
[Inliner/WinEH] Honor implicit nounwinds
Summary:
Funclet EH tables require that a given funclet have only one unwind
destination for exceptional exits. The verifier will therefore reject
e.g. two cleanuprets with different unwind dests for the same cleanup, or
two invokes exiting the same funclet but to different unwind dests.
Because catchswitch has no 'nounwind' variant, and because IR producers
are not *required* to annotate calls which will not unwind as 'nounwind',
it is legal to nest a call or an "unwind to caller" catchswitch within a
funclet pad that has an unwind destination other than caller; it is
undefined behavior for such a call or catchswitch to unwind.
Normally when inlining an invoke, calls in the inlined sequence are
rewritten to invokes that unwind to the callsite invoke's unwind
destination, and "unwind to caller" catchswitches in the inlined sequence
are rewritten to unwind to the callsite invoke's unwind destination.
However, if such a call or "unwind to caller" catchswitch is located in a
callee funclet that has another exceptional exit with an unwind
destination within the callee, applying the normal transformation would
give that callee funclet multiple unwind destinations for its exceptional
exits. There would be no way for EH table generation to determine which
is the "true" exit, and the verifier would reject the function
accordingly.
Add logic to the inliner to detect these cases and leave such calls and
"unwind to caller" catchswitches as calls and "unwind to caller"
catchswitches in the inlined sequence.
This fixes PR26147.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: alexcrichton, llvm-commits
Differential Revision: http://reviews.llvm.org/D16319
llvm-svn: 258273
2016-01-20 10:15:15 +08:00
|
|
|
// Finding a cleanupret with an unwind destination would confuse
|
|
|
|
// subsequent calls to getUnwindDestToken, so map the cleanuppad
|
|
|
|
// to short-circuit any such calls and recognize this as an "unwind
|
|
|
|
// to caller" cleanup.
|
|
|
|
assert(!FuncletUnwindMap.count(CleanupPad) ||
|
|
|
|
isa<ConstantTokenNone>(FuncletUnwindMap[CleanupPad]));
|
|
|
|
FuncletUnwindMap[CleanupPad] =
|
|
|
|
ConstantTokenNone::get(Caller->getContext());
|
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;
|
2015-12-15 02:34:23 +08:00
|
|
|
if (auto *CatchSwitch = dyn_cast<CatchSwitchInst>(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
|
|
|
if (CatchSwitch->unwindsToCaller()) {
|
[Inliner/WinEH] Honor implicit nounwinds
Summary:
Funclet EH tables require that a given funclet have only one unwind
destination for exceptional exits. The verifier will therefore reject
e.g. two cleanuprets with different unwind dests for the same cleanup, or
two invokes exiting the same funclet but to different unwind dests.
Because catchswitch has no 'nounwind' variant, and because IR producers
are not *required* to annotate calls which will not unwind as 'nounwind',
it is legal to nest a call or an "unwind to caller" catchswitch within a
funclet pad that has an unwind destination other than caller; it is
undefined behavior for such a call or catchswitch to unwind.
Normally when inlining an invoke, calls in the inlined sequence are
rewritten to invokes that unwind to the callsite invoke's unwind
destination, and "unwind to caller" catchswitches in the inlined sequence
are rewritten to unwind to the callsite invoke's unwind destination.
However, if such a call or "unwind to caller" catchswitch is located in a
callee funclet that has another exceptional exit with an unwind
destination within the callee, applying the normal transformation would
give that callee funclet multiple unwind destinations for its exceptional
exits. There would be no way for EH table generation to determine which
is the "true" exit, and the verifier would reject the function
accordingly.
Add logic to the inliner to detect these cases and leave such calls and
"unwind to caller" catchswitches as calls and "unwind to caller"
catchswitches in the inlined sequence.
This fixes PR26147.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: alexcrichton, llvm-commits
Differential Revision: http://reviews.llvm.org/D16319
llvm-svn: 258273
2016-01-20 10:15:15 +08:00
|
|
|
Value *UnwindDestToken;
|
|
|
|
if (auto *ParentPad =
|
|
|
|
dyn_cast<Instruction>(CatchSwitch->getParentPad())) {
|
|
|
|
// This catchswitch is nested inside another funclet. If that
|
|
|
|
// funclet has an unwind destination within the inlinee, then
|
|
|
|
// unwinding out of this catchswitch would be UB. Rewriting this
|
|
|
|
// catchswitch to unwind to the inlined invoke's unwind dest would
|
|
|
|
// give the parent funclet multiple unwind destinations, which is
|
|
|
|
// something that subsequent EH table generation can't handle and
|
|
|
|
// that the veirifer rejects. So when we see such a call, leave it
|
|
|
|
// as "unwind to caller".
|
|
|
|
UnwindDestToken = getUnwindDestToken(ParentPad, FuncletUnwindMap);
|
|
|
|
if (UnwindDestToken && !isa<ConstantTokenNone>(UnwindDestToken))
|
|
|
|
continue;
|
|
|
|
} else {
|
|
|
|
// This catchswitch has no parent to inherit constraints from, and
|
|
|
|
// none of its descendants can have an unwind edge that exits it and
|
|
|
|
// targets another funclet in the inlinee. It may or may not have a
|
|
|
|
// descendant that definitively has an unwind to caller. In either
|
|
|
|
// case, we'll have to assume that any unwinds out of it may need to
|
|
|
|
// be routed to the caller, so treat it as though it has a definitive
|
|
|
|
// unwind to caller.
|
|
|
|
UnwindDestToken = ConstantTokenNone::get(Caller->getContext());
|
|
|
|
}
|
[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
|
|
|
auto *NewCatchSwitch = CatchSwitchInst::Create(
|
|
|
|
CatchSwitch->getParentPad(), UnwindDest,
|
|
|
|
CatchSwitch->getNumHandlers(), CatchSwitch->getName(),
|
|
|
|
CatchSwitch);
|
|
|
|
for (BasicBlock *PadBB : CatchSwitch->handlers())
|
|
|
|
NewCatchSwitch->addHandler(PadBB);
|
[Inliner/WinEH] Honor implicit nounwinds
Summary:
Funclet EH tables require that a given funclet have only one unwind
destination for exceptional exits. The verifier will therefore reject
e.g. two cleanuprets with different unwind dests for the same cleanup, or
two invokes exiting the same funclet but to different unwind dests.
Because catchswitch has no 'nounwind' variant, and because IR producers
are not *required* to annotate calls which will not unwind as 'nounwind',
it is legal to nest a call or an "unwind to caller" catchswitch within a
funclet pad that has an unwind destination other than caller; it is
undefined behavior for such a call or catchswitch to unwind.
Normally when inlining an invoke, calls in the inlined sequence are
rewritten to invokes that unwind to the callsite invoke's unwind
destination, and "unwind to caller" catchswitches in the inlined sequence
are rewritten to unwind to the callsite invoke's unwind destination.
However, if such a call or "unwind to caller" catchswitch is located in a
callee funclet that has another exceptional exit with an unwind
destination within the callee, applying the normal transformation would
give that callee funclet multiple unwind destinations for its exceptional
exits. There would be no way for EH table generation to determine which
is the "true" exit, and the verifier would reject the function
accordingly.
Add logic to the inliner to detect these cases and leave such calls and
"unwind to caller" catchswitches as calls and "unwind to caller"
catchswitches in the inlined sequence.
This fixes PR26147.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: alexcrichton, llvm-commits
Differential Revision: http://reviews.llvm.org/D16319
llvm-svn: 258273
2016-01-20 10:15:15 +08:00
|
|
|
// Propagate info for the old catchswitch over to the new one in
|
|
|
|
// the unwind map. This also serves to short-circuit any subsequent
|
|
|
|
// checks for the unwind dest of this catchswitch, which would get
|
|
|
|
// confused if they found the outer handler in the callee.
|
|
|
|
FuncletUnwindMap[NewCatchSwitch] = UnwindDestToken;
|
[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
|
|
|
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)
|
[Inliner/WinEH] Honor implicit nounwinds
Summary:
Funclet EH tables require that a given funclet have only one unwind
destination for exceptional exits. The verifier will therefore reject
e.g. two cleanuprets with different unwind dests for the same cleanup, or
two invokes exiting the same funclet but to different unwind dests.
Because catchswitch has no 'nounwind' variant, and because IR producers
are not *required* to annotate calls which will not unwind as 'nounwind',
it is legal to nest a call or an "unwind to caller" catchswitch within a
funclet pad that has an unwind destination other than caller; it is
undefined behavior for such a call or catchswitch to unwind.
Normally when inlining an invoke, calls in the inlined sequence are
rewritten to invokes that unwind to the callsite invoke's unwind
destination, and "unwind to caller" catchswitches in the inlined sequence
are rewritten to unwind to the callsite invoke's unwind destination.
However, if such a call or "unwind to caller" catchswitch is located in a
callee funclet that has another exceptional exit with an unwind
destination within the callee, applying the normal transformation would
give that callee funclet multiple unwind destinations for its exceptional
exits. There would be no way for EH table generation to determine which
is the "true" exit, and the verifier would reject the function
accordingly.
Add logic to the inliner to detect these cases and leave such calls and
"unwind to caller" catchswitches as calls and "unwind to caller"
catchswitches in the inlined sequence.
This fixes PR26147.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: alexcrichton, llvm-commits
Differential Revision: http://reviews.llvm.org/D16319
llvm-svn: 258273
2016-01-20 10:15:15 +08:00
|
|
|
if (BasicBlock *NewBB = HandleCallsInBlockInlinedThroughInvoke(
|
|
|
|
&*BB, UnwindDest, &FuncletUnwindMap))
|
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);
|
|
|
|
}
|
|
|
|
|
[Inliner] Preserve llvm.mem.parallel_loop_access metadata
When inlining a call site with llvm.mem.parallel_loop_access metadata, this
metadata needs to be propagated to all cloned memory-accessing instructions.
Otherwise, inlining parts of the loop body will invalidate the annotation.
With this functionality, we now vectorize the following as expected:
void Body(int *res, int *c, int *d, int *p, int i) {
res[i] = (p[i] == 0) ? res[i] : res[i] + d[i];
}
void Test(int *res, int *c, int *d, int *p, int n) {
int i;
#pragma clang loop vectorize(assume_safety)
for (i = 0; i < 1600; i++) {
Body(res, c, d, p, i);
}
}
llvm-svn: 267949
2016-04-29 07:00:04 +08:00
|
|
|
/// When inlining a call site that has !llvm.mem.parallel_loop_access metadata,
|
|
|
|
/// that metadata should be propagated to all memory-accessing cloned
|
|
|
|
/// instructions.
|
|
|
|
static void PropagateParallelLoopAccessMetadata(CallSite CS,
|
|
|
|
ValueToValueMapTy &VMap) {
|
|
|
|
MDNode *M =
|
|
|
|
CS.getInstruction()->getMetadata(LLVMContext::MD_mem_parallel_loop_access);
|
|
|
|
if (!M)
|
|
|
|
return;
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
if (MDNode *PM = NI->getMetadata(LLVMContext::MD_mem_parallel_loop_access)) {
|
|
|
|
M = MDNode::concatenate(PM, M);
|
|
|
|
NI->setMetadata(LLVMContext::MD_mem_parallel_loop_access, M);
|
|
|
|
} else if (NI->mayReadOrWriteMemory()) {
|
|
|
|
NI->setMetadata(LLVMContext::MD_mem_parallel_loop_access, M);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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.
|
|
|
|
|
2016-06-26 20:28:59 +08:00
|
|
|
for (const BasicBlock &I : *CalledFunc)
|
|
|
|
for (const Instruction &J : I) {
|
|
|
|
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);
|
2016-06-26 20:28:59 +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;
|
2016-06-26 20:28:59 +08:00
|
|
|
for (const MDNode *I : MD) {
|
2015-01-20 05:30:18 +08:00
|
|
|
DummyNodes.push_back(MDTuple::getTemporary(CalledFunc->getContext(), None));
|
2016-06-26 20:28:59 +08:00
|
|
|
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.
|
2016-06-26 20:28:59 +08:00
|
|
|
for (const MDNode *I : MD) {
|
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;
|
2016-06-26 20:28:59 +08:00
|
|
|
for (unsigned i = 0, ie = I->getNumOperands(); i != ie; ++i) {
|
|
|
|
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);
|
2016-06-26 20:28:59 +08:00
|
|
|
MDTuple *TempM = cast<MDTuple>(MDMap[I]);
|
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
|
|
|
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;
|
|
|
|
|
2016-01-14 06:16:48 +08:00
|
|
|
for (const Argument &Arg : CalledFunc->args())
|
|
|
|
if (Arg.hasNoAliasAttr() && !Arg.use_empty())
|
|
|
|
NoAliasArgs.push_back(&Arg);
|
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;
|
|
|
|
}
|
|
|
|
|
2016-01-14 05:39:26 +08:00
|
|
|
for (Value *Arg : ICS.args()) {
|
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.
|
2016-01-14 05:39:26 +08:00
|
|
|
if (IsArgMemOnlyCall && !Arg->getType()->isPointerTy())
|
2014-09-01 17:01:39 +08:00
|
|
|
continue;
|
|
|
|
|
2016-01-14 05:39:26 +08:00
|
|
|
PtrArgs.push_back(Arg);
|
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;
|
2016-01-14 05:39:26 +08:00
|
|
|
for (const Value *V : PtrArgs) {
|
2014-07-25 23:50:08 +08:00
|
|
|
SmallVector<Value *, 4> Objects;
|
2016-01-14 05:39:26 +08:00
|
|
|
GetUnderlyingObjects(const_cast<Value*>(V),
|
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
|
2016-06-12 23:39:02 +08:00
|
|
|
updateInlinedAtInfo(const DebugLoc &DL, DILocation *InlinedAtNode,
|
|
|
|
LLVMContext &Ctx,
|
2015-04-30 00:38:44 +08:00
|
|
|
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.
|
2016-06-24 12:05:21 +08:00
|
|
|
for (const DILocation *MD : reverse(InlinedAtLocations)) {
|
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) {
|
2016-06-13 01:30:47 +08:00
|
|
|
const 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();
|
2016-03-08 08:36:35 +08:00
|
|
|
|
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()) {
|
2015-12-16 05:27:27 +08:00
|
|
|
for (int i = 0, e = CS.getNumOperandBundles(); i != e; ++i) {
|
|
|
|
uint32_t Tag = CS.getOperandBundleAt(i).getTagID();
|
|
|
|
// ... but it knows how to inline through "deopt" operand bundles ...
|
|
|
|
if (Tag == LLVMContext::OB_deopt)
|
|
|
|
continue;
|
|
|
|
// ... and "funclet" operand bundles.
|
|
|
|
if (Tag == LLVMContext::OB_funclet)
|
|
|
|
continue;
|
|
|
|
|
2015-11-18 14:23:38 +08:00
|
|
|
return false;
|
2015-12-16 05:27:27 +08:00
|
|
|
}
|
2015-11-18 14:23:38 +08:00
|
|
|
}
|
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;
|
2015-12-16 05:27:27 +08:00
|
|
|
if (CallerPersonality) {
|
|
|
|
EHPersonality Personality = classifyEHPersonality(CallerPersonality);
|
[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
|
|
|
if (isFuncletEHPersonality(Personality)) {
|
2015-12-16 05:27:27 +08:00
|
|
|
Optional<OperandBundleUse> ParentFunclet =
|
|
|
|
CS.getOperandBundle(LLVMContext::OB_funclet);
|
|
|
|
if (ParentFunclet)
|
|
|
|
CallSiteEHPad = cast<FuncletPadInst>(ParentFunclet->Inputs.front());
|
[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
|
|
|
|
|
|
|
// 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) {
|
2015-12-16 05:27:27 +08:00
|
|
|
if (isa<CatchSwitchInst>(CalledBB.getFirstNonPHI()))
|
[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
|
|
|
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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-02-24 01:11:04 +08:00
|
|
|
// Determine if we are dealing with a call in an EHPad which does not unwind
|
|
|
|
// to caller.
|
|
|
|
bool EHPadForCallUnwindsLocally = false;
|
|
|
|
if (CallSiteEHPad && CS.isCall()) {
|
|
|
|
UnwindDestMemoTy FuncletUnwindMap;
|
|
|
|
Value *CallSiteUnwindDestToken =
|
|
|
|
getUnwindDestToken(CallSiteEHPad, FuncletUnwindMap);
|
|
|
|
|
|
|
|
EHPadForCallUnwindsLocally =
|
|
|
|
CallSiteUnwindDestToken &&
|
|
|
|
!isa<ConstantTokenNone>(CallSiteUnwindDestToken);
|
|
|
|
}
|
|
|
|
|
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",
|
2016-03-08 08:36:35 +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-12-16 05:27:27 +08:00
|
|
|
Optional<OperandBundleUse> ParentDeopt =
|
|
|
|
CS.getOperandBundle(LLVMContext::OB_deopt);
|
|
|
|
if (ParentDeopt) {
|
2015-11-18 14:23:38 +08:00
|
|
|
SmallVector<OperandBundleDef, 2> OpDefs;
|
|
|
|
|
|
|
|
for (auto &VH : InlinedFunctionInfo.OperandBundleCallSites) {
|
2015-12-20 06:40:28 +08:00
|
|
|
Instruction *I = dyn_cast_or_null<Instruction>(VH);
|
|
|
|
if (!I) continue; // instruction was DCE'd or RAUW'ed to undef
|
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;
|
2015-12-16 05:27:27 +08:00
|
|
|
MergedDeoptArgs.reserve(ParentDeopt->Inputs.size() +
|
2015-11-18 14:23:38 +08:00
|
|
|
ChildOB.Inputs.size());
|
|
|
|
|
|
|
|
MergedDeoptArgs.insert(MergedDeoptArgs.end(),
|
2015-12-16 05:27:27 +08:00
|
|
|
ParentDeopt->Inputs.begin(),
|
|
|
|
ParentDeopt->Inputs.end());
|
2015-11-18 14:23:38 +08:00
|
|
|
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
|
|
|
|
[Inliner] Preserve llvm.mem.parallel_loop_access metadata
When inlining a call site with llvm.mem.parallel_loop_access metadata, this
metadata needs to be propagated to all cloned memory-accessing instructions.
Otherwise, inlining parts of the loop body will invalidate the annotation.
With this functionality, we now vectorize the following as expected:
void Body(int *res, int *c, int *d, int *p, int i) {
res[i] = (p[i] == 0) ? res[i] : res[i] + d[i];
}
void Test(int *res, int *c, int *d, int *p, int n) {
int i;
#pragma clang loop vectorize(assume_safety)
for (i = 0; i < 1600; i++) {
Body(res, c, d, p, i);
}
}
llvm-svn: 267949
2016-04-29 07:00:04 +08:00
|
|
|
// Propagate llvm.mem.parallel_loop_access if necessary.
|
|
|
|
PropagateParallelLoopAccessMetadata(CS, VMap);
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
Introduce @llvm.experimental.deoptimize
Summary:
This intrinsic, together with deoptimization operand bundles, allow
frontends to express transfer of control and frame-local state from
one (typically more specialized, hence faster) version of a function
into another (typically more generic, hence slower) version.
In languages with a fully integrated managed runtime this intrinsic can
be used to implement "uncommon trap" like functionality. In unmanaged
languages like C and C++, this intrinsic can be used to represent the
slow paths of specialized functions.
Note: this change does not address how `@llvm.experimental_deoptimize`
is lowered. That will be done in a later change.
Reviewers: chandlerc, rnk, atrick, reames
Subscribers: llvm-commits, kmod, mjacob, maksfb, mcrosier, JosephTremoulet
Differential Revision: http://reviews.llvm.org/D17732
llvm-svn: 263281
2016-03-12 03:08:34 +08:00
|
|
|
bool InlinedMustTailCalls = false, InlinedDeoptimizeCalls = false;
|
2014-05-16 04:11:28 +08:00
|
|
|
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;
|
|
|
|
|
Introduce @llvm.experimental.deoptimize
Summary:
This intrinsic, together with deoptimization operand bundles, allow
frontends to express transfer of control and frame-local state from
one (typically more specialized, hence faster) version of a function
into another (typically more generic, hence slower) version.
In languages with a fully integrated managed runtime this intrinsic can
be used to implement "uncommon trap" like functionality. In unmanaged
languages like C and C++, this intrinsic can be used to represent the
slow paths of specialized functions.
Note: this change does not address how `@llvm.experimental_deoptimize`
is lowered. That will be done in a later change.
Reviewers: chandlerc, rnk, atrick, reames
Subscribers: llvm-commits, kmod, mjacob, maksfb, mcrosier, JosephTremoulet
Differential Revision: http://reviews.llvm.org/D17732
llvm-svn: 263281
2016-03-12 03:08:34 +08:00
|
|
|
if (Function *F = CI->getCalledFunction())
|
|
|
|
InlinedDeoptimizeCalls |=
|
|
|
|
F->getIntrinsicID() == Intrinsic::experimental_deoptimize;
|
|
|
|
|
2014-05-16 04:11:28 +08:00
|
|
|
// 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) {
|
2016-04-01 10:51:26 +08:00
|
|
|
// Don't insert llvm.lifetime.end calls between a musttail or deoptimize
|
|
|
|
// 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;
|
2016-04-01 10:51:26 +08:00
|
|
|
if (InlinedDeoptimizeCalls &&
|
|
|
|
RI->getParent()->getTerminatingDeoptimizeCall())
|
|
|
|
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) {
|
2016-04-01 10:51:30 +08:00
|
|
|
// Don't insert llvm.stackrestore calls between a musttail or deoptimize
|
|
|
|
// 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;
|
2016-04-01 10:51:30 +08:00
|
|
|
if (InlinedDeoptimizeCalls && RI->getParent()->getTerminatingDeoptimizeCall())
|
|
|
|
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
|
|
|
}
|
|
|
|
|
[Inliner/WinEH] Honor implicit nounwinds
Summary:
Funclet EH tables require that a given funclet have only one unwind
destination for exceptional exits. The verifier will therefore reject
e.g. two cleanuprets with different unwind dests for the same cleanup, or
two invokes exiting the same funclet but to different unwind dests.
Because catchswitch has no 'nounwind' variant, and because IR producers
are not *required* to annotate calls which will not unwind as 'nounwind',
it is legal to nest a call or an "unwind to caller" catchswitch within a
funclet pad that has an unwind destination other than caller; it is
undefined behavior for such a call or catchswitch to unwind.
Normally when inlining an invoke, calls in the inlined sequence are
rewritten to invokes that unwind to the callsite invoke's unwind
destination, and "unwind to caller" catchswitches in the inlined sequence
are rewritten to unwind to the callsite invoke's unwind destination.
However, if such a call or "unwind to caller" catchswitch is located in a
callee funclet that has another exceptional exit with an unwind
destination within the callee, applying the normal transformation would
give that callee funclet multiple unwind destinations for its exceptional
exits. There would be no way for EH table generation to determine which
is the "true" exit, and the verifier would reject the function
accordingly.
Add logic to the inliner to detect these cases and leave such calls and
"unwind to caller" catchswitches as calls and "unwind to caller"
catchswitches in the inlined sequence.
This fixes PR26147.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: alexcrichton, llvm-commits
Differential Revision: http://reviews.llvm.org/D16319
llvm-svn: 258273
2016-01-20 10:15:15 +08:00
|
|
|
// If we are inlining for an invoke instruction, we must make sure to rewrite
|
|
|
|
// any call instructions into invoke instructions. This is sensitive to which
|
|
|
|
// funclet pads were top-level in the inlinee, so must be done before
|
|
|
|
// rewriting the "parent pad" links.
|
|
|
|
if (auto *II = dyn_cast<InvokeInst>(TheCall)) {
|
|
|
|
BasicBlock *UnwindDest = II->getUnwindDest();
|
|
|
|
Instruction *FirstNonPHI = UnwindDest->getFirstNonPHI();
|
|
|
|
if (isa<LandingPadInst>(FirstNonPHI)) {
|
|
|
|
HandleInlinedLandingPad(II, &*FirstNewBlock, InlinedFunctionInfo);
|
|
|
|
} else {
|
|
|
|
HandleInlinedEHPad(II, &*FirstNewBlock, InlinedFunctionInfo);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-12-16 05:27:27 +08:00
|
|
|
// Update the lexical scopes of the new funclets and callsites.
|
|
|
|
// Anything that had 'none' as its parent is now nested inside the callsite's
|
|
|
|
// EHPad.
|
|
|
|
|
[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
|
|
|
if (CallSiteEHPad) {
|
|
|
|
for (Function::iterator BB = FirstNewBlock->getIterator(),
|
|
|
|
E = Caller->end();
|
|
|
|
BB != E; ++BB) {
|
2015-12-16 05:27:27 +08:00
|
|
|
// Add bundle operands to any top-level call sites.
|
|
|
|
SmallVector<OperandBundleDef, 1> OpBundles;
|
|
|
|
for (BasicBlock::iterator BBI = BB->begin(), E = BB->end(); BBI != E;) {
|
|
|
|
Instruction *I = &*BBI++;
|
|
|
|
CallSite CS(I);
|
|
|
|
if (!CS)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Skip call sites which are nounwind intrinsics.
|
|
|
|
auto *CalledFn =
|
|
|
|
dyn_cast<Function>(CS.getCalledValue()->stripPointerCasts());
|
|
|
|
if (CalledFn && CalledFn->isIntrinsic() && CS.doesNotThrow())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Skip call sites which already have a "funclet" bundle.
|
|
|
|
if (CS.getOperandBundle(LLVMContext::OB_funclet))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
CS.getOperandBundlesAsDefs(OpBundles);
|
|
|
|
OpBundles.emplace_back("funclet", CallSiteEHPad);
|
|
|
|
|
|
|
|
Instruction *NewInst;
|
|
|
|
if (CS.isCall())
|
|
|
|
NewInst = CallInst::Create(cast<CallInst>(I), OpBundles, I);
|
|
|
|
else
|
|
|
|
NewInst = InvokeInst::Create(cast<InvokeInst>(I), OpBundles, I);
|
|
|
|
NewInst->takeName(I);
|
|
|
|
I->replaceAllUsesWith(NewInst);
|
|
|
|
I->eraseFromParent();
|
|
|
|
|
|
|
|
OpBundles.clear();
|
|
|
|
}
|
|
|
|
|
2016-02-24 01:11:04 +08:00
|
|
|
// It is problematic if the inlinee has a cleanupret which unwinds to
|
|
|
|
// caller and we inline it into a call site which doesn't unwind but into
|
|
|
|
// an EH pad that does. Such an edge must be dynamically unreachable.
|
|
|
|
// As such, we replace the cleanupret with unreachable.
|
|
|
|
if (auto *CleanupRet = dyn_cast<CleanupReturnInst>(BB->getTerminator()))
|
|
|
|
if (CleanupRet->unwindsToCaller() && EHPadForCallUnwindsLocally)
|
2016-06-25 16:19:55 +08:00
|
|
|
changeToUnreachable(CleanupRet, /*UseLLVMTrap=*/false);
|
2016-02-24 01:11:04 +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;
|
|
|
|
|
2015-12-15 02:34:23 +08:00
|
|
|
if (auto *CatchSwitch = dyn_cast<CatchSwitchInst>(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
|
|
|
if (isa<ConstantTokenNone>(CatchSwitch->getParentPad()))
|
|
|
|
CatchSwitch->setParentPad(CallSiteEHPad);
|
|
|
|
} else {
|
|
|
|
auto *FPI = cast<FuncletPadInst>(I);
|
|
|
|
if (isa<ConstantTokenNone>(FPI->getParentPad()))
|
|
|
|
FPI->setParentPad(CallSiteEHPad);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Introduce @llvm.experimental.deoptimize
Summary:
This intrinsic, together with deoptimization operand bundles, allow
frontends to express transfer of control and frame-local state from
one (typically more specialized, hence faster) version of a function
into another (typically more generic, hence slower) version.
In languages with a fully integrated managed runtime this intrinsic can
be used to implement "uncommon trap" like functionality. In unmanaged
languages like C and C++, this intrinsic can be used to represent the
slow paths of specialized functions.
Note: this change does not address how `@llvm.experimental_deoptimize`
is lowered. That will be done in a later change.
Reviewers: chandlerc, rnk, atrick, reames
Subscribers: llvm-commits, kmod, mjacob, maksfb, mcrosier, JosephTremoulet
Differential Revision: http://reviews.llvm.org/D17732
llvm-svn: 263281
2016-03-12 03:08:34 +08:00
|
|
|
if (InlinedDeoptimizeCalls) {
|
|
|
|
// We need to at least remove the deoptimizing returns from the Return set,
|
|
|
|
// so that the control flow from those returns does not get merged into the
|
|
|
|
// caller (but terminate it instead). If the caller's return type does not
|
|
|
|
// match the callee's return type, we also need to change the return type of
|
|
|
|
// the intrinsic.
|
|
|
|
if (Caller->getReturnType() == TheCall->getType()) {
|
|
|
|
auto NewEnd = remove_if(Returns, [](ReturnInst *RI) {
|
|
|
|
return RI->getParent()->getTerminatingDeoptimizeCall() != nullptr;
|
|
|
|
});
|
|
|
|
Returns.erase(NewEnd, Returns.end());
|
|
|
|
} else {
|
|
|
|
SmallVector<ReturnInst *, 8> NormalReturns;
|
|
|
|
Function *NewDeoptIntrinsic = Intrinsic::getDeclaration(
|
|
|
|
Caller->getParent(), Intrinsic::experimental_deoptimize,
|
|
|
|
{Caller->getReturnType()});
|
|
|
|
|
|
|
|
for (ReturnInst *RI : Returns) {
|
|
|
|
CallInst *DeoptCall = RI->getParent()->getTerminatingDeoptimizeCall();
|
|
|
|
if (!DeoptCall) {
|
|
|
|
NormalReturns.push_back(RI);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2016-05-12 09:17:38 +08:00
|
|
|
// The calling convention on the deoptimize call itself may be bogus,
|
|
|
|
// since the code we're inlining may have undefined behavior (and may
|
|
|
|
// never actually execute at runtime); but all
|
|
|
|
// @llvm.experimental.deoptimize declarations have to have the same
|
|
|
|
// calling convention in a well-formed module.
|
|
|
|
auto CallingConv = DeoptCall->getCalledFunction()->getCallingConv();
|
|
|
|
NewDeoptIntrinsic->setCallingConv(CallingConv);
|
Introduce @llvm.experimental.deoptimize
Summary:
This intrinsic, together with deoptimization operand bundles, allow
frontends to express transfer of control and frame-local state from
one (typically more specialized, hence faster) version of a function
into another (typically more generic, hence slower) version.
In languages with a fully integrated managed runtime this intrinsic can
be used to implement "uncommon trap" like functionality. In unmanaged
languages like C and C++, this intrinsic can be used to represent the
slow paths of specialized functions.
Note: this change does not address how `@llvm.experimental_deoptimize`
is lowered. That will be done in a later change.
Reviewers: chandlerc, rnk, atrick, reames
Subscribers: llvm-commits, kmod, mjacob, maksfb, mcrosier, JosephTremoulet
Differential Revision: http://reviews.llvm.org/D17732
llvm-svn: 263281
2016-03-12 03:08:34 +08:00
|
|
|
auto *CurBB = RI->getParent();
|
|
|
|
RI->eraseFromParent();
|
|
|
|
|
|
|
|
SmallVector<Value *, 4> CallArgs(DeoptCall->arg_begin(),
|
|
|
|
DeoptCall->arg_end());
|
|
|
|
|
|
|
|
SmallVector<OperandBundleDef, 1> OpBundles;
|
|
|
|
DeoptCall->getOperandBundlesAsDefs(OpBundles);
|
|
|
|
DeoptCall->eraseFromParent();
|
|
|
|
assert(!OpBundles.empty() &&
|
|
|
|
"Expected at least the deopt operand bundle");
|
|
|
|
|
|
|
|
IRBuilder<> Builder(CurBB);
|
2016-04-09 08:22:59 +08:00
|
|
|
CallInst *NewDeoptCall =
|
Introduce @llvm.experimental.deoptimize
Summary:
This intrinsic, together with deoptimization operand bundles, allow
frontends to express transfer of control and frame-local state from
one (typically more specialized, hence faster) version of a function
into another (typically more generic, hence slower) version.
In languages with a fully integrated managed runtime this intrinsic can
be used to implement "uncommon trap" like functionality. In unmanaged
languages like C and C++, this intrinsic can be used to represent the
slow paths of specialized functions.
Note: this change does not address how `@llvm.experimental_deoptimize`
is lowered. That will be done in a later change.
Reviewers: chandlerc, rnk, atrick, reames
Subscribers: llvm-commits, kmod, mjacob, maksfb, mcrosier, JosephTremoulet
Differential Revision: http://reviews.llvm.org/D17732
llvm-svn: 263281
2016-03-12 03:08:34 +08:00
|
|
|
Builder.CreateCall(NewDeoptIntrinsic, CallArgs, OpBundles);
|
2016-04-09 08:22:59 +08:00
|
|
|
NewDeoptCall->setCallingConv(CallingConv);
|
Introduce @llvm.experimental.deoptimize
Summary:
This intrinsic, together with deoptimization operand bundles, allow
frontends to express transfer of control and frame-local state from
one (typically more specialized, hence faster) version of a function
into another (typically more generic, hence slower) version.
In languages with a fully integrated managed runtime this intrinsic can
be used to implement "uncommon trap" like functionality. In unmanaged
languages like C and C++, this intrinsic can be used to represent the
slow paths of specialized functions.
Note: this change does not address how `@llvm.experimental_deoptimize`
is lowered. That will be done in a later change.
Reviewers: chandlerc, rnk, atrick, reames
Subscribers: llvm-commits, kmod, mjacob, maksfb, mcrosier, JosephTremoulet
Differential Revision: http://reviews.llvm.org/D17732
llvm-svn: 263281
2016-03-12 03:08:34 +08:00
|
|
|
if (NewDeoptCall->getType()->isVoidTy())
|
|
|
|
Builder.CreateRetVoid();
|
|
|
|
else
|
|
|
|
Builder.CreateRet(NewDeoptCall);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Leave behind the normal returns so we can merge control flow.
|
|
|
|
std::swap(Returns, NormalReturns);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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.
|
2016-03-08 08:36:35 +08:00
|
|
|
if (InlinedMustTailCalls && pred_begin(AfterCallBB) == pred_end(AfterCallBB))
|
2014-05-16 04:11:28 +08:00
|
|
|
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;
|
|
|
|
}
|