|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init |
|
| #
122b0220 |
| 14-Jul-2021 |
Thomas Lively <[email protected]> |
[WebAssembly] Remove datalayout strings from llc tests
The data layout strings do not have any effect on llc tests and will become misleadingly out of date as we continue to update the canonical dat
[WebAssembly] Remove datalayout strings from llc tests
The data layout strings do not have any effect on llc tests and will become misleadingly out of date as we continue to update the canonical data layout, so remove them from the tests.
Differential Revision: https://reviews.llvm.org/D105842
show more ...
|
|
Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1 |
|
| #
c390621a |
| 22-Apr-2021 |
Heejin Ahn <[email protected]> |
[WebAssembly] Fix fixEndsAtEndOfFunction for delegate
Background: CFGStackify's [[ https://github.com/llvm/llvm-project/blob/398f25340000f26d648ebbc7eae9dc401ffc7d5f/llvm/lib/Target/WebAssembly/WebA
[WebAssembly] Fix fixEndsAtEndOfFunction for delegate
Background: CFGStackify's [[ https://github.com/llvm/llvm-project/blob/398f25340000f26d648ebbc7eae9dc401ffc7d5f/llvm/lib/Target/WebAssembly/WebAssemblyCFGStackify.cpp#L1481-L1540 | fixEndsAtEndOfFunction ]] fixes block/loop/try's return type when the end of function is unreachable and the function return type is not void. So if a function returns i32 and `block`-`end` wraps the whole function, i.e., the `block`'s `end` is the last instruction of the function, the `block`'s return type should be i32 too: ``` block i32 ... end end_function ```
If there are consecutive `end`s, this signature has to be propagate to those blocks too, like: ``` block i32 ... block i32 ... end end end_function ```
This applies to `try`-`end` too: ``` try i32 ... catch ... end end_function ```
In case of `try`, we not only follow consecutive `end`s but also follow `catch`, because for the type of the whole `try` to be i32, both `try` and `catch` parts have to be i32: ``` try i32 ... block i32 ... end catch ... block i32 ... end end end_function ```
---
Previously we only handled consecutive `end`s or `end` before a `catch`. But now we have `delegate`, which serves like `end` for `try`-`delegate`. So we have to follow `delegate` too and mark its corresponding `try` as i32 (the function's return type): ``` try i32 ... catch ... try i32 ;; Here ... delegate N end end_function ```
Reviewed By: tlively
Differential Revision: https://reviews.llvm.org/D101036
show more ...
|
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2 |
|
| #
908643ad |
| 22-Feb-2021 |
Heejin Ahn <[email protected]> |
[WebAssembly] Split EH MIR tests into two files
Currently exception.mir runs LateEHPrepare and CFGStackify, but some tests I'm planning to add shouldn't be run with LateEHPrepare, because it is conv
[WebAssembly] Split EH MIR tests into two files
Currently exception.mir runs LateEHPrepare and CFGStackify, but some tests I'm planning to add shouldn't be run with LateEHPrepare, because it is convenient to only run CFGStackify when testing things like unwind mismatches and it is easier to add tests that are in phase right before CFGStackify. This splits existing exception.mir into two files; cfg-stackify-eh.mir will only run CFGStackify. Note that `eh_label_tests` tests both LateEHPrepare and CFGStackify, so it is still in exception.mir. `rethrow_arg_tests` has been converted to the post-LateEHPrepare form to be moved into cfg-stackify-eh.mir, like removing `CATCHRET` and such, because it does not really test anything in LateEHPrepare.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D97175
show more ...
|
|
Revision tags: llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
| #
6a87ddac |
| 08-Jan-2019 |
Thomas Lively <[email protected]> |
[WebAssembly] Massive instruction renaming
Summary: An automated renaming of all the instructions listed at https://github.com/WebAssembly/spec/issues/884#issuecomment-426433329 as well as some simi
[WebAssembly] Massive instruction renaming
Summary: An automated renaming of all the instructions listed at https://github.com/WebAssembly/spec/issues/884#issuecomment-426433329 as well as some similarly-named identifiers.
Reviewers: aheejin, dschuff, aardappel
Subscribers: sbc100, jgravelle-google, eraman, sunfish, jfb, llvm-commits
Differential Revision: https://reviews.llvm.org/D56338
llvm-svn: 350609
show more ...
|
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1 |
|
| #
ac764aa8 |
| 24-Oct-2018 |
Heejin Ahn <[email protected]> |
[WebAssembly] Fix immediate of rethrow when throwing to caller
Summary: Currently when assigning depths 'rethrow' does not take the whole control flow stack into accounts but only considers EH pad s
[WebAssembly] Fix immediate of rethrow when throwing to caller
Summary: Currently when assigning depths 'rethrow' does not take the whole control flow stack into accounts but only considers EH pad stacks. When assigning depth immmediates to rethrows, in normal cases it is done correctly but when a rethrow instruction throws up to a caller, i.e., we convert a pseudo RETHROW_TO_CALLER instruction to a rethrow, it mistakenly compute the whole stack depth.
Reviewers: dschuff
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D53619
llvm-svn: 345223
show more ...
|
|
Revision tags: llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2 |
|
| #
e76fa9ec |
| 16-Aug-2018 |
Heejin Ahn <[email protected]> |
[WebAssembly] CFG stackify support for exception handling
Summary: This adds support for exception handling to CFGStackify pass. This only adds TRY / END_TRY markers and DOES NOT yet fix unwind mism
[WebAssembly] CFG stackify support for exception handling
Summary: This adds support for exception handling to CFGStackify pass. This only adds TRY / END_TRY markers and DOES NOT yet fix unwind mismatches that can be created by the linearization of the CFG into the structural wasm format. The mismatch fix will be added by following patches.
In detail, this patch - Added support for TRY / END_TRY markers to support EH - Changed many static functions into class member functions as they take too many arguments now - Added several more bookeeping data structures - Refactored routines that decide where to insert markers, because without refactoring this got too complicated as we added support for new kinds of markers (TRY/END_TRY). - Rewrote rethrow instructions' BB arguments to relative depths in EH pad stack.
Reviewers: dschuff, sunfish
Subscribers: sbc100, jgravelle-google, llvm-commits
Differential Revision: https://reviews.llvm.org/D48273
llvm-svn: 339967
show more ...
|