4 Commits

Author SHA1 Message Date
Nikita Popov
d35fcf0e97 [WebAssembly] Use default attributes for intrinsics
This switches wasm intrinsics to use default attributes,
i.e. nofree, nosync, nocallback and willreturn. Especially
willreturn will be required to avoid optimization regressions
in the future.

The attributes are omitted from the trapping fptoi intrinsics
(where I assume trapping is considered well-defined, and as such
these aren't willreturn), the throw/rethrow intrinsics (which
will unwind) and the atomic intrinsics (which aren't nosync).

Differential Revision: https://reviews.llvm.org/D137551
2022-11-07 17:05:36 +01:00
Heejin Ahn
4f1244d7cc [WebAssembly] Nullify unnecessary setjmp invokes
This is similar to D116619, but now it handles `invoke`s. The reason we
didn't handle `invoke`s back then was we didn't support Wasm EH + Wasm
SjLj together, and the only case SjLj transformation will see `invoke`s
is when we are using Wasm EH. (In Emscripten EH, they would have been
transformed to `call`s to invoke wrappers.)

But after D117610 we support Wasm EH + Wasm SjLj together and we can
nullify `invoke`s to `setjmp` when there is no other longjmpable calls
within the function. Actually this is very unlikely to happen in
practice, because we treat destructors as longjmpable and also treat
`__cxa_end_catch` as longjmpable even if it is not.

Reviewed By: dschuff

Differential Revision: https://reviews.llvm.org/D118408
2022-01-27 21:11:10 -08:00
Heejin Ahn
20c1d9ce5e [WebAssembly] Handle cleanuppad with no parent in Wasm SjLj
Wasm SjLj converts longjmpable calls into `invoke`s that unwind to
`%catch.longjmp.dispatch` BB, from where we check if the thrown
exception is a `longjmp`. But in case a call already has a `funclet`
attribute, i.e., it is within a catch scope, we have to unwind to its
unwind destination first to preserve the scoping structure. That will
eventually unwind to `%catch.longjmp.dispatch`, because all
`catchswitch` and `cleanupret` that unwind to caller are redirected to
`%catch.dispatch.longjmp` during Wasm SjLj transformation.

But the prevous code assumed `cleanuppad`'s parent pad was always an
instruction, and didn't handle when a `cleanuppad`'s parent is `none`.
This CL handles this case, and makes the `while` loop more intuitive by
removing `FromPad` condition and explicitly inserting `break`s.

Reviewed By: dschuff

Differential Revision: https://reviews.llvm.org/D118407
2022-01-27 21:10:23 -08:00
Heejin Ahn
eb675e972d [WebAssembly] Support Wasm EH + Wasm SjLj
D108960 added support for SjLj using Wasm EH instructions, which we call
Wasm SjLj going forward. (We call the old SjLj Emscripten SjLj) But it
did not support using Wasm EH and Wasm SjLj together. So far users of
Wasm EH had to use Wasm EH with Emscripten SjLj, which had a certain
limitation and it suffered from bigger code size increases as well.

This enables using Wasm EH and Wasm SjLj together.
1. This redirects `catchswitch` and `cleanupret` that unwind to caller
   to `catch.dispatch.longjmp` BB, which is a `catchswitch` BB that
   handles longjmps.
2. D108960 converted all longjmpable `call`s to `invokes` that unwind to
   `catch.dispatch.longjmp`. This CL checks if the `call` is embedded
   within another `catchpad`, and if so, makes it unwind to its nearest
   parent's unwind destination, rather than `catch.dispatch.longjmp`.
   This is necessary to preserve the scoping structure.

Reviewed By: dschuff

Differential Revision: https://reviews.llvm.org/D117610
2022-01-19 20:13:54 -08:00