summaryrefslogtreecommitdiffstats
path: root/docs/ExceptionHandling.rst
diff options
context:
space:
mode:
authorJoseph Tremoulet <jotrem@microsoft.com>2015-09-03 09:09:43 +0000
committerJoseph Tremoulet <jotrem@microsoft.com>2015-09-03 09:09:43 +0000
commit226889eb73e83dea20c050047bcff71e1552a90f (patch)
tree483e40337d9346bedebb5d57ae78a348be757ef4 /docs/ExceptionHandling.rst
parentd951d3c8df3798801931ae64fc5591014ce32485 (diff)
[WinEH] Add cleanupendpad instruction
Summary: Add a `cleanupendpad` instruction, used to mark exceptional exits out of cleanups (for languages/targets that can abort a cleanup with another exception). The `cleanupendpad` instruction is similar to the `catchendpad` instruction in that it is an EH pad which is the target of unwind edges in the handler and which itself has an unwind edge to the next EH action. The `cleanupendpad` instruction, similar to `cleanupret` has a `cleanuppad` argument indicating which cleanup it exits. The unwind successors of a `cleanuppad`'s `cleanupendpad`s must agree with each other and with its `cleanupret`s. Update WinEHPrepare (and docs/tests) to accomodate `cleanupendpad`. Reviewers: rnk, andrew.w.kaylor, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12433 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246751 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'docs/ExceptionHandling.rst')
-rw-r--r--docs/ExceptionHandling.rst43
1 files changed, 32 insertions, 11 deletions
diff --git a/docs/ExceptionHandling.rst b/docs/ExceptionHandling.rst
index fce875b9b8ab..2f09155dff2f 100644
--- a/docs/ExceptionHandling.rst
+++ b/docs/ExceptionHandling.rst
@@ -614,19 +614,32 @@ specifications with one combined instruction. All potentially throwing calls in
a ``noexcept`` function should transitively unwind to a terminateblock. Throw
specifications are not implemented by MSVC, and are not yet supported.
+New instructions are also used to mark the points where control is transferred
+out of a catch/cleanup handler (which will correspond to exits from the
+generated funclet). A catch handler which reaches its end by normal execution
+executes a ``catchret`` instruction, which is a terminator indicating where in
+the function control is returned to. A cleanup handler which reaches its end
+by normal execution executes a ``cleanupret`` instruction, which is a terminator
+indicating where the active exception will unwind to next. A catch or cleanup
+handler which is exited by another exception being raised during its execution will
+unwind through a ``catchendpad`` or ``cleanuupendpad`` (respectively). The
+``catchendpad`` and ``cleanupendpad`` instructions are considered "exception
+handling pads" in the same sense that ``catchpad``, ``cleanuppad``, and
+``terminatepad`` are.
+
Each of these new EH pad instructions has a way to identify which
action should be considered after this action. The ``catchpad`` and
``terminatepad`` instructions are terminators, and have a label operand considered
to be an unwind destination analogous to the unwind destination of an invoke. The
``cleanuppad`` instruction is different from the other two in that it is not a
terminator. The code inside a cleanuppad runs before transferring control to the
-next action, so the ``cleanupret`` instruction is the instruction that holds a
-label operand and unwinds to the next EH pad. All of these "unwind edges" may
-refer to a basic block that contains an EH pad instruction, or they may simply
-unwind to the caller. Unwinding to the caller has roughly the same semantics as
-the ``resume`` instruction in the ``landingpad`` model. When inlining through an
-invoke, instructions that unwind to the caller are hooked up to unwind to the
-unwind destination of the call site.
+next action, so the ``cleanupret`` and ``cleanupendpad`` instructions are the
+instructions that hold a label operand and unwind to the next EH pad. All of
+these "unwind edges" may refer to a basic block that contains an EH pad instruction,
+or they may simply unwind to the caller. Unwinding to the caller has roughly the
+same semantics as the ``resume`` instruction in the ``landingpad`` model. When
+inlining through an invoke, instructions that unwind to the caller are hooked
+up to unwind to the unwind destination of the call site.
Putting things together, here is a hypothetical lowering of some C++ that uses
all of the new IR instructions:
@@ -644,6 +657,7 @@ all of the new IR instructions:
Cleanup obj;
may_throw();
} catch (int e) {
+ may_throw();
return e;
}
return 0;
@@ -666,7 +680,7 @@ all of the new IR instructions:
call void @"\01??_DCleanup@@QEAA@XZ"(%struct.Cleanup* nonnull %obj) nounwind
br label %return
- return: ; preds = %invoke.cont.2, %catch
+ return: ; preds = %invoke.cont.2, %invoke.cont.3
%retval.0 = phi i32 [ 0, %invoke.cont.2 ], [ %9, %catch ]
ret i32 %retval.0
@@ -679,13 +693,20 @@ all of the new IR instructions:
lpad.catch: ; preds = %entry, %lpad.cleanup
%catch = catchpad [%rtti.TypeDescriptor2* @"\01??_R0H@8", i32 0, i32* %e]
- to label %catch unwind label %lpad.terminate
+ to label %catch.body unwind label %catchend
- catch: ; preds = %lpad.catch
+ catch.body: ; preds = %lpad.catch
+ invoke void @"\01?may_throw@@YAXXZ"()
+ to label %invoke.cont.3 unwind label %catchend
+
+ invoke.cont.3: ; preds = %catch.body
%9 = load i32, i32* %e, align 4
catchret %catch label %return
- lpad.terminate:
+ catchend: ; preds = %lpad.catch, %catch.body
+ catchendpad unwind label %lpad.terminate
+
+ lpad.terminate: ; preds = %catchend
terminatepad [void ()* @"\01?terminate@@YAXXZ"]
unwind to caller
}