2019-09-12 14:52:24 +08:00
|
|
|
// REQUIRES: webassembly-registered-target
|
[WebAssembly] Tidy up EH/SjLj options
This CL is small, but the description can be a little long because I'm
trying to sum up the status quo for Emscripten/Wasm EH/SjLj options.
First, this CL adds an option for Wasm SjLj (`-wasm-enable-sjlj`), which
handles SjLj using Wasm EH. The implementation for this will be added as
a followup CL, but this adds the option first to do error checking.
This also adds an option for Wasm EH (`-wasm-enable-eh`), which has been
already implemented. Before we used `-exception-model=wasm` as the same
meaning as enabling Wasm EH, but after we add Wasm SjLj, it will be
possible to use Wasm EH instructions for Wasm SjLj while not enabling
EH, so going forward, to use Wasm EH, `opt` and `llc` will need this
option. This only affects `opt` and `llc` command lines and does not
affect Emscripten user interface.
Now we have two modes of EH (Emscripten/Wasm) and also two modes of SjLj
(also Emscripten/Wasm). The options corresponding to each of are:
- Emscripten EH: `-enable-emscripten-cxx-exceptions`
- Emscripten SjLj: `-enable-emscripten-sjlj`
- Wasm EH: `-wasm-enable-eh -exception-model=wasm`
`-mattr=+exception-handling`
- Wasm SjLj: `-wasm-enable-sjlj -exception-model=wasm`
`-mattr=+exception-handling`
The reason Wasm EH/SjLj's options are a little complicated are
`-exception-model` and `-mattr` are common LLVM options ane not under
our control. (`-mattr` can be omitted if it is embedded within the
bitcode file.)
And we have the following rules of the option composition:
- Emscripten EH and Wasm EH cannot be turned on at the same itme
- Emscripten SjLj and Wasm SjLj cannot be turned on at the same time
- Wasm SjLj should be used with Wasm EH
Which means we now allow these combinations:
- Emscripten EH + Emscripten SjLj: the current default in `emcc`
- Wasm EH + Emscripten SjLj:
This is allowed, but only as an interim step in which we are testing
Wasm EH but not yet have a working implementation of Wasm SjLj. This
will error out (D107687) in compile time if `setjmp` is called in a
function in which Wasm exception is used.
- Wasm EH + Wasm SjLj:
This will be the default mode later when using Wasm EH. Currently Wasm
SjLj implementation doesn't exist, so it doesn't work.
- Emscripten EH + Wasm SjLj will not work.
This CL moves these error checking routines to
`WebAssemblyPassConfig::addIRPasses`. Not sure if this is an ideal place
to do this, but I couldn't find elsewhere. Currently some checking is
done within LowerEmscriptenEHSjLj, but these checks only run if
LowerEmscriptenEHSjLj runs so it may not run when Wasm EH is used. This
moves that to `addIRPasses` and adds some more checks.
Currently LowerEmscriptenEHSjLj pass is responsible for Emscripten EH
and Emscripten SjLj. Wasm EH transformations are done in multiple
places, including WasmEHPrepare, LateEHPrepare, and CFGStackify. But in
the followup CL, LowerEmscriptenEHSjLj pass will be also responsible for
a part of Wasm SjLj transformation, because WasmSjLj will also be using
several Emscripten library functions, and we will be sharing more than
half of the transformation to do that between Emscripten SjLj and Wasm
SjLj.
Currently we have `-enable-emscripten-cxx-exceptions` and
`-enable-emscripten-sjlj` but these only work for `llc`, because for
`llc` we feed these options to the pass but when we run the pass using
`opt` the pass will be created with no options and the default options
will be used, which turns both Emscripten EH and Emscripten SjLj on.
Now we have one more SjLj option to care for, LowerEmscriptenEHSjLj pass
needs a finer way to control these options. This CL removes those
default parameters and make LowerEmscriptenEHSjLj pass read directly
from command line options specified. So if we only run
`opt -wasm-lower-em-ehsjlj`, currently both Emscripten EH and Emscripten
SjLj will run, but with this CL, none will run unless we additionally
pass `-enable-emscripten-cxx-exceptions` or `-enable-emscripten-sjlj`,
or both. This does not affect users; this only affects our `opt` tests
because `emcc` will not call either `opt` or `llc`. As a result of this,
our existing Emscripten EH/SjLj tests gained one or both of those
options in their `RUN` lines.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D107685
2021-08-07 10:35:18 +08:00
|
|
|
// RUN: %clang_cc1 %s -triple wasm32-unknown-unknown -fms-extensions -fexceptions -fcxx-exceptions -mllvm -wasm-enable-eh -exception-model=wasm -target-feature +exception-handling -emit-llvm -o - -std=c++11 | FileCheck %s
|
|
|
|
|
// RUN: %clang_cc1 %s -triple wasm64-unknown-unknown -fms-extensions -fexceptions -fcxx-exceptions -mllvm -wasm-enable-eh -exception-model=wasm -target-feature +exception-handling -emit-llvm -o - -std=c++11 | FileCheck %s
|
[WebAssembly] Use Windows EH instructions for Wasm EH
Summary:
Because wasm control flow needs to be structured, using WinEH
instructions to support wasm EH brings several benefits. This patch
makes wasm EH uses Windows EH instructions, with some changes:
1. Because wasm uses a single catch block to catch all C++ exceptions,
this merges all catch clauses into a single catchpad, within which we
test the EH selector as in Itanium EH.
2. Generates a call to `__clang_call_terminate` in case a cleanup
throws. Wasm does not have a runtime to handle this.
3. In case there is no catch-all clause, inserts a call to
`__cxa_rethrow` at the end of a catchpad in order to unwind to an
enclosing EH scope.
Reviewers: majnemer, dschuff
Subscribers: jfb, sbc100, jgravelle-google, sunfish, cfe-commits
Differential Revision: https://reviews.llvm.org/D44931
llvm-svn: 333703
2018-06-01 06:18:13 +08:00
|
|
|
|
|
|
|
|
void may_throw();
|
|
|
|
|
void dont_throw() noexcept;
|
|
|
|
|
|
|
|
|
|
struct Cleanup {
|
|
|
|
|
~Cleanup() { dont_throw(); }
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
// Multiple catch clauses w/o catch-all
|
|
|
|
|
void test0() {
|
|
|
|
|
try {
|
|
|
|
|
may_throw();
|
|
|
|
|
} catch (int) {
|
|
|
|
|
dont_throw();
|
|
|
|
|
} catch (double) {
|
|
|
|
|
dont_throw();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// CHECK-LABEL: define void @_Z5test0v() {{.*}} personality i8* bitcast (i32 (...)* @__gxx_wasm_personality_v0 to i8*)
|
|
|
|
|
|
|
|
|
|
// CHECK: %[[INT_ALLOCA:.*]] = alloca i32
|
|
|
|
|
// CHECK: invoke void @_Z9may_throwv()
|
|
|
|
|
// CHECK-NEXT: to label %[[NORMAL_BB:.*]] unwind label %[[CATCHDISPATCH_BB:.*]]
|
|
|
|
|
|
|
|
|
|
// CHECK: [[CATCHDISPATCH_BB]]:
|
|
|
|
|
// CHECK-NEXT: %[[CATCHSWITCH:.*]] = catchswitch within none [label %[[CATCHSTART_BB:.*]]] unwind to caller
|
|
|
|
|
|
|
|
|
|
// CHECK: [[CATCHSTART_BB]]:
|
|
|
|
|
// CHECK-NEXT: %[[CATCHPAD:.*]] = catchpad within %[[CATCHSWITCH]] [i8* bitcast (i8** @_ZTIi to i8*), i8* bitcast (i8** @_ZTId to i8*)]
|
|
|
|
|
// CHECK-NEXT: %[[EXN:.*]] = call i8* @llvm.wasm.get.exception(token %[[CATCHPAD]])
|
|
|
|
|
// CHECK-NEXT: store i8* %[[EXN]], i8** %exn.slot
|
|
|
|
|
// CHECK-NEXT: %[[SELECTOR:.*]] = call i32 @llvm.wasm.get.ehselector(token %[[CATCHPAD]])
|
|
|
|
|
// CHECK-NEXT: %[[TYPEID:.*]] = call i32 @llvm.eh.typeid.for(i8* bitcast (i8** @_ZTIi to i8*)) #2
|
|
|
|
|
// CHECK-NEXT: %[[MATCHES:.*]] = icmp eq i32 %[[SELECTOR]], %[[TYPEID]]
|
|
|
|
|
// CHECK-NEXT: br i1 %[[MATCHES]], label %[[CATCH_INT_BB:.*]], label %[[CATCH_FALLTHROUGH_BB:.*]]
|
|
|
|
|
|
|
|
|
|
// CHECK: [[CATCH_INT_BB]]:
|
|
|
|
|
// CHECK-NEXT: %[[EXN:.*]] = load i8*, i8** %exn.slot
|
|
|
|
|
// CHECK-NEXT: %[[ADDR:.*]] = call i8* @__cxa_begin_catch(i8* %[[EXN]]) {{.*}} [ "funclet"(token %[[CATCHPAD]]) ]
|
|
|
|
|
// CHECK-NEXT: %[[ADDR_CAST:.*]] = bitcast i8* %[[ADDR]] to i32*
|
|
|
|
|
// CHECK-NEXT: %[[INT_VAL:.*]] = load i32, i32* %[[ADDR_CAST]]
|
|
|
|
|
// CHECK-NEXT: store i32 %[[INT_VAL]], i32* %[[INT_ALLOCA]]
|
|
|
|
|
// CHECK-NEXT: call void @_Z10dont_throwv() {{.*}} [ "funclet"(token %[[CATCHPAD]]) ]
|
|
|
|
|
// CHECK-NEXT: call void @__cxa_end_catch() {{.*}} [ "funclet"(token %[[CATCHPAD]]) ]
|
|
|
|
|
// CHECK-NEXT: catchret from %[[CATCHPAD]] to label %[[CATCHRET_DEST_BB0:.*]]
|
|
|
|
|
|
|
|
|
|
// CHECK: [[CATCHRET_DEST_BB0]]:
|
|
|
|
|
// CHECK-NEXT: br label %[[TRY_CONT_BB:.*]]
|
|
|
|
|
|
|
|
|
|
// CHECK: [[CATCH_FALLTHROUGH_BB]]
|
|
|
|
|
// CHECK-NEXT: %[[TYPEID:.*]] = call i32 @llvm.eh.typeid.for(i8* bitcast (i8** @_ZTId to i8*)) #2
|
|
|
|
|
// CHECK-NEXT: %[[MATCHES:.*]] = icmp eq i32 %[[SELECTOR]], %[[TYPEID]]
|
|
|
|
|
// CHECK-NEXT: br i1 %[[MATCHES]], label %[[CATCH_FLOAT_BB:.*]], label %[[RETHROW_BB:.*]]
|
|
|
|
|
|
|
|
|
|
// CHECK: [[CATCH_FLOAT_BB]]:
|
|
|
|
|
// CHECK: catchret from %[[CATCHPAD]] to label %[[CATCHRET_DEST_BB1:.*]]
|
|
|
|
|
|
|
|
|
|
// CHECK: [[CATCHRET_DEST_BB1]]:
|
|
|
|
|
// CHECK-NEXT: br label %[[TRY_CONT_BB]]
|
|
|
|
|
|
|
|
|
|
// CHECK: [[RETHROW_BB]]:
|
2020-12-26 08:14:35 +08:00
|
|
|
// CHECK-NEXT: call void @llvm.wasm.rethrow() {{.*}} [ "funclet"(token %[[CATCHPAD]]) ]
|
[WebAssembly] Use Windows EH instructions for Wasm EH
Summary:
Because wasm control flow needs to be structured, using WinEH
instructions to support wasm EH brings several benefits. This patch
makes wasm EH uses Windows EH instructions, with some changes:
1. Because wasm uses a single catch block to catch all C++ exceptions,
this merges all catch clauses into a single catchpad, within which we
test the EH selector as in Itanium EH.
2. Generates a call to `__clang_call_terminate` in case a cleanup
throws. Wasm does not have a runtime to handle this.
3. In case there is no catch-all clause, inserts a call to
`__cxa_rethrow` at the end of a catchpad in order to unwind to an
enclosing EH scope.
Reviewers: majnemer, dschuff
Subscribers: jfb, sbc100, jgravelle-google, sunfish, cfe-commits
Differential Revision: https://reviews.llvm.org/D44931
llvm-svn: 333703
2018-06-01 06:18:13 +08:00
|
|
|
// CHECK-NEXT: unreachable
|
|
|
|
|
|
|
|
|
|
// Single catch-all
|
|
|
|
|
void test1() {
|
|
|
|
|
try {
|
|
|
|
|
may_throw();
|
|
|
|
|
} catch (...) {
|
|
|
|
|
dont_throw();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// CATCH-LABEL: @_Z5test1v()
|
|
|
|
|
|
|
|
|
|
// CHECK: %[[CATCHSWITCH:.*]] = catchswitch within none [label %[[CATCHSTART_BB:.*]]] unwind to caller
|
|
|
|
|
|
|
|
|
|
// CHECK: [[CATCHSTART_BB]]:
|
|
|
|
|
// CHECK-NEXT: %[[CATCHPAD:.*]] = catchpad within %[[CATCHSWITCH]] [i8* null]
|
|
|
|
|
// CHECK: br label %[[CATCH_ALL_BB:.*]]
|
|
|
|
|
|
|
|
|
|
// CHECK: [[CATCH_ALL_BB]]:
|
|
|
|
|
// CHECK: catchret from %[[CATCHPAD]] to label
|
|
|
|
|
|
|
|
|
|
// Multiple catch clauses w/ catch-all
|
|
|
|
|
void test2() {
|
|
|
|
|
try {
|
|
|
|
|
may_throw();
|
|
|
|
|
} catch (int) {
|
|
|
|
|
dont_throw();
|
|
|
|
|
} catch (...) {
|
|
|
|
|
dont_throw();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// CHECK-LABEL: @_Z5test2v()
|
|
|
|
|
|
|
|
|
|
// CHECK: %[[CATCHSWITCH:.*]] = catchswitch within none [label %[[CATCHSTART_BB:.*]]] unwind to caller
|
|
|
|
|
|
|
|
|
|
// CHECK: [[CATCHSTART_BB]]:
|
|
|
|
|
// CHECK-NEXT: %[[CATCHPAD:.*]] = catchpad within %[[CATCHSWITCH]] [i8* bitcast (i8** @_ZTIi to i8*), i8* null]
|
|
|
|
|
// CHECK: br i1 %{{.*}}, label %[[CATCH_INT_BB:.*]], label %[[CATCH_ALL_BB:.*]]
|
|
|
|
|
|
|
|
|
|
// CHECK: [[CATCH_INT_BB]]:
|
|
|
|
|
// CHECK: catchret from %[[CATCHPAD]] to label
|
|
|
|
|
|
|
|
|
|
// CHECK: [[CATCH_ALL_BB]]:
|
|
|
|
|
// CHECK: catchret from %[[CATCHPAD]] to label
|
|
|
|
|
|
|
|
|
|
// Cleanup
|
|
|
|
|
void test3() {
|
|
|
|
|
Cleanup c;
|
|
|
|
|
may_throw();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// CHECK-LABEL: @_Z5test3v()
|
|
|
|
|
|
|
|
|
|
// CHECK: invoke void @_Z9may_throwv()
|
|
|
|
|
// CHECK-NEXT: to label {{.*}} unwind label %[[EHCLEANUP_BB:.*]]
|
|
|
|
|
|
|
|
|
|
// CHECK: [[EHCLEANUP_BB]]:
|
|
|
|
|
// CHECK-NEXT: %[[CLEANUPPAD:.*]] = cleanuppad within none []
|
2022-01-16 17:53:11 +08:00
|
|
|
// CHECK-NEXT: call noundef %struct.Cleanup* @_ZN7CleanupD1Ev(%struct.Cleanup* {{[^,]*}} %{{.*}}) {{.*}} [ "funclet"(token %[[CLEANUPPAD]]) ]
|
[WebAssembly] Use Windows EH instructions for Wasm EH
Summary:
Because wasm control flow needs to be structured, using WinEH
instructions to support wasm EH brings several benefits. This patch
makes wasm EH uses Windows EH instructions, with some changes:
1. Because wasm uses a single catch block to catch all C++ exceptions,
this merges all catch clauses into a single catchpad, within which we
test the EH selector as in Itanium EH.
2. Generates a call to `__clang_call_terminate` in case a cleanup
throws. Wasm does not have a runtime to handle this.
3. In case there is no catch-all clause, inserts a call to
`__cxa_rethrow` at the end of a catchpad in order to unwind to an
enclosing EH scope.
Reviewers: majnemer, dschuff
Subscribers: jfb, sbc100, jgravelle-google, sunfish, cfe-commits
Differential Revision: https://reviews.llvm.org/D44931
llvm-svn: 333703
2018-06-01 06:18:13 +08:00
|
|
|
// CHECK-NEXT: cleanupret from %[[CLEANUPPAD]] unwind to caller
|
|
|
|
|
|
|
|
|
|
// Possibly throwing function call within a catch
|
|
|
|
|
void test4() {
|
|
|
|
|
try {
|
|
|
|
|
may_throw();
|
|
|
|
|
} catch (int) {
|
|
|
|
|
may_throw();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// CHECK-LABEL: @_Z5test4v()
|
|
|
|
|
|
|
|
|
|
// CHECK: %[[CATCHSWITCH]] = catchswitch within none [label %[[CATCHSTART_BB]]] unwind to caller
|
|
|
|
|
|
|
|
|
|
// CHECK: [[CATCHSTART_BB]]:
|
|
|
|
|
// CHECK: %[[CATCHPAD:.*]] = catchpad within %[[CATCHSWITCH]] [i8* bitcast (i8** @_ZTIi to i8*)]
|
|
|
|
|
|
|
|
|
|
// CHECK: invoke void @_Z9may_throwv() [ "funclet"(token %[[CATCHPAD]]) ]
|
|
|
|
|
// CHECK-NEXT: to label %[[INVOKE_CONT_BB:.*]] unwind label %[[EHCLEANUP_BB:.*]]
|
|
|
|
|
|
|
|
|
|
// CHECK: [[INVOKE_CONT_BB]]:
|
|
|
|
|
// CHECK-NEXT: call void @__cxa_end_catch() {{.*}} [ "funclet"(token %[[CATCHPAD]]) ]
|
|
|
|
|
// CHECK-NEXT: catchret from %[[CATCHPAD]] to label
|
|
|
|
|
|
|
|
|
|
// CHECK: [[EHCLEANUP_BB]]:
|
|
|
|
|
// CHECK-NEXT: %[[CLEANUPPAD:.*]] = cleanuppad within %[[CATCHPAD]] []
|
|
|
|
|
// CHECK-NEXT: call void @__cxa_end_catch() {{.*}} [ "funclet"(token %[[CLEANUPPAD]]) ]
|
|
|
|
|
// CHECK-NEXT: cleanupret from %[[CLEANUPPAD]] unwind to caller
|
|
|
|
|
|
|
|
|
|
// Possibly throwing function call within a catch-all
|
|
|
|
|
void test5() {
|
|
|
|
|
try {
|
|
|
|
|
may_throw();
|
|
|
|
|
} catch (...) {
|
|
|
|
|
may_throw();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// CHECK-LABEL: @_Z5test5v()
|
|
|
|
|
|
|
|
|
|
// CHECK: %[[CATCHSWITCH:.*]] = catchswitch within none [label %[[CATCHSTART_BB]]] unwind to caller
|
|
|
|
|
|
|
|
|
|
// CHECK: [[CATCHSTART_BB]]:
|
|
|
|
|
// CHECK: %[[CATCHPAD:.*]] = catchpad within %[[CATCHSWITCH]] [i8* null]
|
|
|
|
|
|
|
|
|
|
// CHECK: invoke void @_Z9may_throwv() [ "funclet"(token %[[CATCHPAD]]) ]
|
|
|
|
|
// CHECK-NEXT: to label %[[INVOKE_CONT_BB0:.*]] unwind label %[[EHCLEANUP_BB:.*]]
|
|
|
|
|
|
|
|
|
|
// CHECK: [[INVOKE_CONT_BB0]]:
|
|
|
|
|
// CHECK-NEXT: call void @__cxa_end_catch() [ "funclet"(token %[[CATCHPAD]]) ]
|
|
|
|
|
// CHECK-NEXT: catchret from %[[CATCHPAD]] to label
|
|
|
|
|
|
|
|
|
|
// CHECK: [[EHCLEANUP_BB]]:
|
|
|
|
|
// CHECK-NEXT: %[[CLEANUPPAD0:.*]] = cleanuppad within %[[CATCHPAD]] []
|
|
|
|
|
// CHECK-NEXT: invoke void @__cxa_end_catch() [ "funclet"(token %[[CLEANUPPAD0]]) ]
|
|
|
|
|
// CHECK-NEXT: to label %[[INVOKE_CONT_BB1:.*]] unwind label %[[TERMINATE_BB:.*]]
|
|
|
|
|
|
|
|
|
|
// CHECK: [[INVOKE_CONT_BB1]]:
|
|
|
|
|
// CHECK-NEXT: cleanupret from %[[CLEANUPPAD0]] unwind to caller
|
|
|
|
|
|
|
|
|
|
// CHECK: [[TERMINATE_BB]]:
|
|
|
|
|
// CHECK-NEXT: %[[CLEANUPPAD1:.*]] = cleanuppad within %[[CLEANUPPAD0]] []
|
[WebAssembly] Disable uses of __clang_call_terminate
Background:
Wasm EH, while using Windows EH (catchpad/cleanuppad based) IR, uses
Itanium-based libraries and ABIs with some modifications.
`__clang_call_terminate` is a wrapper generated in Clang's Itanium C++
ABI implementation. It contains this code, in C-style pseudocode:
```
void __clang_call_terminate(void *exn) {
__cxa_begin_catch(exn);
std::terminate();
}
```
So this function is a wrapper to call `__cxa_begin_catch` on the
exception pointer before termination.
In Itanium ABI, this function is called when another exception is thrown
while processing an exception. The pointer for this second, violating
exception is passed as the argument of this `__clang_call_terminate`,
which calls `__cxa_begin_catch` with that pointer and calls
`std::terminate` to terminate the program.
The spec (https://libcxxabi.llvm.org/spec.html) for `__cxa_begin_catch`
says,
```
When the personality routine encounters a termination condition, it
will call __cxa_begin_catch() to mark the exception as handled and then
call terminate(), which shall not return to its caller.
```
In wasm EH's Clang implementation, this function is called from
cleanuppads that terminates the program, which we also call terminate
pads. Cleanuppads normally don't access the thrown exception and the
wasm backend converts them to `catch_all` blocks. But because we need
the exception pointer in this cleanuppad, we generate
`wasm.get.exception` intrinsic (which will eventually be lowered to
`catch` instruction) as we do in the catchpads. But because terminate
pads are cleanup pads and should run even when a foreign exception is
thrown, so what we have been doing is:
1. In `WebAssemblyLateEHPrepare::ensureSingleBBTermPads()`, we make sure
terminate pads are in this simple shape:
```
%exn = catch
call @__clang_call_terminate(%exn)
unreachable
```
2. In `WebAssemblyHandleEHTerminatePads` pass at the end of the
pipeline, we attach a `catch_all` to terminate pads, so they will be in
this form:
```
%exn = catch
call @__clang_call_terminate(%exn)
unreachable
catch_all
call @std::terminate()
unreachable
```
In `catch_all` part, we don't have the exception pointer, so we call
`std::terminate()` directly. The reason we ran HandleEHTerminatePads at
the end of the pipeline, separate from LateEHPrepare, was it was
convenient to assume there was only a single `catch` part per `try`
during CFGSort and CFGStackify.
---
Problem:
While it thinks terminate pads could have been possibly split or calls
to `__clang_call_terminate` could have been duplicated,
`WebAssemblyLateEHPrepare::ensureSingleBBTermPads()` assumes terminate
pads contain no more than calls to `__clang_call_terminate` and
`unreachable` instruction. I assumed that because in LLVM very limited
forms of transformations are done to catchpads and cleanuppads to
maintain the scoping structure. But it turned out to be incorrect;
passes can merge cleanuppads into one, including terminate pads, as long
as the new code has a correct scoping structure. One pass that does this
I observed was `SimplifyCFG`, but there can be more. After this
transformation, a single cleanuppad can contain any number of other
instructions with the call to `__clang_call_terminate` and can span many
BBs. It wouldn't be practical to duplicate all these BBs within the
cleanuppad to generate the equivalent `catch_all` blocks, only with
calls to `__clang_call_terminate` replaced by calls to `std::terminate`.
Unless we do more complicated transformation to split those calls to
`__clang_call_terminate` into a separate cleanuppad, it is tricky to
solve.
---
Solution (?):
This CL just disables the generation and use of `__clang_call_terminate`
and calls `std::terminate()` directly in its place.
The possible downside of this approach can be, because the Itanium ABI
intended to "mark" the violating exception handled, we don't do that
anymore. What `__cxa_begin_catch` actually does is increment the
exception's handler count and decrement the uncaught exception count,
which in my opinion do not matter much given that we are about to
terminate the program anyway. Also it does not affect info like stack
traces that can be possibly shown to developers.
And while we use a variant of Itanium EH ABI, we can make some
deviations if we choose to; we are already different in that in the
current version of the EH spec we don't support two-phase unwinding. We
can possibly consider a more complicated transformation later to
reenable this, but I don't think that has high priority.
Changes in this CL contains:
- In Clang, we don't generate a call to `wasm.get.exception()` intrinsic
and `__clang_call_terminate` function in terminate pads anymore; we
simply generate calls to `std::terminate()`, which is the default
implementation of `CGCXXABI::emitTerminateForUnexpectedException`.
- Remove `WebAssembly::ensureSingleBBTermPads() function and
`WebAssemblyHandleEHTerminatePads` pass, because terminate pads are
already `catch_all` now (because they don't need the exception
pointer) and we don't need these transformations anymore.
- Change tests to use `std::terminate` directly. Also removes tests that
tested `LateEHPrepare::ensureSingleBBTermPads` and
`HandleEHTerminatePads` pass.
- Drive-by fix: Add some function attributes to EH intrinsic
declarations
Fixes https://github.com/emscripten-core/emscripten/issues/13582.
Reviewed By: dschuff, tlively
Differential Revision: https://reviews.llvm.org/D97834
2021-03-03 07:05:30 +08:00
|
|
|
// CHECK-NEXT: call void @_ZSt9terminatev() {{.*}} [ "funclet"(token %[[CLEANUPPAD1]]) ]
|
[WebAssembly] Use Windows EH instructions for Wasm EH
Summary:
Because wasm control flow needs to be structured, using WinEH
instructions to support wasm EH brings several benefits. This patch
makes wasm EH uses Windows EH instructions, with some changes:
1. Because wasm uses a single catch block to catch all C++ exceptions,
this merges all catch clauses into a single catchpad, within which we
test the EH selector as in Itanium EH.
2. Generates a call to `__clang_call_terminate` in case a cleanup
throws. Wasm does not have a runtime to handle this.
3. In case there is no catch-all clause, inserts a call to
`__cxa_rethrow` at the end of a catchpad in order to unwind to an
enclosing EH scope.
Reviewers: majnemer, dschuff
Subscribers: jfb, sbc100, jgravelle-google, sunfish, cfe-commits
Differential Revision: https://reviews.llvm.org/D44931
llvm-svn: 333703
2018-06-01 06:18:13 +08:00
|
|
|
// CHECK-NEXT: unreachable
|
|
|
|
|
|
|
|
|
|
// Try-catch with cleanups
|
|
|
|
|
void test6() {
|
|
|
|
|
Cleanup c1;
|
|
|
|
|
try {
|
|
|
|
|
Cleanup c2;
|
|
|
|
|
may_throw();
|
|
|
|
|
} catch (int) {
|
|
|
|
|
Cleanup c3;
|
|
|
|
|
may_throw();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// CHECK-LABEL: @_Z5test6v()
|
|
|
|
|
// CHECK: invoke void @_Z9may_throwv()
|
|
|
|
|
// CHECK-NEXT: to label %{{.*}} unwind label %[[EHCLEANUP_BB0:.*]]
|
|
|
|
|
|
|
|
|
|
// CHECK: [[EHCLEANUP_BB0]]:
|
|
|
|
|
// CHECK-NEXT: %[[CLEANUPPAD0:.*]] = cleanuppad within none []
|
2022-01-16 17:53:11 +08:00
|
|
|
// CHECK-NEXT: call noundef %struct.Cleanup* @_ZN7CleanupD1Ev(%struct.Cleanup* {{.*}}) {{.*}} [ "funclet"(token %[[CLEANUPPAD0]]) ]
|
[WebAssembly] Use Windows EH instructions for Wasm EH
Summary:
Because wasm control flow needs to be structured, using WinEH
instructions to support wasm EH brings several benefits. This patch
makes wasm EH uses Windows EH instructions, with some changes:
1. Because wasm uses a single catch block to catch all C++ exceptions,
this merges all catch clauses into a single catchpad, within which we
test the EH selector as in Itanium EH.
2. Generates a call to `__clang_call_terminate` in case a cleanup
throws. Wasm does not have a runtime to handle this.
3. In case there is no catch-all clause, inserts a call to
`__cxa_rethrow` at the end of a catchpad in order to unwind to an
enclosing EH scope.
Reviewers: majnemer, dschuff
Subscribers: jfb, sbc100, jgravelle-google, sunfish, cfe-commits
Differential Revision: https://reviews.llvm.org/D44931
llvm-svn: 333703
2018-06-01 06:18:13 +08:00
|
|
|
// CHECK-NEXT: cleanupret from %[[CLEANUPPAD0]] unwind label %[[CATCH_DISPATCH_BB:.*]]
|
|
|
|
|
|
|
|
|
|
// CHECK: [[CATCH_DISPATCH_BB]]:
|
|
|
|
|
// CHECK-NEXT: %[[CATCHSWITCH:.*]] = catchswitch within none [label %[[CATCHSTART_BB:.*]]] unwind label %[[EHCLEANUP_BB1:.*]]
|
|
|
|
|
|
|
|
|
|
// CHECK: [[CATCHSTART_BB]]:
|
|
|
|
|
// CHECK-NEXT: %[[CATCHPAD:.*]] = catchpad within %[[CATCHSWITCH]] [i8* bitcast (i8** @_ZTIi to i8*)]
|
|
|
|
|
// CHECK: br i1 %{{.*}}, label %[[CATCH_INT_BB:.*]], label %[[RETHROW_BB:.*]]
|
|
|
|
|
|
|
|
|
|
// CHECK: [[CATCH_INT_BB]]:
|
|
|
|
|
// CHECK: invoke void @_Z9may_throwv() [ "funclet"(token %[[CATCHPAD]]) ]
|
|
|
|
|
// CHECK-NEXT: to label %[[INVOKE_CONT_BB:.*]] unwind label %[[EHCLEANUP_BB2:.*]]
|
|
|
|
|
|
|
|
|
|
// CHECK: [[INVOKE_CONT_BB]]:
|
|
|
|
|
// CHECK: catchret from %[[CATCHPAD]] to label %{{.*}}
|
|
|
|
|
|
|
|
|
|
// CHECK: [[RETHROW_BB]]:
|
2020-12-26 08:14:35 +08:00
|
|
|
// CHECK-NEXT: invoke void @llvm.wasm.rethrow() {{.*}} [ "funclet"(token %[[CATCHPAD]]) ]
|
[WebAssembly] Use Windows EH instructions for Wasm EH
Summary:
Because wasm control flow needs to be structured, using WinEH
instructions to support wasm EH brings several benefits. This patch
makes wasm EH uses Windows EH instructions, with some changes:
1. Because wasm uses a single catch block to catch all C++ exceptions,
this merges all catch clauses into a single catchpad, within which we
test the EH selector as in Itanium EH.
2. Generates a call to `__clang_call_terminate` in case a cleanup
throws. Wasm does not have a runtime to handle this.
3. In case there is no catch-all clause, inserts a call to
`__cxa_rethrow` at the end of a catchpad in order to unwind to an
enclosing EH scope.
Reviewers: majnemer, dschuff
Subscribers: jfb, sbc100, jgravelle-google, sunfish, cfe-commits
Differential Revision: https://reviews.llvm.org/D44931
llvm-svn: 333703
2018-06-01 06:18:13 +08:00
|
|
|
// CHECK-NEXT: to label %[[UNREACHABLE_BB:.*]] unwind label %[[EHCLEANUP_BB1:.*]]
|
|
|
|
|
|
|
|
|
|
// CHECK: [[EHCLEANUP_BB2]]:
|
|
|
|
|
// CHECK-NEXT: %[[CLEANUPPAD2:.*]] = cleanuppad within %[[CATCHPAD]] []
|
2022-01-16 17:53:11 +08:00
|
|
|
// CHECK-NEXT: call noundef %struct.Cleanup* @_ZN7CleanupD1Ev(%struct.Cleanup* {{[^,]*}} %{{.*}}) {{.*}} [ "funclet"(token %[[CLEANUPPAD2]]) ]
|
[WebAssembly] Use Windows EH instructions for Wasm EH
Summary:
Because wasm control flow needs to be structured, using WinEH
instructions to support wasm EH brings several benefits. This patch
makes wasm EH uses Windows EH instructions, with some changes:
1. Because wasm uses a single catch block to catch all C++ exceptions,
this merges all catch clauses into a single catchpad, within which we
test the EH selector as in Itanium EH.
2. Generates a call to `__clang_call_terminate` in case a cleanup
throws. Wasm does not have a runtime to handle this.
3. In case there is no catch-all clause, inserts a call to
`__cxa_rethrow` at the end of a catchpad in order to unwind to an
enclosing EH scope.
Reviewers: majnemer, dschuff
Subscribers: jfb, sbc100, jgravelle-google, sunfish, cfe-commits
Differential Revision: https://reviews.llvm.org/D44931
llvm-svn: 333703
2018-06-01 06:18:13 +08:00
|
|
|
// CHECK-NEXT: cleanupret from %[[CLEANUPPAD2]] unwind label %[[EHCLEANUP_BB3:.*]]
|
|
|
|
|
|
|
|
|
|
// CHECK: [[EHCLEANUP_BB3]]:
|
|
|
|
|
// CHECK-NEXT: %[[CLEANUPPAD3:.*]] = cleanuppad within %[[CATCHPAD]] []
|
|
|
|
|
// CHECK: cleanupret from %[[CLEANUPPAD3]] unwind label %[[EHCLEANUP_BB1:.*]]
|
|
|
|
|
|
|
|
|
|
// CHECK: [[EHCLEANUP_BB1]]:
|
|
|
|
|
// CHECK-NEXT: %[[CLEANUPPAD1:.*]] = cleanuppad within none []
|
2022-01-16 17:53:11 +08:00
|
|
|
// CHECK-NEXT: call noundef %struct.Cleanup* @_ZN7CleanupD1Ev(%struct.Cleanup* {{[^,]*}} %{{.*}}) {{.*}} [ "funclet"(token %[[CLEANUPPAD1]]) ]
|
[WebAssembly] Use Windows EH instructions for Wasm EH
Summary:
Because wasm control flow needs to be structured, using WinEH
instructions to support wasm EH brings several benefits. This patch
makes wasm EH uses Windows EH instructions, with some changes:
1. Because wasm uses a single catch block to catch all C++ exceptions,
this merges all catch clauses into a single catchpad, within which we
test the EH selector as in Itanium EH.
2. Generates a call to `__clang_call_terminate` in case a cleanup
throws. Wasm does not have a runtime to handle this.
3. In case there is no catch-all clause, inserts a call to
`__cxa_rethrow` at the end of a catchpad in order to unwind to an
enclosing EH scope.
Reviewers: majnemer, dschuff
Subscribers: jfb, sbc100, jgravelle-google, sunfish, cfe-commits
Differential Revision: https://reviews.llvm.org/D44931
llvm-svn: 333703
2018-06-01 06:18:13 +08:00
|
|
|
// CHECK-NEXT: cleanupret from %[[CLEANUPPAD1]] unwind to caller
|
|
|
|
|
|
|
|
|
|
// CHECK: [[UNREACHABLE_BB]]:
|
|
|
|
|
// CHECK-NEXT: unreachable
|
|
|
|
|
|
|
|
|
|
// Nested try-catches within a try with cleanups
|
|
|
|
|
void test7() {
|
|
|
|
|
Cleanup c1;
|
|
|
|
|
may_throw();
|
|
|
|
|
try {
|
|
|
|
|
Cleanup c2;
|
|
|
|
|
may_throw();
|
|
|
|
|
try {
|
|
|
|
|
Cleanup c3;
|
|
|
|
|
may_throw();
|
|
|
|
|
} catch (int) {
|
|
|
|
|
may_throw();
|
|
|
|
|
} catch (double) {
|
|
|
|
|
may_throw();
|
|
|
|
|
}
|
|
|
|
|
} catch (int) {
|
|
|
|
|
may_throw();
|
|
|
|
|
} catch (...) {
|
|
|
|
|
may_throw();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// CHECK-LABEL: @_Z5test7v()
|
|
|
|
|
// CHECK: invoke void @_Z9may_throwv()
|
|
|
|
|
|
|
|
|
|
// CHECK: invoke void @_Z9may_throwv()
|
|
|
|
|
|
|
|
|
|
// CHECK: invoke void @_Z9may_throwv()
|
|
|
|
|
|
|
|
|
|
// CHECK: %[[CLEANUPPAD0:.*]] = cleanuppad within none []
|
|
|
|
|
// CHECK: cleanupret from %[[CLEANUPPAD0]] unwind label
|
|
|
|
|
|
|
|
|
|
// CHECK: %[[CATCHSWITCH0:.*]] = catchswitch within none
|
|
|
|
|
|
|
|
|
|
// CHECK: %[[CATCHPAD0:.*]] = catchpad within %[[CATCHSWITCH0]] [i8* bitcast (i8** @_ZTIi to i8*), i8* bitcast (i8** @_ZTId to i8*)]
|
|
|
|
|
|
|
|
|
|
// CHECK: invoke void @_Z9may_throwv() [ "funclet"(token %[[CATCHPAD0]]) ]
|
|
|
|
|
|
|
|
|
|
// CHECK: catchret from %[[CATCHPAD0]] to label
|
|
|
|
|
|
|
|
|
|
// CHECK: invoke void @_Z9may_throwv() [ "funclet"(token %[[CATCHPAD0]]) ]
|
|
|
|
|
|
|
|
|
|
// CHECK: catchret from %[[CATCHPAD0]] to label
|
|
|
|
|
|
2020-12-26 08:14:35 +08:00
|
|
|
// CHECK: invoke void @llvm.wasm.rethrow() {{.*}} [ "funclet"(token %[[CATCHPAD0]]) ]
|
[WebAssembly] Use Windows EH instructions for Wasm EH
Summary:
Because wasm control flow needs to be structured, using WinEH
instructions to support wasm EH brings several benefits. This patch
makes wasm EH uses Windows EH instructions, with some changes:
1. Because wasm uses a single catch block to catch all C++ exceptions,
this merges all catch clauses into a single catchpad, within which we
test the EH selector as in Itanium EH.
2. Generates a call to `__clang_call_terminate` in case a cleanup
throws. Wasm does not have a runtime to handle this.
3. In case there is no catch-all clause, inserts a call to
`__cxa_rethrow` at the end of a catchpad in order to unwind to an
enclosing EH scope.
Reviewers: majnemer, dschuff
Subscribers: jfb, sbc100, jgravelle-google, sunfish, cfe-commits
Differential Revision: https://reviews.llvm.org/D44931
llvm-svn: 333703
2018-06-01 06:18:13 +08:00
|
|
|
|
|
|
|
|
// CHECK: %[[CLEANUPPAD1:.*]] = cleanuppad within %[[CATCHPAD0]] []
|
|
|
|
|
// CHECK: cleanupret from %[[CLEANUPPAD1]] unwind label
|
|
|
|
|
|
|
|
|
|
// CHECK: %[[CLEANUPPAD2:.*]] = cleanuppad within %[[CATCHPAD0]] []
|
|
|
|
|
// CHECK: cleanupret from %[[CLEANUPPAD2]] unwind label
|
|
|
|
|
|
|
|
|
|
// CHECK: %[[CLEANUPPAD3:.*]] = cleanuppad within none []
|
|
|
|
|
// CHECK: cleanupret from %[[CLEANUPPAD3]] unwind label
|
|
|
|
|
|
|
|
|
|
// CHECK: %[[CATCHSWITCH1:.*]] = catchswitch within none
|
|
|
|
|
|
|
|
|
|
// CHECK: %[[CATCHPAD1:.*]] = catchpad within %[[CATCHSWITCH1]] [i8* bitcast (i8** @_ZTIi to i8*), i8* null]
|
|
|
|
|
|
|
|
|
|
// CHECK: invoke void @_Z9may_throwv() [ "funclet"(token %[[CATCHPAD1]]) ]
|
|
|
|
|
|
|
|
|
|
// CHECK: catchret from %[[CATCHPAD1]] to label
|
|
|
|
|
|
|
|
|
|
// CHECK: invoke void @_Z9may_throwv() [ "funclet"(token %[[CATCHPAD1]]) ]
|
|
|
|
|
|
|
|
|
|
// CHECK: invoke void @__cxa_end_catch() [ "funclet"(token %[[CATCHPAD1]]) ]
|
|
|
|
|
|
|
|
|
|
// CHECK: catchret from %[[CATCHPAD1]] to label
|
|
|
|
|
|
|
|
|
|
// CHECK: %[[CLEANUPPAD4:.*]] = cleanuppad within %[[CATCHPAD1]] []
|
|
|
|
|
// CHECK: invoke void @__cxa_end_catch() [ "funclet"(token %[[CLEANUPPAD4]]) ]
|
|
|
|
|
|
|
|
|
|
// CHECK: cleanupret from %[[CLEANUPPAD4]] unwind label
|
|
|
|
|
|
|
|
|
|
// CHECK: %[[CLEANUPPAD5:.*]] = cleanuppad within %[[CATCHPAD1]] []
|
|
|
|
|
// CHECK: cleanupret from %[[CLEANUPPAD5]] unwind label
|
|
|
|
|
|
|
|
|
|
// CHECK: %[[CLEANUPPAD6:.*]] = cleanuppad within none []
|
|
|
|
|
// CHECK: cleanupret from %[[CLEANUPPAD6]] unwind to caller
|
|
|
|
|
|
|
|
|
|
// CHECK: unreachable
|
|
|
|
|
|
|
|
|
|
// CHECK: %[[CLEANUPPAD7:.*]] = cleanuppad within %[[CLEANUPPAD4]] []
|
[WebAssembly] Disable uses of __clang_call_terminate
Background:
Wasm EH, while using Windows EH (catchpad/cleanuppad based) IR, uses
Itanium-based libraries and ABIs with some modifications.
`__clang_call_terminate` is a wrapper generated in Clang's Itanium C++
ABI implementation. It contains this code, in C-style pseudocode:
```
void __clang_call_terminate(void *exn) {
__cxa_begin_catch(exn);
std::terminate();
}
```
So this function is a wrapper to call `__cxa_begin_catch` on the
exception pointer before termination.
In Itanium ABI, this function is called when another exception is thrown
while processing an exception. The pointer for this second, violating
exception is passed as the argument of this `__clang_call_terminate`,
which calls `__cxa_begin_catch` with that pointer and calls
`std::terminate` to terminate the program.
The spec (https://libcxxabi.llvm.org/spec.html) for `__cxa_begin_catch`
says,
```
When the personality routine encounters a termination condition, it
will call __cxa_begin_catch() to mark the exception as handled and then
call terminate(), which shall not return to its caller.
```
In wasm EH's Clang implementation, this function is called from
cleanuppads that terminates the program, which we also call terminate
pads. Cleanuppads normally don't access the thrown exception and the
wasm backend converts them to `catch_all` blocks. But because we need
the exception pointer in this cleanuppad, we generate
`wasm.get.exception` intrinsic (which will eventually be lowered to
`catch` instruction) as we do in the catchpads. But because terminate
pads are cleanup pads and should run even when a foreign exception is
thrown, so what we have been doing is:
1. In `WebAssemblyLateEHPrepare::ensureSingleBBTermPads()`, we make sure
terminate pads are in this simple shape:
```
%exn = catch
call @__clang_call_terminate(%exn)
unreachable
```
2. In `WebAssemblyHandleEHTerminatePads` pass at the end of the
pipeline, we attach a `catch_all` to terminate pads, so they will be in
this form:
```
%exn = catch
call @__clang_call_terminate(%exn)
unreachable
catch_all
call @std::terminate()
unreachable
```
In `catch_all` part, we don't have the exception pointer, so we call
`std::terminate()` directly. The reason we ran HandleEHTerminatePads at
the end of the pipeline, separate from LateEHPrepare, was it was
convenient to assume there was only a single `catch` part per `try`
during CFGSort and CFGStackify.
---
Problem:
While it thinks terminate pads could have been possibly split or calls
to `__clang_call_terminate` could have been duplicated,
`WebAssemblyLateEHPrepare::ensureSingleBBTermPads()` assumes terminate
pads contain no more than calls to `__clang_call_terminate` and
`unreachable` instruction. I assumed that because in LLVM very limited
forms of transformations are done to catchpads and cleanuppads to
maintain the scoping structure. But it turned out to be incorrect;
passes can merge cleanuppads into one, including terminate pads, as long
as the new code has a correct scoping structure. One pass that does this
I observed was `SimplifyCFG`, but there can be more. After this
transformation, a single cleanuppad can contain any number of other
instructions with the call to `__clang_call_terminate` and can span many
BBs. It wouldn't be practical to duplicate all these BBs within the
cleanuppad to generate the equivalent `catch_all` blocks, only with
calls to `__clang_call_terminate` replaced by calls to `std::terminate`.
Unless we do more complicated transformation to split those calls to
`__clang_call_terminate` into a separate cleanuppad, it is tricky to
solve.
---
Solution (?):
This CL just disables the generation and use of `__clang_call_terminate`
and calls `std::terminate()` directly in its place.
The possible downside of this approach can be, because the Itanium ABI
intended to "mark" the violating exception handled, we don't do that
anymore. What `__cxa_begin_catch` actually does is increment the
exception's handler count and decrement the uncaught exception count,
which in my opinion do not matter much given that we are about to
terminate the program anyway. Also it does not affect info like stack
traces that can be possibly shown to developers.
And while we use a variant of Itanium EH ABI, we can make some
deviations if we choose to; we are already different in that in the
current version of the EH spec we don't support two-phase unwinding. We
can possibly consider a more complicated transformation later to
reenable this, but I don't think that has high priority.
Changes in this CL contains:
- In Clang, we don't generate a call to `wasm.get.exception()` intrinsic
and `__clang_call_terminate` function in terminate pads anymore; we
simply generate calls to `std::terminate()`, which is the default
implementation of `CGCXXABI::emitTerminateForUnexpectedException`.
- Remove `WebAssembly::ensureSingleBBTermPads() function and
`WebAssemblyHandleEHTerminatePads` pass, because terminate pads are
already `catch_all` now (because they don't need the exception
pointer) and we don't need these transformations anymore.
- Change tests to use `std::terminate` directly. Also removes tests that
tested `LateEHPrepare::ensureSingleBBTermPads` and
`HandleEHTerminatePads` pass.
- Drive-by fix: Add some function attributes to EH intrinsic
declarations
Fixes https://github.com/emscripten-core/emscripten/issues/13582.
Reviewed By: dschuff, tlively
Differential Revision: https://reviews.llvm.org/D97834
2021-03-03 07:05:30 +08:00
|
|
|
// CHECK: call void @_ZSt9terminatev() {{.*}} [ "funclet"(token %[[CLEANUPPAD7]]) ]
|
[WebAssembly] Use Windows EH instructions for Wasm EH
Summary:
Because wasm control flow needs to be structured, using WinEH
instructions to support wasm EH brings several benefits. This patch
makes wasm EH uses Windows EH instructions, with some changes:
1. Because wasm uses a single catch block to catch all C++ exceptions,
this merges all catch clauses into a single catchpad, within which we
test the EH selector as in Itanium EH.
2. Generates a call to `__clang_call_terminate` in case a cleanup
throws. Wasm does not have a runtime to handle this.
3. In case there is no catch-all clause, inserts a call to
`__cxa_rethrow` at the end of a catchpad in order to unwind to an
enclosing EH scope.
Reviewers: majnemer, dschuff
Subscribers: jfb, sbc100, jgravelle-google, sunfish, cfe-commits
Differential Revision: https://reviews.llvm.org/D44931
llvm-svn: 333703
2018-06-01 06:18:13 +08:00
|
|
|
// CHECK: unreachable
|
|
|
|
|
|
|
|
|
|
// Nested try-catches within a catch
|
|
|
|
|
void test8() {
|
|
|
|
|
try {
|
|
|
|
|
may_throw();
|
|
|
|
|
} catch (int) {
|
|
|
|
|
try {
|
|
|
|
|
may_throw();
|
|
|
|
|
} catch (int) {
|
|
|
|
|
may_throw();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// CHECK-LABEL: @_Z5test8v()
|
|
|
|
|
// CHECK: invoke void @_Z9may_throwv()
|
|
|
|
|
|
|
|
|
|
// CHECK: %[[CATCHSWITCH0:.*]] = catchswitch within none
|
|
|
|
|
|
|
|
|
|
// CHECK: %[[CATCHPAD0:.*]] = catchpad within %[[CATCHSWITCH0]] [i8* bitcast (i8** @_ZTIi to i8*)]
|
|
|
|
|
|
|
|
|
|
// CHECK: invoke void @_Z9may_throwv() [ "funclet"(token %[[CATCHPAD0]]) ]
|
|
|
|
|
|
|
|
|
|
// CHECK: %[[CATCHSWITCH1:.*]] = catchswitch within %[[CATCHPAD0]]
|
|
|
|
|
|
|
|
|
|
// CHECK: %[[CATCHPAD1:.*]] = catchpad within %[[CATCHSWITCH1]] [i8* bitcast (i8** @_ZTIi to i8*)]
|
|
|
|
|
|
|
|
|
|
// CHECK: invoke void @_Z9may_throwv() [ "funclet"(token %[[CATCHPAD1]]) ]
|
|
|
|
|
|
|
|
|
|
// CHECK: catchret from %[[CATCHPAD1]] to label
|
|
|
|
|
|
2020-12-26 08:14:35 +08:00
|
|
|
// CHECK: invoke void @llvm.wasm.rethrow() {{.*}} [ "funclet"(token %[[CATCHPAD1]]) ]
|
[WebAssembly] Use Windows EH instructions for Wasm EH
Summary:
Because wasm control flow needs to be structured, using WinEH
instructions to support wasm EH brings several benefits. This patch
makes wasm EH uses Windows EH instructions, with some changes:
1. Because wasm uses a single catch block to catch all C++ exceptions,
this merges all catch clauses into a single catchpad, within which we
test the EH selector as in Itanium EH.
2. Generates a call to `__clang_call_terminate` in case a cleanup
throws. Wasm does not have a runtime to handle this.
3. In case there is no catch-all clause, inserts a call to
`__cxa_rethrow` at the end of a catchpad in order to unwind to an
enclosing EH scope.
Reviewers: majnemer, dschuff
Subscribers: jfb, sbc100, jgravelle-google, sunfish, cfe-commits
Differential Revision: https://reviews.llvm.org/D44931
llvm-svn: 333703
2018-06-01 06:18:13 +08:00
|
|
|
|
|
|
|
|
// CHECK: catchret from %[[CATCHPAD0]] to label
|
|
|
|
|
|
2020-12-26 08:14:35 +08:00
|
|
|
// CHECK: call void @llvm.wasm.rethrow() {{.*}} [ "funclet"(token %[[CATCHPAD0]]) ]
|
[WebAssembly] Use Windows EH instructions for Wasm EH
Summary:
Because wasm control flow needs to be structured, using WinEH
instructions to support wasm EH brings several benefits. This patch
makes wasm EH uses Windows EH instructions, with some changes:
1. Because wasm uses a single catch block to catch all C++ exceptions,
this merges all catch clauses into a single catchpad, within which we
test the EH selector as in Itanium EH.
2. Generates a call to `__clang_call_terminate` in case a cleanup
throws. Wasm does not have a runtime to handle this.
3. In case there is no catch-all clause, inserts a call to
`__cxa_rethrow` at the end of a catchpad in order to unwind to an
enclosing EH scope.
Reviewers: majnemer, dschuff
Subscribers: jfb, sbc100, jgravelle-google, sunfish, cfe-commits
Differential Revision: https://reviews.llvm.org/D44931
llvm-svn: 333703
2018-06-01 06:18:13 +08:00
|
|
|
// CHECK: unreachable
|
|
|
|
|
|
|
|
|
|
// CHECK: %[[CLEANUPPAD0:.*]] = cleanuppad within %[[CATCHPAD1]] []
|
|
|
|
|
// CHECK: cleanupret from %[[CLEANUPPAD0]] unwind label
|
|
|
|
|
|
|
|
|
|
// CHECK: %[[CLEANUPPAD1:.*]] = cleanuppad within %[[CATCHPAD0]] []
|
|
|
|
|
// CHECK: cleanupret from %[[CLEANUPPAD1]] unwind to caller
|
|
|
|
|
|
|
|
|
|
// CHECK: unreachable
|
2019-09-12 12:01:37 +08:00
|
|
|
|
2020-12-15 16:59:19 +08:00
|
|
|
// RUN: %clang_cc1 %s -triple wasm32-unknown-unknown -fms-extensions -fexceptions -fcxx-exceptions -exception-model=wasm -target-feature +exception-handling -emit-llvm -o - -std=c++11 2>&1 | FileCheck %s --check-prefix=WARNING-DEFAULT
|
|
|
|
|
// RUN: %clang_cc1 %s -triple wasm32-unknown-unknown -fms-extensions -fexceptions -fcxx-exceptions -exception-model=wasm -target-feature +exception-handling -Wwasm-exception-spec -emit-llvm -o - -std=c++11 2>&1 | FileCheck %s --check-prefix=WARNING-ON
|
|
|
|
|
// RUN: %clang_cc1 %s -triple wasm32-unknown-unknown -fms-extensions -fexceptions -fcxx-exceptions -exception-model=wasm -target-feature +exception-handling -Wno-wasm-exception-spec -emit-llvm -o - -std=c++11 2>&1 | FileCheck %s --check-prefix=WARNING-OFF
|
2021-05-19 16:47:58 +08:00
|
|
|
// RUN: %clang_cc1 %s -triple wasm32-unknown-unknown -fexceptions -fcxx-exceptions -emit-llvm -o - -std=c++11 2>&1 | FileCheck %s --check-prefix=EM-EH-WARNING
|
2020-05-09 07:19:46 +08:00
|
|
|
|
2020-05-21 14:02:41 +08:00
|
|
|
// Wasm EH ignores dynamic exception specifications with types at the moment.
|
|
|
|
|
// This is controlled by -Wwasm-exception-spec, which is on by default. This
|
|
|
|
|
// warning can be suppressed with -Wno-wasm-exception-spec. Checks if a warning
|
|
|
|
|
// message is correctly printed or not printed depending on the options.
|
2020-05-09 07:19:46 +08:00
|
|
|
void test9() throw(int) {
|
|
|
|
|
}
|
|
|
|
|
// WARNING-DEFAULT: warning: dynamic exception specifications with types are currently ignored in wasm
|
|
|
|
|
// WARNING-ON: warning: dynamic exception specifications with types are currently ignored in wasm
|
|
|
|
|
// WARNING-OFF-NOT: warning: dynamic exception specifications with types are currently ignored in wasm
|
2021-05-19 16:47:58 +08:00
|
|
|
// EM-EH-WARNING: warning: dynamic exception specifications with types are currently ignored in wasm
|
2020-05-09 07:19:46 +08:00
|
|
|
|
|
|
|
|
// Wasm curremtly treats 'throw()' in the same way as 'noexept'. Check if the
|
|
|
|
|
// same warning message is printed as if when a 'noexcept' function throws.
|
|
|
|
|
void test10() throw() {
|
|
|
|
|
throw 3;
|
|
|
|
|
}
|
|
|
|
|
// WARNING-DEFAULT: warning: 'test10' has a non-throwing exception specification but can still throw
|
|
|
|
|
// WARNING-DEFAULT: function declared non-throwing here
|
|
|
|
|
|
2019-09-12 12:01:37 +08:00
|
|
|
// Here we only check if the command enables wasm exception handling in the
|
|
|
|
|
// backend so that exception handling instructions can be generated in .s file.
|
|
|
|
|
|
[WebAssembly] Tidy up EH/SjLj options
This CL is small, but the description can be a little long because I'm
trying to sum up the status quo for Emscripten/Wasm EH/SjLj options.
First, this CL adds an option for Wasm SjLj (`-wasm-enable-sjlj`), which
handles SjLj using Wasm EH. The implementation for this will be added as
a followup CL, but this adds the option first to do error checking.
This also adds an option for Wasm EH (`-wasm-enable-eh`), which has been
already implemented. Before we used `-exception-model=wasm` as the same
meaning as enabling Wasm EH, but after we add Wasm SjLj, it will be
possible to use Wasm EH instructions for Wasm SjLj while not enabling
EH, so going forward, to use Wasm EH, `opt` and `llc` will need this
option. This only affects `opt` and `llc` command lines and does not
affect Emscripten user interface.
Now we have two modes of EH (Emscripten/Wasm) and also two modes of SjLj
(also Emscripten/Wasm). The options corresponding to each of are:
- Emscripten EH: `-enable-emscripten-cxx-exceptions`
- Emscripten SjLj: `-enable-emscripten-sjlj`
- Wasm EH: `-wasm-enable-eh -exception-model=wasm`
`-mattr=+exception-handling`
- Wasm SjLj: `-wasm-enable-sjlj -exception-model=wasm`
`-mattr=+exception-handling`
The reason Wasm EH/SjLj's options are a little complicated are
`-exception-model` and `-mattr` are common LLVM options ane not under
our control. (`-mattr` can be omitted if it is embedded within the
bitcode file.)
And we have the following rules of the option composition:
- Emscripten EH and Wasm EH cannot be turned on at the same itme
- Emscripten SjLj and Wasm SjLj cannot be turned on at the same time
- Wasm SjLj should be used with Wasm EH
Which means we now allow these combinations:
- Emscripten EH + Emscripten SjLj: the current default in `emcc`
- Wasm EH + Emscripten SjLj:
This is allowed, but only as an interim step in which we are testing
Wasm EH but not yet have a working implementation of Wasm SjLj. This
will error out (D107687) in compile time if `setjmp` is called in a
function in which Wasm exception is used.
- Wasm EH + Wasm SjLj:
This will be the default mode later when using Wasm EH. Currently Wasm
SjLj implementation doesn't exist, so it doesn't work.
- Emscripten EH + Wasm SjLj will not work.
This CL moves these error checking routines to
`WebAssemblyPassConfig::addIRPasses`. Not sure if this is an ideal place
to do this, but I couldn't find elsewhere. Currently some checking is
done within LowerEmscriptenEHSjLj, but these checks only run if
LowerEmscriptenEHSjLj runs so it may not run when Wasm EH is used. This
moves that to `addIRPasses` and adds some more checks.
Currently LowerEmscriptenEHSjLj pass is responsible for Emscripten EH
and Emscripten SjLj. Wasm EH transformations are done in multiple
places, including WasmEHPrepare, LateEHPrepare, and CFGStackify. But in
the followup CL, LowerEmscriptenEHSjLj pass will be also responsible for
a part of Wasm SjLj transformation, because WasmSjLj will also be using
several Emscripten library functions, and we will be sharing more than
half of the transformation to do that between Emscripten SjLj and Wasm
SjLj.
Currently we have `-enable-emscripten-cxx-exceptions` and
`-enable-emscripten-sjlj` but these only work for `llc`, because for
`llc` we feed these options to the pass but when we run the pass using
`opt` the pass will be created with no options and the default options
will be used, which turns both Emscripten EH and Emscripten SjLj on.
Now we have one more SjLj option to care for, LowerEmscriptenEHSjLj pass
needs a finer way to control these options. This CL removes those
default parameters and make LowerEmscriptenEHSjLj pass read directly
from command line options specified. So if we only run
`opt -wasm-lower-em-ehsjlj`, currently both Emscripten EH and Emscripten
SjLj will run, but with this CL, none will run unless we additionally
pass `-enable-emscripten-cxx-exceptions` or `-enable-emscripten-sjlj`,
or both. This does not affect users; this only affects our `opt` tests
because `emcc` will not call either `opt` or `llc`. As a result of this,
our existing Emscripten EH/SjLj tests gained one or both of those
options in their `RUN` lines.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D107685
2021-08-07 10:35:18 +08:00
|
|
|
// RUN: %clang_cc1 %s -triple wasm32-unknown-unknown -fms-extensions -fexceptions -fcxx-exceptions -mllvm -wasm-enable-eh -exception-model=wasm -target-feature +exception-handling -S -o - -std=c++11 | FileCheck %s --check-prefix=ASSEMBLY
|
2020-05-09 07:19:46 +08:00
|
|
|
|
2019-09-12 12:01:37 +08:00
|
|
|
// ASSEMBLY: try
|
|
|
|
|
// ASSEMBLY: catch
|
|
|
|
|
// ASSEMBLY: rethrow
|
|
|
|
|
// ASSEMBLY: end_try
|