2015-02-24 21:49:35 +01:00
|
|
|
//===-- WinEHPrepare - Prepare exception handling for code generation ---===//
|
|
|
|
//
|
2019-01-19 09:50:56 +01:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2015-02-24 21:49:35 +01:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This pass lowers LLVM IR exception handling into something closer to what the
|
2015-05-05 19:44:16 +02:00
|
|
|
// backend wants for functions using a personality function from a runtime
|
|
|
|
// provided by MSVC. Functions with other personality functions are left alone
|
|
|
|
// and may be prepared by other passes. In particular, all supported MSVC
|
|
|
|
// personality functions require cleanup code to be outlined, and the C++
|
|
|
|
// personality requires catch handler code to be outlined.
|
2015-02-24 21:49:35 +01:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-04 17:16:01 +01:00
|
|
|
#include "llvm/ADT/DenseMap.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 06:38:55 +01:00
|
|
|
#include "llvm/ADT/MapVector.h"
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-04 17:16:01 +01:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2020-06-06 16:48:17 +02:00
|
|
|
#include "llvm/ADT/Triple.h"
|
2015-08-11 03:15:26 +02:00
|
|
|
#include "llvm/Analysis/CFG.h"
|
2015-12-03 00:06:39 +01:00
|
|
|
#include "llvm/Analysis/EHPersonalities.h"
|
2015-12-29 10:24:39 +01:00
|
|
|
#include "llvm/CodeGen/MachineBasicBlock.h"
|
2017-06-06 13:49:48 +02:00
|
|
|
#include "llvm/CodeGen/Passes.h"
|
2015-03-31 00:58:10 +02:00
|
|
|
#include "llvm/CodeGen/WinEHFuncInfo.h"
|
2016-01-02 10:26:36 +01:00
|
|
|
#include "llvm/IR/Verifier.h"
|
Sink all InitializePasses.h includes
This file lists every pass in LLVM, and is included by Pass.h, which is
very popular. Every time we add, remove, or rename a pass in LLVM, it
caused lots of recompilation.
I found this fact by looking at this table, which is sorted by the
number of times a file was changed over the last 100,000 git commits
multiplied by the number of object files that depend on it in the
current checkout:
recompiles touches affected_files header
342380 95 3604 llvm/include/llvm/ADT/STLExtras.h
314730 234 1345 llvm/include/llvm/InitializePasses.h
307036 118 2602 llvm/include/llvm/ADT/APInt.h
213049 59 3611 llvm/include/llvm/Support/MathExtras.h
170422 47 3626 llvm/include/llvm/Support/Compiler.h
162225 45 3605 llvm/include/llvm/ADT/Optional.h
158319 63 2513 llvm/include/llvm/ADT/Triple.h
140322 39 3598 llvm/include/llvm/ADT/StringRef.h
137647 59 2333 llvm/include/llvm/Support/Error.h
131619 73 1803 llvm/include/llvm/Support/FileSystem.h
Before this change, touching InitializePasses.h would cause 1345 files
to recompile. After this change, touching it only causes 550 compiles in
an incremental rebuild.
Reviewers: bkramer, asbirlea, bollu, jdoerfert
Differential Revision: https://reviews.llvm.org/D70211
2019-11-13 22:15:01 +01:00
|
|
|
#include "llvm/InitializePasses.h"
|
2015-12-29 10:24:39 +01:00
|
|
|
#include "llvm/MC/MCSymbol.h"
|
2015-02-24 21:49:35 +01:00
|
|
|
#include "llvm/Pass.h"
|
2019-11-15 00:15:48 +01:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
2015-03-12 00:22:06 +01:00
|
|
|
#include "llvm/Support/Debug.h"
|
2015-03-23 19:57:17 +01:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2015-03-12 00:22:06 +01:00
|
|
|
#include "llvm/Transforms/Utils/BasicBlockUtils.h"
|
2015-02-24 21:49:35 +01:00
|
|
|
#include "llvm/Transforms/Utils/Cloning.h"
|
Sink all InitializePasses.h includes
This file lists every pass in LLVM, and is included by Pass.h, which is
very popular. Every time we add, remove, or rename a pass in LLVM, it
caused lots of recompilation.
I found this fact by looking at this table, which is sorted by the
number of times a file was changed over the last 100,000 git commits
multiplied by the number of object files that depend on it in the
current checkout:
recompiles touches affected_files header
342380 95 3604 llvm/include/llvm/ADT/STLExtras.h
314730 234 1345 llvm/include/llvm/InitializePasses.h
307036 118 2602 llvm/include/llvm/ADT/APInt.h
213049 59 3611 llvm/include/llvm/Support/MathExtras.h
170422 47 3626 llvm/include/llvm/Support/Compiler.h
162225 45 3605 llvm/include/llvm/ADT/Optional.h
158319 63 2513 llvm/include/llvm/ADT/Triple.h
140322 39 3598 llvm/include/llvm/ADT/StringRef.h
137647 59 2333 llvm/include/llvm/Support/Error.h
131619 73 1803 llvm/include/llvm/Support/FileSystem.h
Before this change, touching InitializePasses.h would cause 1345 files
to recompile. After this change, touching it only causes 550 compiles in
an incremental rebuild.
Reviewers: bkramer, asbirlea, bollu, jdoerfert
Differential Revision: https://reviews.llvm.org/D70211
2019-11-13 22:15:01 +01:00
|
|
|
#include "llvm/Transforms/Utils/Local.h"
|
2015-09-16 20:40:37 +02:00
|
|
|
#include "llvm/Transforms/Utils/SSAUpdater.h"
|
2015-02-24 21:49:35 +01:00
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
#define DEBUG_TYPE "winehprepare"
|
|
|
|
|
2015-09-16 20:40:37 +02:00
|
|
|
static cl::opt<bool> DisableDemotion(
|
|
|
|
"disable-demotion", cl::Hidden,
|
|
|
|
cl::desc(
|
[WebAssembly] Add Wasm personality and isScopedEHPersonality()
Summary:
- Add wasm personality function
- Re-categorize the existing `isFuncletEHPersonality()` function into
two different functions: `isFuncletEHPersonality()` and
`isScopedEHPersonality(). This becomes necessary as wasm EH uses scoped
EH instructions (catchswitch, catchpad/ret, and cleanuppad/ret) but not
outlined funclets.
- Changed some callsites of `isFuncletEHPersonality()` to
`isScopedEHPersonality()` if they are related to scoped EH IR-level
stuff.
Reviewers: majnemer, dschuff, rnk
Subscribers: jfb, sbc100, jgravelle-google, eraman, JDevlieghere, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D45559
llvm-svn: 332667
2018-05-17 22:52:03 +02:00
|
|
|
"Clone multicolor basic blocks but do not demote cross scopes"),
|
2015-09-16 20:40:37 +02:00
|
|
|
cl::init(false));
|
|
|
|
|
|
|
|
static cl::opt<bool> DisableCleanups(
|
|
|
|
"disable-cleanups", cl::Hidden,
|
|
|
|
cl::desc("Do not remove implausible terminators or other similar cleanups"),
|
|
|
|
cl::init(false));
|
|
|
|
|
2018-06-01 00:02:34 +02:00
|
|
|
static cl::opt<bool> DemoteCatchSwitchPHIOnlyOpt(
|
|
|
|
"demote-catchswitch-only", cl::Hidden,
|
|
|
|
cl::desc("Demote catchswitch BBs only (for wasm EH)"), cl::init(false));
|
|
|
|
|
2015-02-24 21:49:35 +01:00
|
|
|
namespace {
|
2018-07-30 21:41:25 +02:00
|
|
|
|
2015-02-24 21:49:35 +01:00
|
|
|
class WinEHPrepare : public FunctionPass {
|
|
|
|
public:
|
|
|
|
static char ID; // Pass identification, replacement for typeid.
|
2018-06-01 00:02:34 +02:00
|
|
|
WinEHPrepare(bool DemoteCatchSwitchPHIOnly = false)
|
|
|
|
: FunctionPass(ID), DemoteCatchSwitchPHIOnly(DemoteCatchSwitchPHIOnly) {}
|
2015-02-24 21:49:35 +01:00
|
|
|
|
|
|
|
bool runOnFunction(Function &Fn) override;
|
|
|
|
|
|
|
|
bool doFinalization(Module &M) override;
|
|
|
|
|
|
|
|
void getAnalysisUsage(AnalysisUsage &AU) const override;
|
|
|
|
|
2016-10-01 04:56:57 +02:00
|
|
|
StringRef getPassName() const override {
|
2015-02-24 21:49:35 +01:00
|
|
|
return "Windows exception handling preparation";
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
2015-08-13 16:30:10 +02:00
|
|
|
void insertPHIStores(PHINode *OriginalPHI, AllocaInst *SpillSlot);
|
|
|
|
void
|
|
|
|
insertPHIStore(BasicBlock *PredBlock, Value *PredVal, AllocaInst *SpillSlot,
|
|
|
|
SmallVectorImpl<std::pair<BasicBlock *, Value *>> &Worklist);
|
|
|
|
AllocaInst *insertPHILoads(PHINode *PN, Function &F);
|
|
|
|
void replaceUseWithLoad(Value *V, Use &U, AllocaInst *&SpillSlot,
|
|
|
|
DenseMap<BasicBlock *, Value *> &Loads, Function &F);
|
[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 06:38:55 +01:00
|
|
|
bool prepareExplicitEH(Function &F);
|
|
|
|
void colorFunclets(Function &F);
|
2015-11-09 20:59:02 +01:00
|
|
|
|
2018-06-01 00:02:34 +02:00
|
|
|
void demotePHIsOnFunclets(Function &F, bool DemoteCatchSwitchPHIOnly);
|
[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 06:38:55 +01:00
|
|
|
void cloneCommonBlocks(Function &F);
|
2015-12-15 22:27:27 +01:00
|
|
|
void removeImplausibleInstructions(Function &F);
|
2015-09-16 20:40:24 +02:00
|
|
|
void cleanupPreparedFunclets(Function &F);
|
|
|
|
void verifyPreparedFunclets(Function &F);
|
2015-08-11 03:15:26 +02:00
|
|
|
|
2018-06-01 00:02:34 +02:00
|
|
|
bool DemoteCatchSwitchPHIOnly;
|
|
|
|
|
2015-03-18 21:26:53 +01:00
|
|
|
// All fields are reset by runOnFunction.
|
2015-04-30 20:17:12 +02:00
|
|
|
EHPersonality Personality = EHPersonality::Unknown;
|
2015-08-11 03:15:26 +02:00
|
|
|
|
2017-04-11 00:27:50 +02:00
|
|
|
const DataLayout *DL = nullptr;
|
[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 06:38:55 +01:00
|
|
|
DenseMap<BasicBlock *, ColorVector> BlockColors;
|
|
|
|
MapVector<BasicBlock *, std::vector<BasicBlock *>> FuncletBlocks;
|
2015-02-24 21:49:35 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
} // end anonymous namespace
|
|
|
|
|
|
|
|
char WinEHPrepare::ID = 0;
|
2017-05-25 23:26:32 +02:00
|
|
|
INITIALIZE_PASS(WinEHPrepare, DEBUG_TYPE, "Prepare Windows exceptions",
|
2017-05-18 19:21:13 +02:00
|
|
|
false, false)
|
2015-02-24 21:49:35 +01:00
|
|
|
|
2018-06-01 00:02:34 +02:00
|
|
|
FunctionPass *llvm::createWinEHPass(bool DemoteCatchSwitchPHIOnly) {
|
|
|
|
return new WinEHPrepare(DemoteCatchSwitchPHIOnly);
|
|
|
|
}
|
2015-02-24 21:49:35 +01:00
|
|
|
|
|
|
|
bool WinEHPrepare::runOnFunction(Function &Fn) {
|
2015-08-11 03:15:26 +02:00
|
|
|
if (!Fn.hasPersonalityFn())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Classify the personality to see what kind of preparation we need.
|
|
|
|
Personality = classifyEHPersonality(Fn.getPersonalityFn());
|
|
|
|
|
[WebAssembly] Add Wasm personality and isScopedEHPersonality()
Summary:
- Add wasm personality function
- Re-categorize the existing `isFuncletEHPersonality()` function into
two different functions: `isFuncletEHPersonality()` and
`isScopedEHPersonality(). This becomes necessary as wasm EH uses scoped
EH instructions (catchswitch, catchpad/ret, and cleanuppad/ret) but not
outlined funclets.
- Changed some callsites of `isFuncletEHPersonality()` to
`isScopedEHPersonality()` if they are related to scoped EH IR-level
stuff.
Reviewers: majnemer, dschuff, rnk
Subscribers: jfb, sbc100, jgravelle-google, eraman, JDevlieghere, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D45559
llvm-svn: 332667
2018-05-17 22:52:03 +02:00
|
|
|
// Do nothing if this is not a scope-based personality.
|
|
|
|
if (!isScopedEHPersonality(Personality))
|
2015-08-11 03:15:26 +02:00
|
|
|
return false;
|
|
|
|
|
2017-04-11 00:27:50 +02:00
|
|
|
DL = &Fn.getParent()->getDataLayout();
|
[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 06:38:55 +01:00
|
|
|
return prepareExplicitEH(Fn);
|
2015-02-24 21:49:35 +01:00
|
|
|
}
|
|
|
|
|
2015-04-03 21:37:50 +02:00
|
|
|
bool WinEHPrepare::doFinalization(Module &M) { return false; }
|
2015-02-24 21:49:35 +01:00
|
|
|
|
2015-10-16 21:59:52 +02:00
|
|
|
void WinEHPrepare::getAnalysisUsage(AnalysisUsage &AU) const {}
|
2015-02-24 21:49:35 +01:00
|
|
|
|
2015-08-18 21:07:12 +02:00
|
|
|
static int addUnwindMapEntry(WinEHFuncInfo &FuncInfo, int ToState,
|
2015-10-10 02:04:29 +02:00
|
|
|
const BasicBlock *BB) {
|
2015-10-10 01:34:53 +02:00
|
|
|
CxxUnwindMapEntry UME;
|
2015-05-29 00:00:24 +02:00
|
|
|
UME.ToState = ToState;
|
2015-10-10 02:04:29 +02:00
|
|
|
UME.Cleanup = BB;
|
2015-10-10 01:34:53 +02:00
|
|
|
FuncInfo.CxxUnwindMap.push_back(UME);
|
2015-08-18 21:07:12 +02:00
|
|
|
return FuncInfo.getLastStateNumber();
|
|
|
|
}
|
|
|
|
|
|
|
|
static void addTryBlockMapEntry(WinEHFuncInfo &FuncInfo, int TryLow,
|
|
|
|
int TryHigh, int CatchHigh,
|
|
|
|
ArrayRef<const CatchPadInst *> Handlers) {
|
|
|
|
WinEHTryBlockMapEntry TBME;
|
|
|
|
TBME.TryLow = TryLow;
|
|
|
|
TBME.TryHigh = TryHigh;
|
|
|
|
TBME.CatchHigh = CatchHigh;
|
|
|
|
assert(TBME.TryLow <= TBME.TryHigh);
|
|
|
|
for (const CatchPadInst *CPI : Handlers) {
|
|
|
|
WinEHHandlerType HT;
|
|
|
|
Constant *TypeInfo = cast<Constant>(CPI->getArgOperand(0));
|
2015-09-16 22:16:27 +02:00
|
|
|
if (TypeInfo->isNullValue())
|
2015-08-18 21:07:12 +02:00
|
|
|
HT.TypeDescriptor = nullptr;
|
2015-09-16 22:16:27 +02:00
|
|
|
else
|
|
|
|
HT.TypeDescriptor = cast<GlobalVariable>(TypeInfo->stripPointerCasts());
|
|
|
|
HT.Adjectives = cast<ConstantInt>(CPI->getArgOperand(1))->getZExtValue();
|
2015-10-07 01:31:59 +02:00
|
|
|
HT.Handler = CPI->getParent();
|
2016-01-08 09:03:55 +01:00
|
|
|
if (auto *AI =
|
|
|
|
dyn_cast<AllocaInst>(CPI->getArgOperand(2)->stripPointerCasts()))
|
|
|
|
HT.CatchObj.Alloca = AI;
|
2015-09-16 22:16:27 +02:00
|
|
|
else
|
2016-01-08 09:03:55 +01:00
|
|
|
HT.CatchObj.Alloca = nullptr;
|
2015-08-18 21:07:12 +02:00
|
|
|
TBME.HandlerArray.push_back(HT);
|
|
|
|
}
|
|
|
|
FuncInfo.TryBlockMap.push_back(TBME);
|
|
|
|
}
|
|
|
|
|
[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 06:38:55 +01:00
|
|
|
static BasicBlock *getCleanupRetUnwindDest(const CleanupPadInst *CleanupPad) {
|
|
|
|
for (const User *U : CleanupPad->users())
|
|
|
|
if (const auto *CRI = dyn_cast<CleanupReturnInst>(U))
|
|
|
|
return CRI->getUnwindDest();
|
2015-08-18 21:07:12 +02:00
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
[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 06:38:55 +01:00
|
|
|
static void calculateStateNumbersForInvokes(const Function *Fn,
|
|
|
|
WinEHFuncInfo &FuncInfo) {
|
|
|
|
auto *F = const_cast<Function *>(Fn);
|
|
|
|
DenseMap<BasicBlock *, ColorVector> BlockColors = colorEHFunclets(*F);
|
|
|
|
for (BasicBlock &BB : *F) {
|
|
|
|
auto *II = dyn_cast<InvokeInst>(BB.getTerminator());
|
|
|
|
if (!II)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
auto &BBColors = BlockColors[&BB];
|
2015-12-23 04:59:04 +01:00
|
|
|
assert(BBColors.size() == 1 && "multi-color BB not removed by preparation");
|
[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 06:38:55 +01:00
|
|
|
BasicBlock *FuncletEntryBB = BBColors.front();
|
|
|
|
|
|
|
|
BasicBlock *FuncletUnwindDest;
|
|
|
|
auto *FuncletPad =
|
|
|
|
dyn_cast<FuncletPadInst>(FuncletEntryBB->getFirstNonPHI());
|
|
|
|
assert(FuncletPad || FuncletEntryBB == &Fn->getEntryBlock());
|
|
|
|
if (!FuncletPad)
|
|
|
|
FuncletUnwindDest = nullptr;
|
|
|
|
else if (auto *CatchPad = dyn_cast<CatchPadInst>(FuncletPad))
|
|
|
|
FuncletUnwindDest = CatchPad->getCatchSwitch()->getUnwindDest();
|
|
|
|
else if (auto *CleanupPad = dyn_cast<CleanupPadInst>(FuncletPad))
|
|
|
|
FuncletUnwindDest = getCleanupRetUnwindDest(CleanupPad);
|
|
|
|
else
|
|
|
|
llvm_unreachable("unexpected funclet pad!");
|
|
|
|
|
|
|
|
BasicBlock *InvokeUnwindDest = II->getUnwindDest();
|
|
|
|
int BaseState = -1;
|
|
|
|
if (FuncletUnwindDest == InvokeUnwindDest) {
|
|
|
|
auto BaseStateI = FuncInfo.FuncletBaseStateMap.find(FuncletPad);
|
|
|
|
if (BaseStateI != FuncInfo.FuncletBaseStateMap.end())
|
|
|
|
BaseState = BaseStateI->second;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (BaseState != -1) {
|
|
|
|
FuncInfo.InvokeStateMap[II] = BaseState;
|
|
|
|
} else {
|
|
|
|
Instruction *PadInst = InvokeUnwindDest->getFirstNonPHI();
|
|
|
|
assert(FuncInfo.EHPadStateMap.count(PadInst) && "EH Pad has no state!");
|
|
|
|
FuncInfo.InvokeStateMap[II] = FuncInfo.EHPadStateMap[PadInst];
|
|
|
|
}
|
2015-09-09 23:10:03 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-08-18 21:07:12 +02:00
|
|
|
// Given BB which ends in an unwind edge, return the EHPad that this BB belongs
|
|
|
|
// to. If the unwind edge came from an invoke, return null.
|
[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 06:38:55 +01:00
|
|
|
static const BasicBlock *getEHPadFromPredecessor(const BasicBlock *BB,
|
|
|
|
Value *ParentPad) {
|
2018-10-15 12:04:59 +02:00
|
|
|
const Instruction *TI = BB->getTerminator();
|
2015-08-18 21:07:12 +02:00
|
|
|
if (isa<InvokeInst>(TI))
|
|
|
|
return nullptr;
|
[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 06:38:55 +01:00
|
|
|
if (auto *CatchSwitch = dyn_cast<CatchSwitchInst>(TI)) {
|
|
|
|
if (CatchSwitch->getParentPad() != ParentPad)
|
|
|
|
return nullptr;
|
2015-08-18 21:07:12 +02:00
|
|
|
return BB;
|
[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 06:38:55 +01:00
|
|
|
}
|
|
|
|
assert(!TI->isEHPad() && "unexpected EHPad!");
|
|
|
|
auto *CleanupPad = cast<CleanupReturnInst>(TI)->getCleanupPad();
|
|
|
|
if (CleanupPad->getParentPad() != ParentPad)
|
|
|
|
return nullptr;
|
|
|
|
return CleanupPad->getParent();
|
2015-08-18 21:07:12 +02:00
|
|
|
}
|
|
|
|
|
2020-05-03 10:15:59 +02:00
|
|
|
// Starting from a EHPad, Backward walk through control-flow graph
|
|
|
|
// to produce two primary outputs:
|
|
|
|
// FuncInfo.EHPadStateMap[] and FuncInfo.CxxUnwindMap[]
|
[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 06:38:55 +01:00
|
|
|
static void calculateCXXStateNumbers(WinEHFuncInfo &FuncInfo,
|
|
|
|
const Instruction *FirstNonPHI,
|
|
|
|
int ParentState) {
|
|
|
|
const BasicBlock *BB = FirstNonPHI->getParent();
|
|
|
|
assert(BB->isEHPad() && "not a funclet!");
|
|
|
|
|
|
|
|
if (auto *CatchSwitch = dyn_cast<CatchSwitchInst>(FirstNonPHI)) {
|
|
|
|
assert(FuncInfo.EHPadStateMap.count(CatchSwitch) == 0 &&
|
|
|
|
"shouldn't revist catch funclets!");
|
2015-08-18 21:07:12 +02:00
|
|
|
|
|
|
|
SmallVector<const CatchPadInst *, 2> Handlers;
|
[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 06:38:55 +01:00
|
|
|
for (const BasicBlock *CatchPadBB : CatchSwitch->handlers()) {
|
|
|
|
auto *CatchPad = cast<CatchPadInst>(CatchPadBB->getFirstNonPHI());
|
|
|
|
Handlers.push_back(CatchPad);
|
|
|
|
}
|
2015-08-18 21:07:12 +02:00
|
|
|
int TryLow = addUnwindMapEntry(FuncInfo, ParentState, nullptr);
|
[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 06:38:55 +01:00
|
|
|
FuncInfo.EHPadStateMap[CatchSwitch] = TryLow;
|
|
|
|
for (const BasicBlock *PredBlock : predecessors(BB))
|
|
|
|
if ((PredBlock = getEHPadFromPredecessor(PredBlock,
|
|
|
|
CatchSwitch->getParentPad())))
|
|
|
|
calculateCXXStateNumbers(FuncInfo, PredBlock->getFirstNonPHI(),
|
|
|
|
TryLow);
|
2015-08-18 21:07:12 +02:00
|
|
|
int CatchLow = addUnwindMapEntry(FuncInfo, ParentState, nullptr);
|
2015-09-09 23:10:03 +02:00
|
|
|
|
|
|
|
// catchpads are separate funclets in C++ EH due to the way rethrow works.
|
2015-08-18 21:07:12 +02:00
|
|
|
int TryHigh = CatchLow - 1;
|
2020-05-16 07:03:43 +02:00
|
|
|
|
|
|
|
// MSVC FrameHandler3/4 on x64&Arm64 expect Catch Handlers in $tryMap$
|
|
|
|
// stored in pre-order (outer first, inner next), not post-order
|
|
|
|
// Add to map here. Fix the CatchHigh after children are processed
|
|
|
|
const Module *Mod = BB->getParent()->getParent();
|
|
|
|
bool IsPreOrder = Triple(Mod->getTargetTriple()).isArch64Bit();
|
|
|
|
if (IsPreOrder)
|
|
|
|
addTryBlockMapEntry(FuncInfo, TryLow, TryHigh, CatchLow, Handlers);
|
|
|
|
unsigned TBMEIdx = FuncInfo.TryBlockMap.size() - 1;
|
|
|
|
|
[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 06:38:55 +01:00
|
|
|
for (const auto *CatchPad : Handlers) {
|
|
|
|
FuncInfo.FuncletBaseStateMap[CatchPad] = CatchLow;
|
|
|
|
for (const User *U : CatchPad->users()) {
|
|
|
|
const auto *UserI = cast<Instruction>(U);
|
2016-02-23 08:18:15 +01:00
|
|
|
if (auto *InnerCatchSwitch = dyn_cast<CatchSwitchInst>(UserI)) {
|
|
|
|
BasicBlock *UnwindDest = InnerCatchSwitch->getUnwindDest();
|
|
|
|
if (!UnwindDest || UnwindDest == CatchSwitch->getUnwindDest())
|
2015-12-23 04:59:04 +01:00
|
|
|
calculateCXXStateNumbers(FuncInfo, UserI, CatchLow);
|
2016-02-23 08:18:15 +01:00
|
|
|
}
|
2016-02-12 22:10:16 +01:00
|
|
|
if (auto *InnerCleanupPad = dyn_cast<CleanupPadInst>(UserI)) {
|
|
|
|
BasicBlock *UnwindDest = getCleanupRetUnwindDest(InnerCleanupPad);
|
|
|
|
// If a nested cleanup pad reports a null unwind destination and the
|
|
|
|
// enclosing catch pad doesn't it must be post-dominated by an
|
|
|
|
// unreachable instruction.
|
|
|
|
if (!UnwindDest || UnwindDest == CatchSwitch->getUnwindDest())
|
2015-12-23 04:59:04 +01:00
|
|
|
calculateCXXStateNumbers(FuncInfo, UserI, CatchLow);
|
2016-02-12 22:10:16 +01: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 06:38:55 +01:00
|
|
|
}
|
|
|
|
}
|
2015-08-18 21:07:12 +02:00
|
|
|
int CatchHigh = FuncInfo.getLastStateNumber();
|
2020-05-16 07:03:43 +02:00
|
|
|
// Now child Catches are processed, update CatchHigh
|
|
|
|
if (IsPreOrder)
|
|
|
|
FuncInfo.TryBlockMap[TBMEIdx].CatchHigh = CatchHigh;
|
|
|
|
else // PostOrder
|
|
|
|
addTryBlockMapEntry(FuncInfo, TryLow, TryHigh, CatchHigh, Handlers);
|
|
|
|
|
2018-05-14 14:53:11 +02:00
|
|
|
LLVM_DEBUG(dbgs() << "TryLow[" << BB->getName() << "]: " << TryLow << '\n');
|
|
|
|
LLVM_DEBUG(dbgs() << "TryHigh[" << BB->getName() << "]: " << TryHigh
|
|
|
|
<< '\n');
|
|
|
|
LLVM_DEBUG(dbgs() << "CatchHigh[" << BB->getName() << "]: " << CatchHigh
|
|
|
|
<< '\n');
|
[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 06:38:55 +01:00
|
|
|
} else {
|
|
|
|
auto *CleanupPad = cast<CleanupPadInst>(FirstNonPHI);
|
|
|
|
|
|
|
|
// It's possible for a cleanup to be visited twice: it might have multiple
|
|
|
|
// cleanupret instructions.
|
|
|
|
if (FuncInfo.EHPadStateMap.count(CleanupPad))
|
2015-10-09 02:46:08 +02:00
|
|
|
return;
|
[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 06:38:55 +01:00
|
|
|
|
|
|
|
int CleanupState = addUnwindMapEntry(FuncInfo, ParentState, BB);
|
|
|
|
FuncInfo.EHPadStateMap[CleanupPad] = CleanupState;
|
2018-05-14 14:53:11 +02:00
|
|
|
LLVM_DEBUG(dbgs() << "Assigning state #" << CleanupState << " to BB "
|
|
|
|
<< BB->getName() << '\n');
|
[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 06:38:55 +01:00
|
|
|
for (const BasicBlock *PredBlock : predecessors(BB)) {
|
|
|
|
if ((PredBlock = getEHPadFromPredecessor(PredBlock,
|
|
|
|
CleanupPad->getParentPad()))) {
|
|
|
|
calculateCXXStateNumbers(FuncInfo, PredBlock->getFirstNonPHI(),
|
|
|
|
CleanupState);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
for (const User *U : CleanupPad->users()) {
|
|
|
|
const auto *UserI = cast<Instruction>(U);
|
|
|
|
if (UserI->isEHPad())
|
|
|
|
report_fatal_error("Cleanup funclets for the MSVC++ personality cannot "
|
|
|
|
"contain exceptional actions");
|
|
|
|
}
|
2015-09-09 23:10:03 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-10-01 23:38:24 +02:00
|
|
|
static int addSEHExcept(WinEHFuncInfo &FuncInfo, int ParentState,
|
|
|
|
const Function *Filter, const BasicBlock *Handler) {
|
2015-09-09 23:10:03 +02:00
|
|
|
SEHUnwindMapEntry Entry;
|
|
|
|
Entry.ToState = ParentState;
|
2015-10-01 23:38:24 +02:00
|
|
|
Entry.IsFinally = false;
|
2015-09-09 23:10:03 +02:00
|
|
|
Entry.Filter = Filter;
|
|
|
|
Entry.Handler = Handler;
|
|
|
|
FuncInfo.SEHUnwindMap.push_back(Entry);
|
|
|
|
return FuncInfo.SEHUnwindMap.size() - 1;
|
|
|
|
}
|
|
|
|
|
2015-10-01 23:38:24 +02:00
|
|
|
static int addSEHFinally(WinEHFuncInfo &FuncInfo, int ParentState,
|
|
|
|
const BasicBlock *Handler) {
|
|
|
|
SEHUnwindMapEntry Entry;
|
|
|
|
Entry.ToState = ParentState;
|
|
|
|
Entry.IsFinally = true;
|
|
|
|
Entry.Filter = nullptr;
|
|
|
|
Entry.Handler = Handler;
|
|
|
|
FuncInfo.SEHUnwindMap.push_back(Entry);
|
|
|
|
return FuncInfo.SEHUnwindMap.size() - 1;
|
|
|
|
}
|
|
|
|
|
2020-05-03 10:15:59 +02:00
|
|
|
// Starting from a EHPad, Backward walk through control-flow graph
|
|
|
|
// to produce two primary outputs:
|
|
|
|
// FuncInfo.EHPadStateMap[] and FuncInfo.SEHUnwindMap[]
|
[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 06:38:55 +01:00
|
|
|
static void calculateSEHStateNumbers(WinEHFuncInfo &FuncInfo,
|
|
|
|
const Instruction *FirstNonPHI,
|
|
|
|
int ParentState) {
|
|
|
|
const BasicBlock *BB = FirstNonPHI->getParent();
|
|
|
|
assert(BB->isEHPad() && "no a funclet!");
|
|
|
|
|
|
|
|
if (auto *CatchSwitch = dyn_cast<CatchSwitchInst>(FirstNonPHI)) {
|
|
|
|
assert(FuncInfo.EHPadStateMap.count(CatchSwitch) == 0 &&
|
|
|
|
"shouldn't revist catch funclets!");
|
2015-09-09 23:10:03 +02:00
|
|
|
|
|
|
|
// Extract the filter function and the __except basic block and create a
|
|
|
|
// state for them.
|
[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 06:38:55 +01:00
|
|
|
assert(CatchSwitch->getNumHandlers() == 1 &&
|
2015-09-09 23:10:03 +02:00
|
|
|
"SEH doesn't have multiple handlers per __try");
|
[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 06:38:55 +01:00
|
|
|
const auto *CatchPad =
|
|
|
|
cast<CatchPadInst>((*CatchSwitch->handler_begin())->getFirstNonPHI());
|
|
|
|
const BasicBlock *CatchPadBB = CatchPad->getParent();
|
2015-10-01 23:38:24 +02:00
|
|
|
const Constant *FilterOrNull =
|
[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 06:38:55 +01:00
|
|
|
cast<Constant>(CatchPad->getArgOperand(0)->stripPointerCasts());
|
2015-10-01 23:38:24 +02:00
|
|
|
const Function *Filter = dyn_cast<Function>(FilterOrNull);
|
|
|
|
assert((Filter || FilterOrNull->isNullValue()) &&
|
|
|
|
"unexpected filter value");
|
2015-10-07 01:31:59 +02:00
|
|
|
int TryState = addSEHExcept(FuncInfo, ParentState, Filter, CatchPadBB);
|
2015-09-09 23:10:03 +02:00
|
|
|
|
|
|
|
// Everything in the __try block uses TryState as its parent state.
|
[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 06:38:55 +01:00
|
|
|
FuncInfo.EHPadStateMap[CatchSwitch] = TryState;
|
2018-05-14 14:53:11 +02:00
|
|
|
LLVM_DEBUG(dbgs() << "Assigning state #" << TryState << " to BB "
|
|
|
|
<< CatchPadBB->getName() << '\n');
|
[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 06:38:55 +01:00
|
|
|
for (const BasicBlock *PredBlock : predecessors(BB))
|
|
|
|
if ((PredBlock = getEHPadFromPredecessor(PredBlock,
|
|
|
|
CatchSwitch->getParentPad())))
|
|
|
|
calculateSEHStateNumbers(FuncInfo, PredBlock->getFirstNonPHI(),
|
|
|
|
TryState);
|
2015-09-09 23:10:03 +02:00
|
|
|
|
|
|
|
// Everything in the __except block unwinds to ParentState, just like code
|
|
|
|
// outside the __try.
|
[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 06:38:55 +01:00
|
|
|
for (const User *U : CatchPad->users()) {
|
|
|
|
const auto *UserI = cast<Instruction>(U);
|
2016-02-23 08:18:15 +01:00
|
|
|
if (auto *InnerCatchSwitch = dyn_cast<CatchSwitchInst>(UserI)) {
|
|
|
|
BasicBlock *UnwindDest = InnerCatchSwitch->getUnwindDest();
|
|
|
|
if (!UnwindDest || UnwindDest == CatchSwitch->getUnwindDest())
|
2015-12-23 04:59:04 +01:00
|
|
|
calculateSEHStateNumbers(FuncInfo, UserI, ParentState);
|
2016-02-23 08:18:15 +01:00
|
|
|
}
|
2016-02-12 22:10:16 +01:00
|
|
|
if (auto *InnerCleanupPad = dyn_cast<CleanupPadInst>(UserI)) {
|
|
|
|
BasicBlock *UnwindDest = getCleanupRetUnwindDest(InnerCleanupPad);
|
|
|
|
// If a nested cleanup pad reports a null unwind destination and the
|
|
|
|
// enclosing catch pad doesn't it must be post-dominated by an
|
|
|
|
// unreachable instruction.
|
|
|
|
if (!UnwindDest || UnwindDest == CatchSwitch->getUnwindDest())
|
2015-12-23 04:59:04 +01:00
|
|
|
calculateSEHStateNumbers(FuncInfo, UserI, ParentState);
|
2016-02-12 22:10:16 +01: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 06:38:55 +01:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
auto *CleanupPad = cast<CleanupPadInst>(FirstNonPHI);
|
|
|
|
|
|
|
|
// It's possible for a cleanup to be visited twice: it might have multiple
|
|
|
|
// cleanupret instructions.
|
|
|
|
if (FuncInfo.EHPadStateMap.count(CleanupPad))
|
2015-10-09 02:46:08 +02:00
|
|
|
return;
|
[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 06:38:55 +01:00
|
|
|
|
|
|
|
int CleanupState = addSEHFinally(FuncInfo, ParentState, BB);
|
|
|
|
FuncInfo.EHPadStateMap[CleanupPad] = CleanupState;
|
2018-05-14 14:53:11 +02:00
|
|
|
LLVM_DEBUG(dbgs() << "Assigning state #" << CleanupState << " to BB "
|
|
|
|
<< BB->getName() << '\n');
|
[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 06:38:55 +01:00
|
|
|
for (const BasicBlock *PredBlock : predecessors(BB))
|
|
|
|
if ((PredBlock =
|
|
|
|
getEHPadFromPredecessor(PredBlock, CleanupPad->getParentPad())))
|
|
|
|
calculateSEHStateNumbers(FuncInfo, PredBlock->getFirstNonPHI(),
|
|
|
|
CleanupState);
|
|
|
|
for (const User *U : CleanupPad->users()) {
|
|
|
|
const auto *UserI = cast<Instruction>(U);
|
|
|
|
if (UserI->isEHPad())
|
|
|
|
report_fatal_error("Cleanup funclets for the SEH personality cannot "
|
|
|
|
"contain exceptional actions");
|
|
|
|
}
|
2015-08-18 21:07:12 +02: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 06:38:55 +01:00
|
|
|
static bool isTopLevelPadForMSVC(const Instruction *EHPad) {
|
|
|
|
if (auto *CatchSwitch = dyn_cast<CatchSwitchInst>(EHPad))
|
|
|
|
return isa<ConstantTokenNone>(CatchSwitch->getParentPad()) &&
|
|
|
|
CatchSwitch->unwindsToCaller();
|
|
|
|
if (auto *CleanupPad = dyn_cast<CleanupPadInst>(EHPad))
|
|
|
|
return isa<ConstantTokenNone>(CleanupPad->getParentPad()) &&
|
|
|
|
getCleanupRetUnwindDest(CleanupPad) == nullptr;
|
|
|
|
if (isa<CatchPadInst>(EHPad))
|
|
|
|
return false;
|
|
|
|
llvm_unreachable("unexpected EHPad!");
|
2015-09-09 23:10:03 +02:00
|
|
|
}
|
|
|
|
|
2015-09-17 00:14:46 +02:00
|
|
|
void llvm::calculateSEHStateNumbers(const Function *Fn,
|
2015-09-09 23:10:03 +02:00
|
|
|
WinEHFuncInfo &FuncInfo) {
|
|
|
|
// Don't compute state numbers twice.
|
|
|
|
if (!FuncInfo.SEHUnwindMap.empty())
|
|
|
|
return;
|
|
|
|
|
2015-09-17 00:14:46 +02:00
|
|
|
for (const BasicBlock &BB : *Fn) {
|
[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 06:38:55 +01:00
|
|
|
if (!BB.isEHPad())
|
|
|
|
continue;
|
|
|
|
const Instruction *FirstNonPHI = BB.getFirstNonPHI();
|
|
|
|
if (!isTopLevelPadForMSVC(FirstNonPHI))
|
2015-09-09 23:10:03 +02:00
|
|
|
continue;
|
[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 06:38:55 +01:00
|
|
|
::calculateSEHStateNumbers(FuncInfo, FirstNonPHI, -1);
|
2015-09-09 23:10:03 +02: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 06:38:55 +01:00
|
|
|
|
|
|
|
calculateStateNumbersForInvokes(Fn, FuncInfo);
|
2015-09-09 23:10:03 +02:00
|
|
|
}
|
|
|
|
|
2015-09-17 00:14:46 +02:00
|
|
|
void llvm::calculateWinCXXEHStateNumbers(const Function *Fn,
|
2015-05-29 00:00:24 +02:00
|
|
|
WinEHFuncInfo &FuncInfo) {
|
|
|
|
// Return if it's already been done.
|
2015-08-18 21:07:12 +02:00
|
|
|
if (!FuncInfo.EHPadStateMap.empty())
|
|
|
|
return;
|
|
|
|
|
2015-09-17 00:14:46 +02:00
|
|
|
for (const BasicBlock &BB : *Fn) {
|
2015-08-18 21:07:12 +02:00
|
|
|
if (!BB.isEHPad())
|
|
|
|
continue;
|
2015-09-03 11:09:43 +02:00
|
|
|
const Instruction *FirstNonPHI = BB.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 06:38:55 +01:00
|
|
|
if (!isTopLevelPadForMSVC(FirstNonPHI))
|
2015-08-18 21:07:12 +02:00
|
|
|
continue;
|
[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 06:38:55 +01:00
|
|
|
calculateCXXStateNumbers(FuncInfo, FirstNonPHI, -1);
|
2015-08-18 21:07:12 +02: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 06:38:55 +01:00
|
|
|
|
|
|
|
calculateStateNumbersForInvokes(Fn, FuncInfo);
|
2015-05-29 00:00:24 +02:00
|
|
|
}
|
2015-08-11 03:15:26 +02:00
|
|
|
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-04 17:16:01 +01:00
|
|
|
static int addClrEHHandler(WinEHFuncInfo &FuncInfo, int HandlerParentState,
|
|
|
|
int TryParentState, ClrHandlerType HandlerType,
|
|
|
|
uint32_t TypeToken, const BasicBlock *Handler) {
|
2015-10-06 22:30:33 +02:00
|
|
|
ClrEHUnwindMapEntry Entry;
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-04 17:16:01 +01:00
|
|
|
Entry.HandlerParentState = HandlerParentState;
|
|
|
|
Entry.TryParentState = TryParentState;
|
2015-10-06 22:30:33 +02:00
|
|
|
Entry.Handler = Handler;
|
|
|
|
Entry.HandlerType = HandlerType;
|
|
|
|
Entry.TypeToken = TypeToken;
|
|
|
|
FuncInfo.ClrEHUnwindMap.push_back(Entry);
|
|
|
|
return FuncInfo.ClrEHUnwindMap.size() - 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
void llvm::calculateClrEHStateNumbers(const Function *Fn,
|
|
|
|
WinEHFuncInfo &FuncInfo) {
|
|
|
|
// Return if it's already been done.
|
|
|
|
if (!FuncInfo.EHPadStateMap.empty())
|
|
|
|
return;
|
|
|
|
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-04 17:16:01 +01:00
|
|
|
// This numbering assigns one state number to each catchpad and cleanuppad.
|
|
|
|
// It also computes two tree-like relations over states:
|
|
|
|
// 1) Each state has a "HandlerParentState", which is the state of the next
|
|
|
|
// outer handler enclosing this state's handler (same as nearest ancestor
|
|
|
|
// per the ParentPad linkage on EH pads, but skipping over catchswitches).
|
|
|
|
// 2) Each state has a "TryParentState", which:
|
|
|
|
// a) for a catchpad that's not the last handler on its catchswitch, is
|
|
|
|
// the state of the next catchpad on that catchswitch
|
|
|
|
// b) for all other pads, is the state of the pad whose try region is the
|
|
|
|
// next outer try region enclosing this state's try region. The "try
|
|
|
|
// regions are not present as such in the IR, but will be inferred
|
|
|
|
// based on the placement of invokes and pads which reach each other
|
|
|
|
// by exceptional exits
|
|
|
|
// Catchswitches do not get their own states, but each gets mapped to the
|
|
|
|
// state of its first catchpad.
|
|
|
|
|
|
|
|
// Step one: walk down from outermost to innermost funclets, assigning each
|
|
|
|
// catchpad and cleanuppad a state number. Add an entry to the
|
|
|
|
// ClrEHUnwindMap for each state, recording its HandlerParentState and
|
|
|
|
// handler attributes. Record the TryParentState as well for each catchpad
|
|
|
|
// that's not the last on its catchswitch, but initialize all other entries'
|
|
|
|
// TryParentStates to a sentinel -1 value that the next pass will update.
|
|
|
|
|
|
|
|
// Seed a worklist with pads that have no parent.
|
2015-10-06 22:30:33 +02:00
|
|
|
SmallVector<std::pair<const Instruction *, int>, 8> Worklist;
|
|
|
|
for (const BasicBlock &BB : *Fn) {
|
|
|
|
const Instruction *FirstNonPHI = BB.getFirstNonPHI();
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-04 17:16:01 +01:00
|
|
|
const Value *ParentPad;
|
|
|
|
if (const auto *CPI = dyn_cast<CleanupPadInst>(FirstNonPHI))
|
|
|
|
ParentPad = CPI->getParentPad();
|
|
|
|
else if (const auto *CSI = dyn_cast<CatchSwitchInst>(FirstNonPHI))
|
|
|
|
ParentPad = CSI->getParentPad();
|
|
|
|
else
|
2015-10-06 22:30:33 +02:00
|
|
|
continue;
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-04 17:16:01 +01:00
|
|
|
if (isa<ConstantTokenNone>(ParentPad))
|
|
|
|
Worklist.emplace_back(FirstNonPHI, -1);
|
2015-10-06 22:30:33 +02:00
|
|
|
}
|
|
|
|
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-04 17:16:01 +01:00
|
|
|
// Use the worklist to visit all pads, from outer to inner. Record
|
|
|
|
// HandlerParentState for all pads. Record TryParentState only for catchpads
|
|
|
|
// that aren't the last on their catchswitch (setting all other entries'
|
|
|
|
// TryParentStates to an initial value of -1). This loop is also responsible
|
|
|
|
// for setting the EHPadStateMap entry for all catchpads, cleanuppads, and
|
|
|
|
// catchswitches.
|
2015-10-06 22:30:33 +02:00
|
|
|
while (!Worklist.empty()) {
|
|
|
|
const Instruction *Pad;
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-04 17:16:01 +01:00
|
|
|
int HandlerParentState;
|
|
|
|
std::tie(Pad, HandlerParentState) = Worklist.pop_back_val();
|
|
|
|
|
|
|
|
if (const auto *Cleanup = dyn_cast<CleanupPadInst>(Pad)) {
|
|
|
|
// Create the entry for this cleanup with the appropriate handler
|
2016-11-20 14:47:59 +01:00
|
|
|
// properties. Finally and fault handlers are distinguished by arity.
|
2015-10-06 22:30:33 +02:00
|
|
|
ClrHandlerType HandlerType =
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-04 17:16:01 +01:00
|
|
|
(Cleanup->getNumArgOperands() ? ClrHandlerType::Fault
|
|
|
|
: ClrHandlerType::Finally);
|
|
|
|
int CleanupState = addClrEHHandler(FuncInfo, HandlerParentState, -1,
|
|
|
|
HandlerType, 0, Pad->getParent());
|
|
|
|
// Queue any child EH pads on the worklist.
|
|
|
|
for (const User *U : Cleanup->users())
|
|
|
|
if (const auto *I = dyn_cast<Instruction>(U))
|
|
|
|
if (I->isEHPad())
|
|
|
|
Worklist.emplace_back(I, CleanupState);
|
|
|
|
// Remember this pad's state.
|
|
|
|
FuncInfo.EHPadStateMap[Cleanup] = CleanupState;
|
|
|
|
} else {
|
|
|
|
// Walk the handlers of this catchswitch in reverse order since all but
|
|
|
|
// the last need to set the following one as its TryParentState.
|
|
|
|
const auto *CatchSwitch = cast<CatchSwitchInst>(Pad);
|
|
|
|
int CatchState = -1, FollowerState = -1;
|
|
|
|
SmallVector<const BasicBlock *, 4> CatchBlocks(CatchSwitch->handlers());
|
|
|
|
for (auto CBI = CatchBlocks.rbegin(), CBE = CatchBlocks.rend();
|
|
|
|
CBI != CBE; ++CBI, FollowerState = CatchState) {
|
|
|
|
const BasicBlock *CatchBlock = *CBI;
|
|
|
|
// Create the entry for this catch with the appropriate handler
|
|
|
|
// properties.
|
|
|
|
const auto *Catch = cast<CatchPadInst>(CatchBlock->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 06:38:55 +01:00
|
|
|
uint32_t TypeToken = static_cast<uint32_t>(
|
|
|
|
cast<ConstantInt>(Catch->getArgOperand(0))->getZExtValue());
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-04 17:16:01 +01:00
|
|
|
CatchState =
|
|
|
|
addClrEHHandler(FuncInfo, HandlerParentState, FollowerState,
|
|
|
|
ClrHandlerType::Catch, TypeToken, CatchBlock);
|
|
|
|
// Queue any child EH pads on the worklist.
|
|
|
|
for (const User *U : Catch->users())
|
|
|
|
if (const auto *I = dyn_cast<Instruction>(U))
|
|
|
|
if (I->isEHPad())
|
|
|
|
Worklist.emplace_back(I, CatchState);
|
|
|
|
// Remember this catch's state.
|
|
|
|
FuncInfo.EHPadStateMap[Catch] = CatchState;
|
[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 06:38:55 +01:00
|
|
|
}
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-04 17:16:01 +01:00
|
|
|
// Associate the catchswitch with the state of its first catch.
|
|
|
|
assert(CatchSwitch->getNumHandlers());
|
|
|
|
FuncInfo.EHPadStateMap[CatchSwitch] = CatchState;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Step two: record the TryParentState of each state. For cleanuppads that
|
|
|
|
// don't have cleanuprets, we may need to infer this from their child pads,
|
|
|
|
// so visit pads in descendant-most to ancestor-most order.
|
|
|
|
for (auto Entry = FuncInfo.ClrEHUnwindMap.rbegin(),
|
|
|
|
End = FuncInfo.ClrEHUnwindMap.rend();
|
|
|
|
Entry != End; ++Entry) {
|
|
|
|
const Instruction *Pad =
|
|
|
|
Entry->Handler.get<const BasicBlock *>()->getFirstNonPHI();
|
|
|
|
// For most pads, the TryParentState is the state associated with the
|
|
|
|
// unwind dest of exceptional exits from it.
|
|
|
|
const BasicBlock *UnwindDest;
|
|
|
|
if (const auto *Catch = dyn_cast<CatchPadInst>(Pad)) {
|
|
|
|
// If a catch is not the last in its catchswitch, its TryParentState is
|
|
|
|
// the state associated with the next catch in the switch, even though
|
|
|
|
// that's not the unwind dest of exceptions escaping the catch. Those
|
|
|
|
// cases were already assigned a TryParentState in the first pass, so
|
|
|
|
// skip them.
|
|
|
|
if (Entry->TryParentState != -1)
|
|
|
|
continue;
|
|
|
|
// Otherwise, get the unwind dest from the catchswitch.
|
|
|
|
UnwindDest = Catch->getCatchSwitch()->getUnwindDest();
|
|
|
|
} else {
|
|
|
|
const auto *Cleanup = cast<CleanupPadInst>(Pad);
|
|
|
|
UnwindDest = nullptr;
|
|
|
|
for (const User *U : Cleanup->users()) {
|
|
|
|
if (auto *CleanupRet = dyn_cast<CleanupReturnInst>(U)) {
|
|
|
|
// Common and unambiguous case -- cleanupret indicates cleanup's
|
|
|
|
// unwind dest.
|
|
|
|
UnwindDest = CleanupRet->getUnwindDest();
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Get an unwind dest for the user
|
|
|
|
const BasicBlock *UserUnwindDest = nullptr;
|
|
|
|
if (auto *Invoke = dyn_cast<InvokeInst>(U)) {
|
|
|
|
UserUnwindDest = Invoke->getUnwindDest();
|
|
|
|
} else if (auto *CatchSwitch = dyn_cast<CatchSwitchInst>(U)) {
|
|
|
|
UserUnwindDest = CatchSwitch->getUnwindDest();
|
|
|
|
} else if (auto *ChildCleanup = dyn_cast<CleanupPadInst>(U)) {
|
|
|
|
int UserState = FuncInfo.EHPadStateMap[ChildCleanup];
|
|
|
|
int UserUnwindState =
|
|
|
|
FuncInfo.ClrEHUnwindMap[UserState].TryParentState;
|
|
|
|
if (UserUnwindState != -1)
|
|
|
|
UserUnwindDest = FuncInfo.ClrEHUnwindMap[UserUnwindState]
|
|
|
|
.Handler.get<const BasicBlock *>();
|
[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 06:38:55 +01:00
|
|
|
}
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-04 17:16:01 +01:00
|
|
|
|
|
|
|
// Not having an unwind dest for this user might indicate that it
|
|
|
|
// doesn't unwind, so can't be taken as proof that the cleanup itself
|
|
|
|
// may unwind to caller (see e.g. SimplifyUnreachable and
|
|
|
|
// RemoveUnwindEdge).
|
|
|
|
if (!UserUnwindDest)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Now we have an unwind dest for the user, but we need to see if it
|
|
|
|
// unwinds all the way out of the cleanup or if it stays within it.
|
|
|
|
const Instruction *UserUnwindPad = UserUnwindDest->getFirstNonPHI();
|
|
|
|
const Value *UserUnwindParent;
|
|
|
|
if (auto *CSI = dyn_cast<CatchSwitchInst>(UserUnwindPad))
|
|
|
|
UserUnwindParent = CSI->getParentPad();
|
|
|
|
else
|
|
|
|
UserUnwindParent =
|
|
|
|
cast<CleanupPadInst>(UserUnwindPad)->getParentPad();
|
|
|
|
|
|
|
|
// The unwind stays within the cleanup iff it targets a child of the
|
|
|
|
// cleanup.
|
|
|
|
if (UserUnwindParent == Cleanup)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// This unwind exits the cleanup, so its dest is the cleanup's dest.
|
|
|
|
UnwindDest = UserUnwindDest;
|
|
|
|
break;
|
[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 06:38:55 +01:00
|
|
|
}
|
2015-10-06 22:30:33 +02:00
|
|
|
}
|
|
|
|
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-04 17:16:01 +01:00
|
|
|
// Record the state of the unwind dest as the TryParentState.
|
|
|
|
int UnwindDestState;
|
|
|
|
|
|
|
|
// If UnwindDest is null at this point, either the pad in question can
|
|
|
|
// be exited by unwind to caller, or it cannot be exited by unwind. In
|
|
|
|
// either case, reporting such cases as unwinding to caller is correct.
|
|
|
|
// This can lead to EH tables that "look strange" -- if this pad's is in
|
|
|
|
// a parent funclet which has other children that do unwind to an enclosing
|
|
|
|
// pad, the try region for this pad will be missing the "duplicate" EH
|
|
|
|
// clause entries that you'd expect to see covering the whole parent. That
|
|
|
|
// should be benign, since the unwind never actually happens. If it were
|
|
|
|
// an issue, we could add a subsequent pass that pushes unwind dests down
|
|
|
|
// from parents that have them to children that appear to unwind to caller.
|
|
|
|
if (!UnwindDest) {
|
|
|
|
UnwindDestState = -1;
|
|
|
|
} else {
|
|
|
|
UnwindDestState = FuncInfo.EHPadStateMap[UnwindDest->getFirstNonPHI()];
|
2015-10-06 22:30:33 +02:00
|
|
|
}
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-04 17:16:01 +01:00
|
|
|
|
|
|
|
Entry->TryParentState = UnwindDestState;
|
2015-10-06 22:30:33 +02: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 06:38:55 +01:00
|
|
|
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-04 17:16:01 +01:00
|
|
|
// Step three: transfer information from pads to invokes.
|
[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 06:38:55 +01:00
|
|
|
calculateStateNumbersForInvokes(Fn, FuncInfo);
|
2015-10-06 22:30:33 +02: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 06:38:55 +01:00
|
|
|
void WinEHPrepare::colorFunclets(Function &F) {
|
|
|
|
BlockColors = colorEHFunclets(F);
|
2015-11-09 20:59:02 +01: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 06:38:55 +01:00
|
|
|
// Invert the map from BB to colors to color to BBs.
|
|
|
|
for (BasicBlock &BB : F) {
|
|
|
|
ColorVector &Colors = BlockColors[&BB];
|
|
|
|
for (BasicBlock *Color : Colors)
|
|
|
|
FuncletBlocks[Color].push_back(&BB);
|
2015-08-11 03:15:26 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-06-01 00:02:34 +02:00
|
|
|
void WinEHPrepare::demotePHIsOnFunclets(Function &F,
|
|
|
|
bool DemoteCatchSwitchPHIOnly) {
|
2015-08-13 16:30:10 +02:00
|
|
|
// Strip PHI nodes off of EH pads.
|
|
|
|
SmallVector<PHINode *, 16> PHINodes;
|
2021-02-20 07:44:14 +01:00
|
|
|
for (BasicBlock &BB : make_early_inc_range(F)) {
|
|
|
|
if (!BB.isEHPad())
|
2015-08-11 03:15:26 +02:00
|
|
|
continue;
|
2021-02-20 07:44:14 +01:00
|
|
|
if (DemoteCatchSwitchPHIOnly && !isa<CatchSwitchInst>(BB.getFirstNonPHI()))
|
2018-06-01 00:02:34 +02:00
|
|
|
continue;
|
|
|
|
|
2021-02-20 07:44:14 +01:00
|
|
|
for (Instruction &I : make_early_inc_range(BB)) {
|
|
|
|
auto *PN = dyn_cast<PHINode>(&I);
|
2015-08-11 03:15:26 +02:00
|
|
|
// Stop at the first non-PHI.
|
|
|
|
if (!PN)
|
|
|
|
break;
|
|
|
|
|
2015-08-13 16:30:10 +02:00
|
|
|
AllocaInst *SpillSlot = insertPHILoads(PN, F);
|
|
|
|
if (SpillSlot)
|
|
|
|
insertPHIStores(PN, SpillSlot);
|
|
|
|
|
|
|
|
PHINodes.push_back(PN);
|
2015-08-11 03:15:26 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-08-13 16:30:10 +02:00
|
|
|
for (auto *PN : PHINodes) {
|
|
|
|
// There may be lingering uses on other EH PHIs being removed
|
|
|
|
PN->replaceAllUsesWith(UndefValue::get(PN->getType()));
|
|
|
|
PN->eraseFromParent();
|
2015-08-11 03:15:26 +02:00
|
|
|
}
|
2015-09-16 20:40:24 +02:00
|
|
|
}
|
2015-08-11 03:15:26 +02: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 06:38:55 +01:00
|
|
|
void WinEHPrepare::cloneCommonBlocks(Function &F) {
|
2015-08-11 03:15:26 +02:00
|
|
|
// We need to clone all blocks which belong to multiple funclets. Values are
|
2016-11-20 14:47:59 +01:00
|
|
|
// remapped throughout the funclet to propagate both the new instructions
|
2015-08-11 03:15:26 +02:00
|
|
|
// *and* the new basic blocks themselves.
|
[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 06:38:55 +01:00
|
|
|
for (auto &Funclets : FuncletBlocks) {
|
|
|
|
BasicBlock *FuncletPadBB = Funclets.first;
|
|
|
|
std::vector<BasicBlock *> &BlocksInFunclet = Funclets.second;
|
2016-01-02 16:22:36 +01:00
|
|
|
Value *FuncletToken;
|
|
|
|
if (FuncletPadBB == &F.getEntryBlock())
|
|
|
|
FuncletToken = ConstantTokenNone::get(F.getContext());
|
|
|
|
else
|
|
|
|
FuncletToken = FuncletPadBB->getFirstNonPHI();
|
2015-08-11 03:15:26 +02: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 06:38:55 +01:00
|
|
|
std::vector<std::pair<BasicBlock *, BasicBlock *>> Orig2Clone;
|
2015-08-11 03:15:26 +02:00
|
|
|
ValueToValueMapTy VMap;
|
[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 06:38:55 +01:00
|
|
|
for (BasicBlock *BB : BlocksInFunclet) {
|
|
|
|
ColorVector &ColorsForBB = BlockColors[BB];
|
2015-08-11 03:15:26 +02:00
|
|
|
// We don't need to do anything if the block is monochromatic.
|
|
|
|
size_t NumColorsForBB = ColorsForBB.size();
|
|
|
|
if (NumColorsForBB == 1)
|
|
|
|
continue;
|
|
|
|
|
2015-11-09 20:59:02 +01:00
|
|
|
DEBUG_WITH_TYPE("winehprepare-coloring",
|
|
|
|
dbgs() << " Cloning block \'" << BB->getName()
|
|
|
|
<< "\' for funclet \'" << FuncletPadBB->getName()
|
|
|
|
<< "\'.\n");
|
|
|
|
|
2015-08-11 03:15:26 +02:00
|
|
|
// Create a new basic block and copy instructions into it!
|
2015-08-28 03:12:35 +02:00
|
|
|
BasicBlock *CBB =
|
|
|
|
CloneBasicBlock(BB, VMap, Twine(".for.", FuncletPadBB->getName()));
|
|
|
|
// Insert the clone immediately after the original to ensure determinism
|
|
|
|
// and to keep the same relative ordering of any funclet's blocks.
|
|
|
|
CBB->insertInto(&F, BB->getNextNode());
|
2015-08-11 03:15:26 +02:00
|
|
|
|
|
|
|
// Add basic block mapping.
|
|
|
|
VMap[BB] = CBB;
|
|
|
|
|
|
|
|
// Record delta operations that we need to perform to our color mappings.
|
[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 06:38:55 +01:00
|
|
|
Orig2Clone.emplace_back(BB, CBB);
|
2015-08-11 03:15:26 +02:00
|
|
|
}
|
|
|
|
|
2015-10-07 21:29:56 +02:00
|
|
|
// If nothing was cloned, we're done cloning in this funclet.
|
|
|
|
if (Orig2Clone.empty())
|
|
|
|
continue;
|
|
|
|
|
2015-08-11 03:15:26 +02:00
|
|
|
// Update our color mappings to reflect that one block has lost a color and
|
|
|
|
// another has gained a color.
|
|
|
|
for (auto &BBMapping : Orig2Clone) {
|
|
|
|
BasicBlock *OldBlock = BBMapping.first;
|
|
|
|
BasicBlock *NewBlock = BBMapping.second;
|
|
|
|
|
[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 06:38:55 +01:00
|
|
|
BlocksInFunclet.push_back(NewBlock);
|
|
|
|
ColorVector &NewColors = BlockColors[NewBlock];
|
|
|
|
assert(NewColors.empty() && "A new block should only have one color!");
|
|
|
|
NewColors.push_back(FuncletPadBB);
|
2015-08-11 03:15:26 +02:00
|
|
|
|
2015-11-09 20:59:02 +01:00
|
|
|
DEBUG_WITH_TYPE("winehprepare-coloring",
|
|
|
|
dbgs() << " Assigned color \'" << FuncletPadBB->getName()
|
|
|
|
<< "\' to block \'" << NewBlock->getName()
|
|
|
|
<< "\'.\n");
|
|
|
|
|
2021-01-02 18:24:15 +01:00
|
|
|
llvm::erase_value(BlocksInFunclet, OldBlock);
|
[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 06:38:55 +01:00
|
|
|
ColorVector &OldColors = BlockColors[OldBlock];
|
2021-01-02 18:24:15 +01:00
|
|
|
llvm::erase_value(OldColors, FuncletPadBB);
|
2015-11-09 20:59:02 +01:00
|
|
|
|
|
|
|
DEBUG_WITH_TYPE("winehprepare-coloring",
|
|
|
|
dbgs() << " Removed color \'" << FuncletPadBB->getName()
|
|
|
|
<< "\' from block \'" << OldBlock->getName()
|
|
|
|
<< "\'.\n");
|
2015-08-11 03:15:26 +02:00
|
|
|
}
|
|
|
|
|
2015-10-07 21:29:56 +02:00
|
|
|
// Loop over all of the instructions in this funclet, fixing up operand
|
2015-08-11 03:15:26 +02:00
|
|
|
// references as we go. This uses VMap to do all the hard work.
|
|
|
|
for (BasicBlock *BB : BlocksInFunclet)
|
|
|
|
// Loop over all instructions, fixing each one as we find it...
|
|
|
|
for (Instruction &I : *BB)
|
2015-10-07 21:29:56 +02:00
|
|
|
RemapInstruction(&I, VMap,
|
2016-04-07 02:26:43 +02:00
|
|
|
RF_IgnoreMissingLocals | RF_NoModuleLevelChanges);
|
2015-09-16 20:40:37 +02:00
|
|
|
|
2016-01-02 16:22:36 +01:00
|
|
|
// Catchrets targeting cloned blocks need to be updated separately from
|
|
|
|
// the loop above because they are not in the current funclet.
|
|
|
|
SmallVector<CatchReturnInst *, 2> FixupCatchrets;
|
|
|
|
for (auto &BBMapping : Orig2Clone) {
|
|
|
|
BasicBlock *OldBlock = BBMapping.first;
|
|
|
|
BasicBlock *NewBlock = BBMapping.second;
|
|
|
|
|
|
|
|
FixupCatchrets.clear();
|
|
|
|
for (BasicBlock *Pred : predecessors(OldBlock))
|
|
|
|
if (auto *CatchRet = dyn_cast<CatchReturnInst>(Pred->getTerminator()))
|
2016-01-15 22:16:19 +01:00
|
|
|
if (CatchRet->getCatchSwitchParentPad() == FuncletToken)
|
2016-01-02 16:22:36 +01:00
|
|
|
FixupCatchrets.push_back(CatchRet);
|
|
|
|
|
|
|
|
for (CatchReturnInst *CatchRet : FixupCatchrets)
|
|
|
|
CatchRet->setSuccessor(NewBlock);
|
|
|
|
}
|
|
|
|
|
[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 06:38:55 +01:00
|
|
|
auto UpdatePHIOnClonedBlock = [&](PHINode *PN, bool IsForOldBlock) {
|
|
|
|
unsigned NumPreds = PN->getNumIncomingValues();
|
|
|
|
for (unsigned PredIdx = 0, PredEnd = NumPreds; PredIdx != PredEnd;
|
|
|
|
++PredIdx) {
|
|
|
|
BasicBlock *IncomingBlock = PN->getIncomingBlock(PredIdx);
|
2016-01-02 16:22:36 +01:00
|
|
|
bool EdgeTargetsFunclet;
|
|
|
|
if (auto *CRI =
|
|
|
|
dyn_cast<CatchReturnInst>(IncomingBlock->getTerminator())) {
|
2016-01-15 22:16:19 +01:00
|
|
|
EdgeTargetsFunclet = (CRI->getCatchSwitchParentPad() == FuncletToken);
|
2016-01-02 16:22:36 +01:00
|
|
|
} else {
|
|
|
|
ColorVector &IncomingColors = BlockColors[IncomingBlock];
|
|
|
|
assert(!IncomingColors.empty() && "Block not colored!");
|
|
|
|
assert((IncomingColors.size() == 1 ||
|
|
|
|
llvm::all_of(IncomingColors,
|
|
|
|
[&](BasicBlock *Color) {
|
|
|
|
return Color != FuncletPadBB;
|
|
|
|
})) &&
|
|
|
|
"Cloning should leave this funclet's blocks monochromatic");
|
|
|
|
EdgeTargetsFunclet = (IncomingColors.front() == FuncletPadBB);
|
|
|
|
}
|
|
|
|
if (IsForOldBlock != EdgeTargetsFunclet)
|
[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 06:38:55 +01:00
|
|
|
continue;
|
|
|
|
PN->removeIncomingValue(IncomingBlock, /*DeletePHIIfEmpty=*/false);
|
|
|
|
// Revisit the next entry.
|
|
|
|
--PredIdx;
|
|
|
|
--PredEnd;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
for (auto &BBMapping : Orig2Clone) {
|
|
|
|
BasicBlock *OldBlock = BBMapping.first;
|
|
|
|
BasicBlock *NewBlock = BBMapping.second;
|
2017-12-30 16:27:33 +01:00
|
|
|
for (PHINode &OldPN : OldBlock->phis()) {
|
|
|
|
UpdatePHIOnClonedBlock(&OldPN, /*IsForOldBlock=*/true);
|
[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 06:38:55 +01:00
|
|
|
}
|
2017-12-30 16:27:33 +01:00
|
|
|
for (PHINode &NewPN : NewBlock->phis()) {
|
|
|
|
UpdatePHIOnClonedBlock(&NewPN, /*IsForOldBlock=*/false);
|
[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 06:38:55 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-09-16 20:40:37 +02:00
|
|
|
// Check to see if SuccBB has PHI nodes. If so, we need to add entries to
|
|
|
|
// the PHI nodes for NewBB now.
|
|
|
|
for (auto &BBMapping : Orig2Clone) {
|
|
|
|
BasicBlock *OldBlock = BBMapping.first;
|
|
|
|
BasicBlock *NewBlock = BBMapping.second;
|
|
|
|
for (BasicBlock *SuccBB : successors(NewBlock)) {
|
2017-12-30 16:27:33 +01:00
|
|
|
for (PHINode &SuccPN : SuccBB->phis()) {
|
2015-09-16 20:40:37 +02:00
|
|
|
// Ok, we have a PHI node. Figure out what the incoming value was for
|
|
|
|
// the OldBlock.
|
2017-12-30 16:27:33 +01:00
|
|
|
int OldBlockIdx = SuccPN.getBasicBlockIndex(OldBlock);
|
2015-09-16 20:40:37 +02:00
|
|
|
if (OldBlockIdx == -1)
|
|
|
|
break;
|
2017-12-30 16:27:33 +01:00
|
|
|
Value *IV = SuccPN.getIncomingValue(OldBlockIdx);
|
2015-09-16 20:40:37 +02:00
|
|
|
|
|
|
|
// Remap the value if necessary.
|
|
|
|
if (auto *Inst = dyn_cast<Instruction>(IV)) {
|
|
|
|
ValueToValueMapTy::iterator I = VMap.find(Inst);
|
|
|
|
if (I != VMap.end())
|
|
|
|
IV = I->second;
|
|
|
|
}
|
|
|
|
|
2017-12-30 16:27:33 +01:00
|
|
|
SuccPN.addIncoming(IV, NewBlock);
|
2015-09-16 20:40:37 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (ValueToValueMapTy::value_type VT : VMap) {
|
|
|
|
// If there were values defined in BB that are used outside the funclet,
|
|
|
|
// then we now have to update all uses of the value to use either the
|
|
|
|
// original value, the cloned value, or some PHI derived value. This can
|
|
|
|
// require arbitrary PHI insertion, of which we are prepared to do, clean
|
|
|
|
// these up now.
|
|
|
|
SmallVector<Use *, 16> UsesToRename;
|
|
|
|
|
|
|
|
auto *OldI = dyn_cast<Instruction>(const_cast<Value *>(VT.first));
|
|
|
|
if (!OldI)
|
|
|
|
continue;
|
|
|
|
auto *NewI = cast<Instruction>(VT.second);
|
|
|
|
// Scan all uses of this instruction to see if it is used outside of its
|
|
|
|
// funclet, and if so, record them in UsesToRename.
|
|
|
|
for (Use &U : OldI->uses()) {
|
|
|
|
Instruction *UserI = cast<Instruction>(U.getUser());
|
|
|
|
BasicBlock *UserBB = UserI->getParent();
|
[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 06:38:55 +01:00
|
|
|
ColorVector &ColorsForUserBB = BlockColors[UserBB];
|
2015-09-16 20:40:37 +02:00
|
|
|
assert(!ColorsForUserBB.empty());
|
|
|
|
if (ColorsForUserBB.size() > 1 ||
|
|
|
|
*ColorsForUserBB.begin() != FuncletPadBB)
|
|
|
|
UsesToRename.push_back(&U);
|
|
|
|
}
|
|
|
|
|
|
|
|
// If there are no uses outside the block, we're done with this
|
|
|
|
// instruction.
|
|
|
|
if (UsesToRename.empty())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// We found a use of OldI outside of the funclet. Rename all uses of OldI
|
|
|
|
// that are outside its funclet to be uses of the appropriate PHI node
|
|
|
|
// etc.
|
|
|
|
SSAUpdater SSAUpdate;
|
|
|
|
SSAUpdate.Initialize(OldI->getType(), OldI->getName());
|
|
|
|
SSAUpdate.AddAvailableValue(OldI->getParent(), OldI);
|
|
|
|
SSAUpdate.AddAvailableValue(NewI->getParent(), NewI);
|
|
|
|
|
|
|
|
while (!UsesToRename.empty())
|
|
|
|
SSAUpdate.RewriteUseAfterInsertions(*UsesToRename.pop_back_val());
|
|
|
|
}
|
2015-08-11 03:15:26 +02:00
|
|
|
}
|
2015-09-16 20:40:24 +02:00
|
|
|
}
|
2015-08-11 03:15:26 +02:00
|
|
|
|
2015-12-15 22:27:27 +01:00
|
|
|
void WinEHPrepare::removeImplausibleInstructions(Function &F) {
|
2015-08-17 22:56:39 +02:00
|
|
|
// Remove implausible terminators and replace them with UnreachableInst.
|
|
|
|
for (auto &Funclet : FuncletBlocks) {
|
|
|
|
BasicBlock *FuncletPadBB = Funclet.first;
|
[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 06:38:55 +01:00
|
|
|
std::vector<BasicBlock *> &BlocksInFunclet = Funclet.second;
|
2015-12-15 22:27:27 +01:00
|
|
|
Instruction *FirstNonPHI = FuncletPadBB->getFirstNonPHI();
|
|
|
|
auto *FuncletPad = dyn_cast<FuncletPadInst>(FirstNonPHI);
|
|
|
|
auto *CatchPad = dyn_cast_or_null<CatchPadInst>(FuncletPad);
|
|
|
|
auto *CleanupPad = dyn_cast_or_null<CleanupPadInst>(FuncletPad);
|
2015-08-17 22:56:39 +02:00
|
|
|
|
|
|
|
for (BasicBlock *BB : BlocksInFunclet) {
|
2015-12-15 22:27:27 +01:00
|
|
|
for (Instruction &I : *BB) {
|
2020-04-13 08:12:41 +02:00
|
|
|
auto *CB = dyn_cast<CallBase>(&I);
|
|
|
|
if (!CB)
|
2015-12-15 22:27:27 +01:00
|
|
|
continue;
|
|
|
|
|
|
|
|
Value *FuncletBundleOperand = nullptr;
|
2020-04-13 08:12:41 +02:00
|
|
|
if (auto BU = CB->getOperandBundle(LLVMContext::OB_funclet))
|
2015-12-15 22:27:27 +01:00
|
|
|
FuncletBundleOperand = BU->Inputs.front();
|
|
|
|
|
|
|
|
if (FuncletBundleOperand == FuncletPad)
|
|
|
|
continue;
|
|
|
|
|
2016-02-26 01:04:25 +01:00
|
|
|
// Skip call sites which are nounwind intrinsics or inline asm.
|
2015-12-15 22:27:27 +01:00
|
|
|
auto *CalledFn =
|
2020-04-28 05:15:59 +02:00
|
|
|
dyn_cast<Function>(CB->getCalledOperand()->stripPointerCasts());
|
2020-04-13 08:12:41 +02:00
|
|
|
if (CalledFn && ((CalledFn->isIntrinsic() && CB->doesNotThrow()) ||
|
|
|
|
CB->isInlineAsm()))
|
2015-12-15 22:27:27 +01:00
|
|
|
continue;
|
|
|
|
|
|
|
|
// This call site was not part of this funclet, remove it.
|
2020-04-13 08:12:41 +02:00
|
|
|
if (isa<InvokeInst>(CB)) {
|
2015-12-15 22:27:27 +01:00
|
|
|
// Remove the unwind edge if it was an invoke.
|
|
|
|
removeUnwindEdge(BB);
|
|
|
|
// Get a pointer to the new call.
|
|
|
|
BasicBlock::iterator CallI =
|
|
|
|
std::prev(BB->getTerminator()->getIterator());
|
|
|
|
auto *CI = cast<CallInst>(&*CallI);
|
2021-07-19 22:31:10 +02:00
|
|
|
changeToUnreachable(CI);
|
2015-12-15 22:27:27 +01:00
|
|
|
} else {
|
2021-07-19 22:31:10 +02:00
|
|
|
changeToUnreachable(&I);
|
2015-12-15 22:27:27 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
// There are no more instructions in the block (except for unreachable),
|
|
|
|
// we are done.
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2018-10-15 12:04:59 +02:00
|
|
|
Instruction *TI = BB->getTerminator();
|
2015-08-17 22:56:39 +02:00
|
|
|
// CatchPadInst and CleanupPadInst can't transfer control to a ReturnInst.
|
2015-12-15 22:27:27 +01:00
|
|
|
bool IsUnreachableRet = isa<ReturnInst>(TI) && FuncletPad;
|
2015-08-17 22:56:39 +02:00
|
|
|
// The token consumed by a CatchReturnInst must match the funclet token.
|
|
|
|
bool IsUnreachableCatchret = false;
|
|
|
|
if (auto *CRI = dyn_cast<CatchReturnInst>(TI))
|
2015-08-23 02:26:33 +02:00
|
|
|
IsUnreachableCatchret = CRI->getCatchPad() != CatchPad;
|
2015-09-03 11:09:43 +02:00
|
|
|
// The token consumed by a CleanupReturnInst must match the funclet token.
|
2015-08-17 22:56:39 +02:00
|
|
|
bool IsUnreachableCleanupret = false;
|
|
|
|
if (auto *CRI = dyn_cast<CleanupReturnInst>(TI))
|
2015-08-23 02:26:33 +02:00
|
|
|
IsUnreachableCleanupret = CRI->getCleanupPad() != CleanupPad;
|
2015-09-03 11:09:43 +02:00
|
|
|
if (IsUnreachableRet || IsUnreachableCatchret ||
|
[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 06:38:55 +01:00
|
|
|
IsUnreachableCleanupret) {
|
2021-07-19 22:31:10 +02:00
|
|
|
changeToUnreachable(TI);
|
[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 06:38:55 +01:00
|
|
|
} else if (isa<InvokeInst>(TI)) {
|
2015-12-15 22:27:27 +01:00
|
|
|
if (Personality == EHPersonality::MSVC_CXX && CleanupPad) {
|
|
|
|
// Invokes within a cleanuppad for the MSVC++ personality never
|
|
|
|
// transfer control to their unwind edge: the personality will
|
|
|
|
// terminate the program.
|
[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 06:38:55 +01:00
|
|
|
removeUnwindEdge(BB);
|
2015-12-15 22:27:27 +01:00
|
|
|
}
|
2015-08-17 22:56:39 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2015-09-16 20:40:24 +02:00
|
|
|
}
|
2015-08-17 22:56:39 +02:00
|
|
|
|
2015-09-16 20:40:24 +02:00
|
|
|
void WinEHPrepare::cleanupPreparedFunclets(Function &F) {
|
2015-08-11 03:15:26 +02:00
|
|
|
// Clean-up some of the mess we made by removing useles PHI nodes, trivial
|
|
|
|
// branches, etc.
|
2021-02-22 04:58:07 +01:00
|
|
|
for (BasicBlock &BB : llvm::make_early_inc_range(F)) {
|
|
|
|
SimplifyInstructionsInBlock(&BB);
|
|
|
|
ConstantFoldTerminator(&BB, /*DeleteDeadConditions=*/true);
|
|
|
|
MergeBlockIntoPredecessor(&BB);
|
2015-08-11 03:15:26 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// We might have some unreachable blocks after cleaning up some impossible
|
|
|
|
// control flow.
|
|
|
|
removeUnreachableBlocks(F);
|
2015-09-16 20:40:24 +02:00
|
|
|
}
|
2015-08-11 03:15:26 +02:00
|
|
|
|
2017-07-31 12:07:49 +02:00
|
|
|
#ifndef NDEBUG
|
2015-09-16 20:40:24 +02:00
|
|
|
void WinEHPrepare::verifyPreparedFunclets(Function &F) {
|
2015-08-11 03:15:26 +02:00
|
|
|
for (BasicBlock &BB : F) {
|
|
|
|
size_t NumColors = BlockColors[&BB].size();
|
|
|
|
assert(NumColors == 1 && "Expected monochromatic BB!");
|
|
|
|
if (NumColors == 0)
|
|
|
|
report_fatal_error("Uncolored BB!");
|
|
|
|
if (NumColors > 1)
|
|
|
|
report_fatal_error("Multicolor BB!");
|
2016-01-03 02:41:00 +01:00
|
|
|
assert((DisableDemotion || !(BB.isEHPad() && isa<PHINode>(BB.begin()))) &&
|
|
|
|
"EH Pad still has a PHI!");
|
2015-08-11 03:15:26 +02:00
|
|
|
}
|
2015-09-16 20:40:24 +02:00
|
|
|
}
|
2017-07-31 12:07:49 +02:00
|
|
|
#endif
|
2015-09-16 20:40:24 +02: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 06:38:55 +01:00
|
|
|
bool WinEHPrepare::prepareExplicitEH(Function &F) {
|
|
|
|
// Remove unreachable blocks. It is not valuable to assign them a color and
|
|
|
|
// their existence can trick us into thinking values are alive when they are
|
|
|
|
// not.
|
|
|
|
removeUnreachableBlocks(F);
|
|
|
|
|
2015-09-16 20:40:24 +02:00
|
|
|
// Determine which blocks are reachable from which funclet entries.
|
[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 06:38:55 +01:00
|
|
|
colorFunclets(F);
|
|
|
|
|
|
|
|
cloneCommonBlocks(F);
|
2015-09-16 20:40:24 +02:00
|
|
|
|
2015-11-20 00:23:33 +01:00
|
|
|
if (!DisableDemotion)
|
2018-06-01 00:02:34 +02:00
|
|
|
demotePHIsOnFunclets(F, DemoteCatchSwitchPHIOnly ||
|
|
|
|
DemoteCatchSwitchPHIOnlyOpt);
|
2015-09-16 20:40:24 +02:00
|
|
|
|
2015-09-16 20:40:37 +02:00
|
|
|
if (!DisableCleanups) {
|
2020-05-18 21:41:36 +02:00
|
|
|
assert(!verifyFunction(F, &dbgs()));
|
2015-12-15 22:27:27 +01:00
|
|
|
removeImplausibleInstructions(F);
|
2015-09-16 20:40:24 +02:00
|
|
|
|
2020-05-18 21:41:36 +02:00
|
|
|
assert(!verifyFunction(F, &dbgs()));
|
2015-09-16 20:40:37 +02:00
|
|
|
cleanupPreparedFunclets(F);
|
|
|
|
}
|
2015-09-16 20:40:24 +02:00
|
|
|
|
2018-05-14 14:53:11 +02:00
|
|
|
LLVM_DEBUG(verifyPreparedFunclets(F));
|
2016-01-02 10:26:36 +01:00
|
|
|
// Recolor the CFG to verify that all is well.
|
2018-05-14 14:53:11 +02:00
|
|
|
LLVM_DEBUG(colorFunclets(F));
|
|
|
|
LLVM_DEBUG(verifyPreparedFunclets(F));
|
2015-08-11 03:15:26 +02:00
|
|
|
|
|
|
|
BlockColors.clear();
|
|
|
|
FuncletBlocks.clear();
|
2015-08-18 21:07:12 +02:00
|
|
|
|
2015-08-11 03:15:26 +02:00
|
|
|
return true;
|
|
|
|
}
|
2015-08-13 16:30:10 +02:00
|
|
|
|
|
|
|
// TODO: Share loads when one use dominates another, or when a catchpad exit
|
|
|
|
// dominates uses (needs dominators).
|
|
|
|
AllocaInst *WinEHPrepare::insertPHILoads(PHINode *PN, Function &F) {
|
|
|
|
BasicBlock *PHIBlock = PN->getParent();
|
|
|
|
AllocaInst *SpillSlot = nullptr;
|
[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 06:38:55 +01:00
|
|
|
Instruction *EHPad = PHIBlock->getFirstNonPHI();
|
2015-08-13 16:30:10 +02:00
|
|
|
|
2018-08-26 11:51:22 +02:00
|
|
|
if (!EHPad->isTerminator()) {
|
[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 06:38:55 +01:00
|
|
|
// If the EHPad isn't a terminator, then we can insert a load in this block
|
|
|
|
// that will dominate all uses.
|
2017-04-11 00:27:50 +02:00
|
|
|
SpillSlot = new AllocaInst(PN->getType(), DL->getAllocaAddrSpace(), nullptr,
|
2015-08-13 16:30:10 +02:00
|
|
|
Twine(PN->getName(), ".wineh.spillslot"),
|
2015-10-10 00:56:24 +02:00
|
|
|
&F.getEntryBlock().front());
|
2019-02-01 21:44:24 +01:00
|
|
|
Value *V = new LoadInst(PN->getType(), SpillSlot,
|
|
|
|
Twine(PN->getName(), ".wineh.reload"),
|
2015-10-10 00:56:24 +02:00
|
|
|
&*PHIBlock->getFirstInsertionPt());
|
2015-08-13 16:30:10 +02:00
|
|
|
PN->replaceAllUsesWith(V);
|
|
|
|
return SpillSlot;
|
|
|
|
}
|
|
|
|
|
[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 06:38:55 +01:00
|
|
|
// Otherwise, we have a PHI on a terminator EHPad, and we give up and insert
|
|
|
|
// loads of the slot before every use.
|
2015-08-13 16:30:10 +02:00
|
|
|
DenseMap<BasicBlock *, Value *> Loads;
|
2021-02-22 04:58:07 +01:00
|
|
|
for (Use &U : llvm::make_early_inc_range(PN->uses())) {
|
2015-08-13 16:30:10 +02:00
|
|
|
auto *UsingInst = cast<Instruction>(U.getUser());
|
[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 06:38:55 +01:00
|
|
|
if (isa<PHINode>(UsingInst) && UsingInst->getParent()->isEHPad()) {
|
2015-08-13 16:30:10 +02:00
|
|
|
// Use is on an EH pad phi. Leave it alone; we'll insert loads and
|
|
|
|
// stores for it separately.
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
replaceUseWithLoad(PN, U, SpillSlot, Loads, F);
|
|
|
|
}
|
|
|
|
return SpillSlot;
|
|
|
|
}
|
|
|
|
|
|
|
|
// TODO: improve store placement. Inserting at def is probably good, but need
|
|
|
|
// to be careful not to introduce interfering stores (needs liveness analysis).
|
|
|
|
// TODO: identify related phi nodes that can share spill slots, and share them
|
|
|
|
// (also needs liveness).
|
|
|
|
void WinEHPrepare::insertPHIStores(PHINode *OriginalPHI,
|
|
|
|
AllocaInst *SpillSlot) {
|
|
|
|
// Use a worklist of (Block, Value) pairs -- the given Value needs to be
|
|
|
|
// stored to the spill slot by the end of the given Block.
|
|
|
|
SmallVector<std::pair<BasicBlock *, Value *>, 4> Worklist;
|
|
|
|
|
|
|
|
Worklist.push_back({OriginalPHI->getParent(), OriginalPHI});
|
|
|
|
|
|
|
|
while (!Worklist.empty()) {
|
|
|
|
BasicBlock *EHBlock;
|
|
|
|
Value *InVal;
|
|
|
|
std::tie(EHBlock, InVal) = Worklist.pop_back_val();
|
|
|
|
|
|
|
|
PHINode *PN = dyn_cast<PHINode>(InVal);
|
|
|
|
if (PN && PN->getParent() == EHBlock) {
|
|
|
|
// The value is defined by another PHI we need to remove, with no room to
|
|
|
|
// insert a store after the PHI, so each predecessor needs to store its
|
|
|
|
// incoming value.
|
|
|
|
for (unsigned i = 0, e = PN->getNumIncomingValues(); i < e; ++i) {
|
|
|
|
Value *PredVal = PN->getIncomingValue(i);
|
|
|
|
|
|
|
|
// Undef can safely be skipped.
|
|
|
|
if (isa<UndefValue>(PredVal))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
insertPHIStore(PN->getIncomingBlock(i), PredVal, SpillSlot, Worklist);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// We need to store InVal, which dominates EHBlock, but can't put a store
|
|
|
|
// in EHBlock, so need to put stores in each predecessor.
|
|
|
|
for (BasicBlock *PredBlock : predecessors(EHBlock)) {
|
|
|
|
insertPHIStore(PredBlock, InVal, SpillSlot, Worklist);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void WinEHPrepare::insertPHIStore(
|
|
|
|
BasicBlock *PredBlock, Value *PredVal, AllocaInst *SpillSlot,
|
|
|
|
SmallVectorImpl<std::pair<BasicBlock *, Value *>> &Worklist) {
|
|
|
|
|
2018-08-26 11:51:22 +02:00
|
|
|
if (PredBlock->isEHPad() && PredBlock->getFirstNonPHI()->isTerminator()) {
|
2015-08-13 16:30:10 +02:00
|
|
|
// Pred is unsplittable, so we need to queue it on the worklist.
|
|
|
|
Worklist.push_back({PredBlock, PredVal});
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Otherwise, insert the store at the end of the basic block.
|
|
|
|
new StoreInst(PredVal, SpillSlot, PredBlock->getTerminator());
|
|
|
|
}
|
|
|
|
|
|
|
|
void WinEHPrepare::replaceUseWithLoad(Value *V, Use &U, AllocaInst *&SpillSlot,
|
|
|
|
DenseMap<BasicBlock *, Value *> &Loads,
|
|
|
|
Function &F) {
|
|
|
|
// Lazilly create the spill slot.
|
|
|
|
if (!SpillSlot)
|
2017-04-11 00:27:50 +02:00
|
|
|
SpillSlot = new AllocaInst(V->getType(), DL->getAllocaAddrSpace(), nullptr,
|
2015-08-13 16:30:10 +02:00
|
|
|
Twine(V->getName(), ".wineh.spillslot"),
|
2015-10-10 00:56:24 +02:00
|
|
|
&F.getEntryBlock().front());
|
2015-08-13 16:30:10 +02:00
|
|
|
|
|
|
|
auto *UsingInst = cast<Instruction>(U.getUser());
|
|
|
|
if (auto *UsingPHI = dyn_cast<PHINode>(UsingInst)) {
|
|
|
|
// If this is a PHI node, we can't insert a load of the value before
|
|
|
|
// the use. Instead insert the load in the predecessor block
|
|
|
|
// corresponding to the incoming value.
|
|
|
|
//
|
|
|
|
// Note that if there are multiple edges from a basic block to this
|
|
|
|
// PHI node that we cannot have multiple loads. The problem is that
|
|
|
|
// the resulting PHI node will have multiple values (from each load)
|
|
|
|
// coming in from the same block, which is illegal SSA form.
|
|
|
|
// For this reason, we keep track of and reuse loads we insert.
|
|
|
|
BasicBlock *IncomingBlock = UsingPHI->getIncomingBlock(U);
|
2015-08-17 15:51:37 +02:00
|
|
|
if (auto *CatchRet =
|
|
|
|
dyn_cast<CatchReturnInst>(IncomingBlock->getTerminator())) {
|
|
|
|
// Putting a load above a catchret and use on the phi would still leave
|
|
|
|
// a cross-funclet def/use. We need to split the edge, change the
|
|
|
|
// catchret to target the new block, and put the load there.
|
|
|
|
BasicBlock *PHIBlock = UsingInst->getParent();
|
|
|
|
BasicBlock *NewBlock = SplitEdge(IncomingBlock, PHIBlock);
|
|
|
|
// SplitEdge gives us:
|
|
|
|
// IncomingBlock:
|
|
|
|
// ...
|
|
|
|
// br label %NewBlock
|
|
|
|
// NewBlock:
|
|
|
|
// catchret label %PHIBlock
|
|
|
|
// But we need:
|
|
|
|
// IncomingBlock:
|
|
|
|
// ...
|
|
|
|
// catchret label %NewBlock
|
|
|
|
// NewBlock:
|
|
|
|
// br label %PHIBlock
|
|
|
|
// So move the terminators to each others' blocks and swap their
|
|
|
|
// successors.
|
|
|
|
BranchInst *Goto = cast<BranchInst>(IncomingBlock->getTerminator());
|
|
|
|
Goto->removeFromParent();
|
|
|
|
CatchRet->removeFromParent();
|
|
|
|
IncomingBlock->getInstList().push_back(CatchRet);
|
|
|
|
NewBlock->getInstList().push_back(Goto);
|
|
|
|
Goto->setSuccessor(0, PHIBlock);
|
|
|
|
CatchRet->setSuccessor(NewBlock);
|
|
|
|
// Update the color mapping for the newly split edge.
|
2016-12-14 20:30:18 +01:00
|
|
|
// Grab a reference to the ColorVector to be inserted before getting the
|
|
|
|
// reference to the vector we are copying because inserting the new
|
|
|
|
// element in BlockColors might cause the map to be reallocated.
|
|
|
|
ColorVector &ColorsForNewBlock = BlockColors[NewBlock];
|
[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 06:38:55 +01:00
|
|
|
ColorVector &ColorsForPHIBlock = BlockColors[PHIBlock];
|
2016-12-14 20:30:18 +01:00
|
|
|
ColorsForNewBlock = ColorsForPHIBlock;
|
2015-08-17 15:51:37 +02:00
|
|
|
for (BasicBlock *FuncletPad : ColorsForPHIBlock)
|
[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 06:38:55 +01:00
|
|
|
FuncletBlocks[FuncletPad].push_back(NewBlock);
|
2015-08-17 15:51:37 +02:00
|
|
|
// Treat the new block as incoming for load insertion.
|
|
|
|
IncomingBlock = NewBlock;
|
|
|
|
}
|
2015-08-13 16:30:10 +02:00
|
|
|
Value *&Load = Loads[IncomingBlock];
|
|
|
|
// Insert the load into the predecessor block
|
|
|
|
if (!Load)
|
2019-02-01 21:44:24 +01:00
|
|
|
Load = new LoadInst(V->getType(), SpillSlot,
|
|
|
|
Twine(V->getName(), ".wineh.reload"),
|
2019-07-16 06:46:31 +02:00
|
|
|
/*isVolatile=*/false, IncomingBlock->getTerminator());
|
2015-08-13 16:30:10 +02:00
|
|
|
|
|
|
|
U.set(Load);
|
|
|
|
} else {
|
|
|
|
// Reload right before the old use.
|
2019-02-01 21:44:24 +01:00
|
|
|
auto *Load = new LoadInst(V->getType(), SpillSlot,
|
|
|
|
Twine(V->getName(), ".wineh.reload"),
|
2019-07-16 06:46:31 +02:00
|
|
|
/*isVolatile=*/false, UsingInst);
|
2015-08-13 16:30:10 +02:00
|
|
|
U.set(Load);
|
|
|
|
}
|
|
|
|
}
|
2015-09-29 01:56:30 +02: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 06:38:55 +01:00
|
|
|
void WinEHFuncInfo::addIPToStateRange(const InvokeInst *II,
|
2015-09-29 01:56:30 +02:00
|
|
|
MCSymbol *InvokeBegin,
|
|
|
|
MCSymbol *InvokeEnd) {
|
[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 06:38:55 +01:00
|
|
|
assert(InvokeStateMap.count(II) &&
|
|
|
|
"should get invoke with precomputed state");
|
|
|
|
LabelToStateMap[InvokeBegin] = std::make_pair(InvokeStateMap[II], InvokeEnd);
|
2015-09-29 01:56:30 +02:00
|
|
|
}
|
2015-12-29 10:24:39 +01:00
|
|
|
|
|
|
|
WinEHFuncInfo::WinEHFuncInfo() {}
|