#
00f9e5aa |
| 09-Oct-2019 |
Thomas Lively <tlively@google.com> |
[WebAssembly] Make returns variadic
Summary: This is necessary and sufficient to get simple cases of multiple return working with multivalue enabled. More complex cases will require block and loop s
[WebAssembly] Make returns variadic
Summary: This is necessary and sufficient to get simple cases of multiple return working with multivalue enabled. More complex cases will require block and loop signatures to be generalized to potentially be type indices as well.
Reviewers: aheejin, dschuff
Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68684
llvm-svn: 374235
show more ...
|
#
6a37c5d6 |
| 08-Oct-2019 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Fix a bug in 'try' placement
Summary: When searching for local expression tree created by stackified registers, for 'block' placement, we start the search from the previous instruction
[WebAssembly] Fix a bug in 'try' placement
Summary: When searching for local expression tree created by stackified registers, for 'block' placement, we start the search from the previous instruction of a BB's terminator. But in 'try''s case, we should start from the previous instruction of a call that can throw, or a EH_LABEL that precedes the call, because the return values of the call's previous instructions can be stackified and consumed by the throwing call.
For example, ``` i32.call @foo call @bar ; may throw br $label0 ``` In this case, if we start the search from the previous instruction of the terminator (`br` here), we end up stopping at `call @bar` and place a 'try' between `i32.call @foo` and `call @bar`, because `call @bar` does not have a return value so it is not a local expression tree of `br`.
But in this case, unlike when placing 'block's, we should start the search from `call @bar`, because the return value of `i32.call @foo` is stackified and used by `call @bar`.
Reviewers: dschuff
Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68619
llvm-svn: 374073
show more ...
|
#
daeead4b |
| 07-Oct-2019 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Fix unwind mismatch stat computation
Summary: There was a bug when computing the number of unwind destination mismatches in CFGStackify. When there are many mismatched calls that share
[WebAssembly] Fix unwind mismatch stat computation
Summary: There was a bug when computing the number of unwind destination mismatches in CFGStackify. When there are many mismatched calls that share the same (original) destination BB, they have to be counted separately.
This also fixes a typo and runs `fixUnwindMismatches` only when the wasm exception handling is enabled. This is to prevent unnecessary computations and does not change behavior.
Reviewers: dschuff
Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68552
llvm-svn: 373975
show more ...
|
#
61d5c76a |
| 01-Oct-2019 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Unstackify regs after fixing unwinding mismatches
Summary: Fixing unwind mismatches for exception handling can result in splicing existing BBs and moving some of instructions to new BB
[WebAssembly] Unstackify regs after fixing unwinding mismatches
Summary: Fixing unwind mismatches for exception handling can result in splicing existing BBs and moving some of instructions to new BBs. In this case some of stackified def registers in the original BB can be used in the split BB. For example, we have this BB and suppose %r0 is a stackified register. ``` bb.1: %r0 = call @foo ... use %r0 ... ```
After fixing unwind mismatches in CFGStackify, `bb.1` can be split and some instructions can be moved to a newly created BB: ``` bb.1: %r0 = call @foo
bb.split (new): ... use %r0 ... ```
In this case we should make %r0 un-stackified, because its use is now in another BB.
When spliting a BB, this CL unstackifies all def registers that have uses in the new split BB.
Reviewers: dschuff
Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68218
llvm-svn: 373301
show more ...
|
Revision tags: 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 |
|
#
05c145d6 |
| 12-Aug-2019 |
Daniel Sanders <daniel_l_sanders@apple.com> |
[webassembly] Apply llvm-prefer-register-over-unsigned from clang-tidy to LLVM
Summary: This clang-tidy check is looking for unsigned integer variables whose initializer starts with an implicit cast
[webassembly] Apply llvm-prefer-register-over-unsigned from clang-tidy to LLVM
Summary: This clang-tidy check is looking for unsigned integer variables whose initializer starts with an implicit cast from llvm::Register and changes the type of the variable to llvm::Register (dropping the llvm:: where possible).
Reviewers: aheejin
Subscribers: jholewinski, MatzeB, qcolombet, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, wdng, nhaehnle, sbc100, jgravelle-google, kristof.beyls, hiraditya, aheejin, kbarton, fedor.sergeev, javed.absar, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, tpr, PkmX, jocewei, jsji, Petar.Avramovic, asbirlea, Jim, s.egerton, llvm-commits
Tags: #llvm
Differential Revision for whole review: https://reviews.llvm.org/D65962
llvm-svn: 368627
show more ...
|
Revision tags: llvmorg-9.0.0-rc1, llvmorg-10-init |
|
#
9f96a58c |
| 15-Jul-2019 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Rename except_ref type to exnref
Summary: We agreed to rename `except_ref` to `exnref` for consistency with other reference types in https://github.com/WebAssembly/exception-handling/i
[WebAssembly] Rename except_ref type to exnref
Summary: We agreed to rename `except_ref` to `exnref` for consistency with other reference types in https://github.com/WebAssembly/exception-handling/issues/79. This also renames WebAssemblyInstrExceptRef.td to WebAssemblyInstrRef.td in order to use the file for other reference types in future.
Reviewers: dschuff
Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64703
llvm-svn: 366145
show more ...
|
#
d8ddf839 |
| 12-Jul-2019 |
Wouter van Oortmerssen <aardappel@gmail.com> |
[WebAssembly] refactored utilities to not depend on MachineInstr
Summary: Most of these functions can work for MachineInstr and MCInst equally now.
Reviewers: dschuff
Subscribers: MatzeB, sbc100,
[WebAssembly] refactored utilities to not depend on MachineInstr
Summary: Most of these functions can work for MachineInstr and MCInst equally now.
Reviewers: dschuff
Subscribers: MatzeB, sbc100, jgravelle-google, aheejin, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64643
llvm-svn: 365965
show more ...
|
Revision tags: llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1 |
|
#
c4ac74fb |
| 30-Mar-2019 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Fix unwind destination mismatches in CFG stackify
Summary: Linearing the control flow by placing `try`/`end_try` markers can create mismatches in unwind destinations. This patch resolv
[WebAssembly] Fix unwind destination mismatches in CFG stackify
Summary: Linearing the control flow by placing `try`/`end_try` markers can create mismatches in unwind destinations. This patch resolves these mismatches by wrapping those instructions with an incorrect unwind destination with a nested `try`/`catch`/`end_try` and branching to the right destination within the new catch block.
Reviewers: dschuff
Subscribers: sunfish, sbc100, jgravelle-google, chrib, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D48345
llvm-svn: 357343
show more ...
|
#
67f74ace |
| 29-Mar-2019 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Handle END_LOOP in unreachable BB in CFGStackify
Summary: This fixes crashes when a BB in which an END_LOOP is to be placed is unreachable and does not have any predecessors. Fixes PR4
[WebAssembly] Handle END_LOOP in unreachable BB in CFGStackify
Summary: This fixes crashes when a BB in which an END_LOOP is to be placed is unreachable and does not have any predecessors. Fixes PR41307.
Reviewers: dschuff
Subscribers: yurydelendik, sbc100, jgravelle-google, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60004
llvm-svn: 357303
show more ...
|
#
1aaa481f |
| 26-Mar-2019 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Add CFGStacikfied field to WebAssemblyFunctionInfo
Summary: This adds `CFGStackified` field and its serialization to WebAssemblyFunctionInfo.
Reviewers: dschuff
Subscribers: sunfish,
[WebAssembly] Add CFGStacikfied field to WebAssemblyFunctionInfo
Summary: This adds `CFGStackified` field and its serialization to WebAssemblyFunctionInfo.
Reviewers: dschuff
Subscribers: sunfish, sbc100, jgravelle-google, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59747
llvm-svn: 357011
show more ...
|
#
222718fd |
| 26-Mar-2019 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Fix a bug when mixing TRY/LOOP markers
Summary: When TRY and LOOP markers are in the same BB and END_TRY and END_LOOP markers are in the same BB, END_TRY should be _before_ END_LOOP, b
[WebAssembly] Fix a bug when mixing TRY/LOOP markers
Summary: When TRY and LOOP markers are in the same BB and END_TRY and END_LOOP markers are in the same BB, END_TRY should be _before_ END_LOOP, because LOOP is always before TRY if they are in the same BB. (TRY is placed in the latest possible position, whereas LOOP is in the earliest possible position.)
Reviewers: dschuff
Subscribers: sunfish, sbc100, jgravelle-google, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59751
llvm-svn: 357008
show more ...
|
#
44a5a4b1 |
| 26-Mar-2019 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Fix bugs in BLOCK/TRY placement
Summary: Before we placed all TRY/END_TRY markers before placing BLOCK/END_BLOCK markers. This couldn't handle this case: ``` bb0: br bb2 bb1:
[WebAssembly] Fix bugs in BLOCK/TRY placement
Summary: Before we placed all TRY/END_TRY markers before placing BLOCK/END_BLOCK markers. This couldn't handle this case: ``` bb0: br bb2 bb1: // nearest common dominator of bb3 and bb4 br_if ... bb3 br bb4 bb2: ... bb3: call @foo // unwinds to ehpad bb4: call @bar // unwinds to ehpad ehpad: catch ... ```
When we placed TRY markers, we placed it in bb1 because it is the nearest common dominator of bb3 and bb4. But because bb0 jumps to bb2, when we placed block markers, we ended up with interleaved scopes like ``` block try end_block catch end_try ``` which was not correct.
This patch fixes the bug by placing BLOCK and TRY markers in one pass while iterating BBs in a function. This also adds some more routines to `placeTryMarkers`, because we now have to assume that there can be previously placed BLOCK and END_BLOCK.
Reviewers: dschuff
Subscribers: sunfish, sbc100, jgravelle-google, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59739
llvm-svn: 357007
show more ...
|
Revision tags: llvmorg-8.0.0 |
|
#
8b49b6be |
| 13-Mar-2019 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Place 'try' and 'catch' correctly wrt EH_LABELs
Summary: After instruction selection phase, possibly-throwing calls, which were previously invoke, are wrapped in `EH_LABEL` instruction
[WebAssembly] Place 'try' and 'catch' correctly wrt EH_LABELs
Summary: After instruction selection phase, possibly-throwing calls, which were previously invoke, are wrapped in `EH_LABEL` instructions. For example: ``` EH_LABEL <mcsymbol .Ltmp0> CALL_VOID @foo ... EH_LABEL <mcsymbol .Ltmp1> ```
`EH_LABEL` is placed also in the beginning of EH pads: ``` bb.1 (landing-pad): EH_LABEL <mcsymbol .Ltmp2> ... ```
And we'd like to maintian this relationship, so when we place a `try`, ``` TRY ... EH_LABEL <mcsymbol .Ltmp0> CALL_VOID @foo ... EH_LABEL <mcsymbol .Ltmp1> ```
When we place a `catch`, ``` bb.1 (landing-pad): EH_LABEL <mcsymbol .Ltmp2> %0:except_ref = CATCH ... ... ```
Previously we didn't treat EH_LABELs specially, so `try` was placed right before a call, and `catch` was placed in the beginning of an EH pad.
Reviewers: dschuff
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58914
llvm-svn: 355996
show more ...
|
Revision tags: llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4 |
|
#
5c644c9b |
| 05-Mar-2019 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Simplify iterator navigations (NFC)
Summary: - Replaces some uses of `MachineFunction::iterator(MBB)` with `MBB->getIterator()` and `MachineBasicBlock::iterator(MI)` with `MI->getI
[WebAssembly] Simplify iterator navigations (NFC)
Summary: - Replaces some uses of `MachineFunction::iterator(MBB)` with `MBB->getIterator()` and `MachineBasicBlock::iterator(MI)` with `MI->getIterator()`, which are simpler. - Replaces some uses of `std::prev` of `std::next` that takes a MachineFunction or MachineBasicBlock iterator with `getPrevNode` and `getNextNode`, which are also simpler.
Reviewers: sbc100
Subscribers: dschuff, sunfish, jgravelle-google, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58913
llvm-svn: 355444
show more ...
|
Revision tags: llvmorg-8.0.0-rc3 |
|
#
82da1ffc |
| 27-Feb-2019 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Fix ScopeTops info in CFGStackify for EH pads
Summary: When creating `ScopeTops` info for `try` ~ `catch` ~ `end_try`, we should create not only `end_try` -> `try` mapping but also `ca
[WebAssembly] Fix ScopeTops info in CFGStackify for EH pads
Summary: When creating `ScopeTops` info for `try` ~ `catch` ~ `end_try`, we should create not only `end_try` -> `try` mapping but also `catch` -> `try` mapping as well. If this is not created, `block` and `end_block` markers later added may span across an existing `catch`, resulting in the incorrect code like: ``` try block --| (X) catch | end_block --| end_try ```
Reviewers: dschuff
Subscribers: sunfish, sbc100, jgravelle-google, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58605
llvm-svn: 354945
show more ...
|
#
cf699b45 |
| 27-Feb-2019 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Remove unnecessary instructions after TRY marker placement
Summary: This removes unnecessary instructions after TRY marker placement. There are two cases: - `end`/`end_block` can be re
[WebAssembly] Remove unnecessary instructions after TRY marker placement
Summary: This removes unnecessary instructions after TRY marker placement. There are two cases: - `end`/`end_block` can be removed if they overlap with `try`/`end_try` and they have the same return types. - `br` right before `catch` that branches to after `end_try` can be deleted.
Reviewers: dschuff
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58591
llvm-svn: 354939
show more ...
|
#
20cf0749 |
| 24-Feb-2019 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Rename a variable in CFGStackify (NFC)
llvm-svn: 354744
|
#
25d924b4 |
| 24-Feb-2019 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Merge two identical switch case routines into one (NFC)
llvm-svn: 354743
|
#
a5e68748 |
| 22-Feb-2019 |
Sam Clegg <sbc@chromium.org> |
[WebAssembly] Remove debug statement submitted in rL354657
Subscribers: dschuff, jgravelle-google, hiraditya, aheejin, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm
[WebAssembly] Remove debug statement submitted in rL354657
Subscribers: dschuff, jgravelle-google, hiraditya, aheejin, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58549
llvm-svn: 354684
show more ...
|
#
85631d8b |
| 22-Feb-2019 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Remove getBottom function from CFGStackify (NFC)
Summary: This removes `getBottom` function and the bookeeping map of <begin marker instruction, bottom BB>.
Reviewers: dschuff
Subscr
[WebAssembly] Remove getBottom function from CFGStackify (NFC)
Summary: This removes `getBottom` function and the bookeeping map of <begin marker instruction, bottom BB>.
Reviewers: dschuff
Subscribers: sunfish, sbc100, jgravelle-google, jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58319
llvm-svn: 354657
show more ...
|
Revision tags: llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2 |
|
#
18c56a07 |
| 04-Feb-2019 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] clang-tidy (NFC)
Summary: This patch fixes clang-tidy warnings on wasm-only files. The list of checks used is: `-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-
[WebAssembly] clang-tidy (NFC)
Summary: This patch fixes clang-tidy warnings on wasm-only files. The list of checks used is: `-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming,modernize-*` (LLVM's default .clang-tidy list is the same except it does not have `modernize-*`. But I've seen in multiple CLs in LLVM the modernize style was recommended and code was fixed based on the style, so I added it as well.)
The common fixes are: - Variable names start with an uppercase letter - Function names start with a lowercase letter - Use `auto` when you use casts so the type is evident - Use inline initialization for class member variables - Use `= default` for empty constructors / destructors - Use `using` in place of `typedef`
Reviewers: sbc100, tlively, aardappel
Subscribers: dschuff, sunfish, jgravelle-google, yurydelendik, kripken, MatzeB, mgorny, rupprecht, llvm-commits
Differential Revision: https://reviews.llvm.org/D57500
llvm-svn: 353075
show more ...
|
#
d6f48786 |
| 30-Jan-2019 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Exception handling: Switch to the new proposal
Summary: This switches the EH implementation to the new proposal: https://github.com/WebAssembly/exception-handling/blob/master/proposals
[WebAssembly] Exception handling: Switch to the new proposal
Summary: This switches the EH implementation to the new proposal: https://github.com/WebAssembly/exception-handling/blob/master/proposals/Exceptions.md (The previous proposal was https://github.com/WebAssembly/exception-handling/blob/master/proposals/old/Exceptions.md)
- Instruction changes - Now we have one single `catch` instruction that returns a except_ref value - `throw` now can take variable number of operations - `rethrow` does not have 'depth' argument anymore - `br_on_exn` queries an except_ref to see if it matches the tag and branches to the given label if true. - `extract_exception` is a pseudo instruction that simulates popping values from wasm stack. This is to make `br_on_exn`, a very special instruction, work: `br_on_exn` puts values onto the stack only if it is taken, and the # of values can vay depending on the tag.
- Now there's only one `catch` per `try`, this patch removes all special handling for terminate pad with a call to `__clang_call_terminate`. Before it was the only case there are two catch clauses (a normal `catch` and `catch_all` per `try`).
- Make `rethrow` act as a terminator like `throw`. This splits BB after `rethrow` in WasmEHPrepare, and deletes an unnecessary `unreachable` after `rethrow` in LateEHPrepare.
- Now we stop at all catchpads (because we add wasm `catch` instruction that catches all exceptions), this creates new `findWasmUnwindDestinations` function in SelectionDAGBuilder.
- Now we use `br_on_exn` instrution to figure out if an except_ref matches the current tag or not, LateEHPrepare generates this sequence for catch pads: ``` catch block i32 br_on_exn $__cpp_exception end_block extract_exception ```
- Branch analysis for `br_on_exn` in WebAssemblyInstrInfo
- Other various misc. changes to switch to the new proposal.
Reviewers: dschuff
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D57134
llvm-svn: 352598
show more ...
|
Revision tags: llvmorg-8.0.0-rc1 |
|
#
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <chandlerc@gmail.com> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3 |
|
#
d2fd7099 |
| 07-Dec-2018 |
Heejin Ahn <aheejin@gmail.com> |
Delete registerScope function
`unregisterScope()` is not currently used, so removing it.
llvm-svn: 348647
|
#
5b023e07 |
| 02-Nov-2018 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Fix bugs in rethrow depth counting and InstPrinter
Summary: EH stack depth is incremented at `try` and decremented at `catch`. When there are more than two catch instructions for a try
[WebAssembly] Fix bugs in rethrow depth counting and InstPrinter
Summary: EH stack depth is incremented at `try` and decremented at `catch`. When there are more than two catch instructions for a try instruction, we shouldn't count non-first catches when calculating EH stack depths.
This patch fixes two bugs: - CFGStackify: Exclude `catch_all` in the terminate catch pad when calculating EH pad stack, because when we have multiple catches for a try we should count only the first catch instruction when calculating EH pad stack. - InstPrinter: The initial intention was also to exclude non-first catches, but it didn't account nested try-catches, so it failed on this case: ``` try try catch end catch <-- (1) end ``` In the example, when we are at the catch (1), the last seen EH instruction is not `try` but `end_try`, violating the wrong assumption.
We don't need these after we switch to the second proposal because there is gonna be only one `catch` instruction. But anyway before then these bugfixes are necessary for keep trunk in working state.
Reviewers: dschuff
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D53819
llvm-svn: 346029
show more ...
|