diff options
author | Joseph Tremoulet <jotrem@microsoft.com> | 2015-09-03 09:09:43 +0000 |
---|---|---|
committer | Joseph Tremoulet <jotrem@microsoft.com> | 2015-09-03 09:09:43 +0000 |
commit | 226889eb73e83dea20c050047bcff71e1552a90f (patch) | |
tree | 483e40337d9346bedebb5d57ae78a348be757ef4 /docs/ExceptionHandling.rst | |
parent | d951d3c8df3798801931ae64fc5591014ce32485 (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.rst | 43 |
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 } |