searching for reviewer(lth)
ceedac0727f9d783d5c34efe9781d446b8e68cb8: Bug 1598149 - Import updated spec tests. r=lth
Ryan Hunt <rhunt@eqrion.net> - Tue, 26 Nov 2019 18:24:03 +0000 - rev 569147
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1598149 - Import updated spec tests. r=lth This commit updates our in-tree version of spec-tests to a recent bulk-memory master (1e296604ae7c2aa2ce7619929a8817c9fd95941d) with one backport for our addition of a bottom type. All the other backports and merges have been dropped. [1] https://github.com/eqrion/wasm-spec/commits/spidermonkey-tree-tests Differential Revision: https://phabricator.services.mozilla.com/D54600
81832b228e1684f421ffe1a0c2f2f3597afc6e63: Bug 1598149 - Treat data/elem.drop as shrink-to-zero, disallow zero length past end of bounds. r=lth
Ryan Hunt <rhunt@eqrion.net> - Tue, 26 Nov 2019 18:23:22 +0000 - rev 569146
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1598149 - Treat data/elem.drop as shrink-to-zero, disallow zero length past end of bounds. r=lth Spec Issue: https://github.com/WebAssembly/bulk-memory-operations/issues/124 The inline path for memory.copy/fill are updated to fallback to the OOL path when the length is 0 to have proper bounds checking behavior. Differential Revision: https://phabricator.services.mozilla.com/D54599
bc6abdc25bcfeba3f1f2a13d50d704e0d44002b6: Bug 1598149 - Report bulk-memory failures to instantiate segments as runtime errors. r=lth
Ryan Hunt <rhunt@eqrion.net> - Tue, 26 Nov 2019 19:01:01 +0000 - rev 569145
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1598149 - Report bulk-memory failures to instantiate segments as runtime errors. r=lth Bulk memory reduces active segments to sequences of *.init that are executed before the start function is called. This implies that an error here is to be reported as a RuntimeError, as an error in the start function would. The latest spec tests for bulk-memory check this, so we're required to update as well. Differential Revision: https://phabricator.services.mozilla.com/D54598
664f0ef11e261fcefdb910973660a9c183937af7: Bug 1598149 - Report bulk-memory failures to instantiate segments as runtime errors. r=lth
Ryan Hunt <rhunt@eqrion.net> - Tue, 26 Nov 2019 18:24:39 +0000 - rev 569095
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1598149 - Report bulk-memory failures to instantiate segments as runtime errors. r=lth Bulk memory reduces active segments to sequences of *.init that are executed before the start function is called. This implies that an error here is to be reported as a RuntimeError, as an error in the start function would. The latest spec tests for bulk-memory check this, so we're required to update as well. Differential Revision: https://phabricator.services.mozilla.com/D54598
2e5253665a3abc5946839908f450d46d00cda95e: Bug 1562667 - P4c - Revert the check for SAB for a js chrome test on Nightly; r=lth
Tom Tung <ttung@mozilla.com> - Mon, 25 Nov 2019 15:33:22 +0000 - rev 568876
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1562667 - P4c - Revert the check for SAB for a js chrome test on Nightly; r=lth Differential Revision: https://phabricator.services.mozilla.com/D54126
5337448b7a79da8a3ff7619bb3cd01e33df01e28: Bug 1562667 - P4b - Disable jsref test for Atomic on Nightly; r=lth,jorendorff
Tom Tung <ttung@mozilla.com> - Mon, 25 Nov 2019 15:33:22 +0000 - rev 568875
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1562667 - P4b - Disable jsref test for Atomic on Nightly; r=lth,jorendorff After enabling the perf for SAB by default on Nightly, some jsreftests fail. And they all have log like: tests/test262/shell.js:492: Error: Agents not available item 1 It seems that there are some issues on test262 shell, so the plan of this patch is to disable these tests and open another follow-up ticket to re-enable them. So that we could check the impact of enable the perf for SAB without enabling the functionality of being postMessage'ed on Nightly users. Differential Revision: https://phabricator.services.mozilla.com/D53966
e318a3f2027c8209ddb3afbe312cfe953953d938: Bug 1594561 - Update spec tests for backported spec change. r=lth
Ryan Hunt <rhunt@eqrion.net> - Mon, 18 Nov 2019 12:17:19 +0000 - rev 567964
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1594561 - Update spec tests for backported spec change. r=lth Our import of the spec tests don't include the change to allow dropped segments if the length = 0. Ideally we would update the test branch to the latest canon master, then merge bulk, then merge ref. Unfortunately ref and bulk have non-trivial interpreter changes that conflict. I solved some of these issues on the current test branch, but it's gotten more challenging to do again. For now, it seems easiest to backport the change we need to our test branch, ask for either bulk-mem or reftypes to move to phase 4, then fix the merge conflicts publically in the repo of other proposal. Link to the backport patch [1] [2]. [1] github.com/eqrion/wasm-spec/commit/cb1eb6f3235574ae043d5e1e7e9adc56852d2e4f [2] github.com/eqrion/wasm-spec/tree/spidermonkey-tree-tests Depends on D52130 Differential Revision: https://phabricator.services.mozilla.com/D53242
263c029519073e3d6fff07d791d90f01b609ce82: Bug 1594561 - Allow dropped segs with mem/table.init when len=0. r=lth
Ryan Hunt <rhunt@eqrion.net> - Fri, 15 Nov 2019 17:52:25 +0000 - rev 567963
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1594561 - Allow dropped segs with mem/table.init when len=0. r=lth This was an ambiguity in the spec between the prose and formalism. The spec interpreter implements it this way. Differential Revision: https://phabricator.services.mozilla.com/D52130
e12f0cfd62926fd3bee18a6d3f1983776804545a: Bug 1597200 - Fix shuffling of WebAssembly stack results toward FP r=lth
Andy Wingo <wingo@igalia.com> - Tue, 19 Nov 2019 08:20:18 +0000 - rev 567788
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1597200 - Fix shuffling of WebAssembly stack results toward FP r=lth In a sadly similar bogosity as in bug 1595466, the multi-value stack value shuffling code was confused about "stack height" (distance from FP), "stack offset" (distance from SP), and whether the bytes to be copied were towards the FP or the SP. Differential Revision: https://phabricator.services.mozilla.com/D53660
c06659c20d415adb089a7751af744d8f4a908153: Bug 1594204 - Generate inline code for memory.copy and memory.fill. r=lth
Ryan Hunt <rhunt@eqrion.net> - Fri, 15 Nov 2019 17:21:24 +0000 - rev 567454
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1594204 - Generate inline code for memory.copy and memory.fill. r=lth This commit adds an inline code path for memory.copy/fill for Ion and Baseline for all platforms. To keep things simple, I reused the plain wasm load/store codegen with integer types up to 64bits. A future commit can add SIMD support as needed. A copy with constant length is reduced to a series of loads (from low-to-high) onto the value stack (for baseline), or onto a stack of definitions (for ion). Then a series of stores are emitted (from high-to-low) from the value stack or temp definition stack. A fill with constant length and value is reduced to a series of stores (from high-to-low). The stores use the widest transfer width as possible, and the value is splatted as appropriate to fill the whole integer. This optimization is limited to sizes that are less than the guard page so that we only need to perform a single bounds check for src/dest. The threshold is per-platform and derived from the wasm-bulk-bench microbenchmark. I attempted to pick the length just before the inline path began to slow exponentially. This was roughly constant at 8 loads/stores for 64 and 32 bits. Differential Revision: https://phabricator.services.mozilla.com/D52129
26c65691696b92244393e8ebe7f06bff47ea5a0f: Bug 1594204 - Split out 'emitMemCopy' function for dedicated optimizations. r=lth
Ryan Hunt <rhunt@eqrion.net> - Fri, 15 Nov 2019 17:20:43 +0000 - rev 567453
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1594204 - Split out 'emitMemCopy' function for dedicated optimizations. r=lth Differential Revision: https://phabricator.services.mozilla.com/D50380
74cc3a413cb0f2da50eb95dff6b6656ce4edabfc: Bug 1594204 - Generate inline code for memory.copy and memory.fill. r=lth
Ryan Hunt <rhunt@eqrion.net> - Thu, 14 Nov 2019 18:56:56 +0000 - rev 567251
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1594204 - Generate inline code for memory.copy and memory.fill. r=lth This commit adds an inline code path for memory.copy/fill for Ion and Baseline for all platforms. To keep things simple, I reused the plain wasm load/store codegen with integer types up to 64bits. A future commit can add SIMD support as needed. A copy with constant length is reduced to a series of loads (from low-to-high) onto the value stack (for baseline), or onto a stack of definitions (for ion). Then a series of stores are emitted (from high-to-low) from the value stack or temp definition stack. A fill with constant length and value is reduced to a series of stores (from high-to-low). The stores use the widest transfer width as possible, and the value is splatted as appropriate to fill the whole integer. This optimization is limited to sizes that are less than the guard page so that we only need to perform a single bounds check for src/dest. The threshold is per-platform and derived from the wasm-bulk-bench microbenchmark. I attempted to pick the length just before the inline path began to slow exponentially. This was roughly constant at 8 loads/stores for 64 and 32 bits. Differential Revision: https://phabricator.services.mozilla.com/D52129
6295568b6ea47d638c4346effd4731d37366547b: Bug 1594204 - Split out 'emitMemCopy' function for dedicated optimizations. r=lth
Ryan Hunt <rhunt@eqrion.net> - Thu, 14 Nov 2019 18:56:41 +0000 - rev 567250
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1594204 - Split out 'emitMemCopy' function for dedicated optimizations. r=lth Differential Revision: https://phabricator.services.mozilla.com/D50380
b0545db75058d5967c77a4836f5d6e4e3115ebf5: Bug 1594204 - Generate inline code for memory.copy and memory.fill. r=lth
Ryan Hunt <rhunt@eqrion.net> - Thu, 14 Nov 2019 17:33:19 +0000 - rev 567207
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1594204 - Generate inline code for memory.copy and memory.fill. r=lth This commit adds an inline code path for memory.copy/fill for Ion and Baseline for all platforms. To keep things simple, I reused the plain wasm load/store codegen with integer types up to 64bits. A future commit can add SIMD support as needed. A copy with constant length is reduced to a series of loads (from low-to-high) onto the value stack (for baseline), or onto a stack of definitions (for ion). Then a series of stores are emitted (from high-to-low) from the value stack or temp definition stack. A fill with constant length and value is reduced to a series of stores (from high-to-low). The stores use the widest transfer width as possible, and the value is splatted as appropriate to fill the whole integer. This optimization is limited to sizes that are less than the guard page so that we only need to perform a single bounds check for src/dest. The threshold is per-platform and derived from the wasm-bulk-bench microbenchmark. I attempted to pick the length just before the inline path began to slow exponentially. This was roughly constant at 8 loads/stores for 64 and 32 bits. Differential Revision: https://phabricator.services.mozilla.com/D52129
36d41bbf2f46f987ea17b903890eb58a0cfd02a4: Bug 1594204 - Split out 'emitMemCopy' function for dedicated optimizations. r=lth
Ryan Hunt <rhunt@eqrion.net> - Thu, 14 Nov 2019 15:10:46 +0000 - rev 567206
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1594204 - Split out 'emitMemCopy' function for dedicated optimizations. r=lth Differential Revision: https://phabricator.services.mozilla.com/D50380
2475e9e1ea77d8ddeeaf8e9918d360c8f03ec8bb: Bug 1593736 - Rename ArgType_Double to ArgType_Float64. r=lth
Ryan Hunt <rhunt@eqrion.net> - Wed, 13 Nov 2019 14:43:56 +0000 - rev 566957
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1593736 - Rename ArgType_Double to ArgType_Float64. r=lth Also shuffle constants and add a comment for clarity. Differential Revision: https://phabricator.services.mozilla.com/D52178
23218bed721cdac05991d943fc4443a03cfc4cbd: Bug 1593736 - Give ArgType_General pointer semantics in Wasm builtin code. r=lth
Ryan Hunt <rhunt@eqrion.net> - Wed, 13 Nov 2019 14:43:43 +0000 - rev 566956
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1593736 - Give ArgType_General pointer semantics in Wasm builtin code. r=lth After examining bug 1591047, I believe we should have added an Int32 type instead of changing the semantics of ArgType_General to be Int32. The reason is that the existing code assumes ArgType_General is pointer sized, and changing this is scary for all the existing uses. (e.g. simulator, MacroAssembler::appendSignatureType) * Adds ArgType_Int32 * Changes ArgType_General -> ArgType_Int32, ArgType_Pointer -> ArgType_General for ABIFunctionTypes introduced in bug 1591047 (which are only used for Wasm instance calls). * ToMirType(ArgType_General) -> MIRType::Pointer (should only affect wasm) * ToMirType(ArgType_Int32) -> MIRType::Int32 (should only affect wasm) Differential Revision: https://phabricator.services.mozilla.com/D52177
4424f41acdb04b53e7efcf8d64fc9dd1a2c53275: Bug 1595466 - Fix multi-value shuffle of stack values toward SP r=lth
Andy Wingo <wingo@igalia.com> - Tue, 12 Nov 2019 17:49:10 +0000 - rev 566928
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1595466 - Fix multi-value shuffle of stack values toward SP r=lth This commit fixes a bug whereby shuffling of stack results toward the stack pointer was borked. Just for posterity, here's a wee ASCII art of how this works in the baseline compiler. The error came in the last transition, when shuffling B toward the newly-expanded SP. The previous code was simply bogus. ``` initial (i32.const A) stack --> (local.get B) -> popRegisterResults -> popStackResults state (local.get C) _ | | | | | | | | | | | | | stack | | | | | | | | | height | | | | | | | | | | | | | | | | | sp+-+ v +-+ +-+ +-+ | |B| |A| | +-+ +-+ | |B| | +-+ | V nothing pushed C in %rax; B shuffled toward stack on machine stack; A still on %rsp; A materialized grows 3 values on value value stack down stack ``` Differential Revision: https://phabricator.services.mozilla.com/D52676
283981b64bead149add4f1c730fe78b69968dd7d: Bug 1595222 - Don't define an unused |AtomicReturnReg64| on x86. r=lth
Jeff Walden <jwalden@mit.edu> - Tue, 12 Nov 2019 13:43:31 +0000 - rev 566804
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1595222 - Don't define an unused |AtomicReturnReg64| on x86. r=lth Differential Revision: https://phabricator.services.mozilla.com/D52424
6f894c71dabe09331fcb09ed8f2e5215c6eaecea: Bug 1593736 - Rename ArgType_Double to ArgType_Float64. r=lth
Ryan Hunt <rhunt@eqrion.net> - Fri, 08 Nov 2019 08:26:45 +0000 - rev 566755
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1593736 - Rename ArgType_Double to ArgType_Float64. r=lth Also shuffle constants and add a comment for clarity. Depends on D52177 Differential Revision: https://phabricator.services.mozilla.com/D52178
4d1dc9dc93be754a602f067dd769dd6b75bdc95d: Bug 1593736 - Give ArgType_General pointer semantics in Wasm builtin code. r=lth
Ryan Hunt <rhunt@eqrion.net> - Fri, 08 Nov 2019 08:37:20 +0000 - rev 566754
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1593736 - Give ArgType_General pointer semantics in Wasm builtin code. r=lth After examining bug 1591047, I believe we should have added an Int32 type instead of changing the semantics of ArgType_General to be Int32. The reason is that the existing code assumes ArgType_General is pointer sized, and changing this is scary for all the existing uses. (e.g. simulator, MacroAssembler::appendSignatureType) * Adds ArgType_Int32 * Changes ArgType_General -> ArgType_Int32, ArgType_Pointer -> ArgType_General for ABIFunctionTypes introduced in bug 1591047 (which are only used for Wasm instance calls). * ToMirType(ArgType_General) -> MIRType::Pointer (should only affect wasm) * ToMirType(ArgType_Int32) -> MIRType::Int32 (should only affect wasm) Differential Revision: https://phabricator.services.mozilla.com/D52177
e7d2e0642ae035d0bc81a7eab75dbf75511702d8: Bug 1593027 - Add WebAssembly multi-value codegen and run-time tests r=lth
Andy Wingo <wingo@igalia.com> - Fri, 08 Nov 2019 14:17:20 +0000 - rev 566633
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1593027 - Add WebAssembly multi-value codegen and run-time tests r=lth Differential Revision: https://phabricator.services.mozilla.com/D51287
1d5515a8ba7004980aa3cd2ab39b3e2f6bbfc632: Bug 1584112 - Add WebAssembly multi-value validation tests r=lth
Andy Wingo <wingo@igalia.com> - Fri, 08 Nov 2019 14:17:50 +0000 - rev 566526
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1584112 - Add WebAssembly multi-value validation tests r=lth Differential Revision: https://phabricator.services.mozilla.com/D47220
0f3a32ae9e57a194cceab6bac1f02b19277050ec: Bug 1586207 - WebAssembly validation allows multi-param and multi-result blocks r=lth
Andy Wingo <wingo@igalia.com> - Fri, 08 Nov 2019 14:16:57 +0000 - rev 566525
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1586207 - WebAssembly validation allows multi-param and multi-result blocks r=lth Differential Revision: https://phabricator.services.mozilla.com/D48157
39bc5b23a7a9047fa3770d80787a0d93c9491ee9: Bug 1592983 - Only validate WebAssembly baseline stack in live code r=lth
Andy Wingo <wingo@igalia.com> - Fri, 08 Nov 2019 12:39:40 +0000 - rev 566497
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1592983 - Only validate WebAssembly baseline stack in live code r=lth Differential Revision: https://phabricator.services.mozilla.com/D51276
4bf64cf387138bda40ae1d98dfec594c536b103c: Bug 1594561 - Allow dropped segs with mem/table.init when len=0. r=lth
Ryan Hunt <rhunt@eqrion.net> - Thu, 07 Nov 2019 07:32:40 +0000 - rev 566277
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1594561 - Allow dropped segs with mem/table.init when len=0. r=lth This was an ambiguity in the spec between the prose and formalism. The spec interpreter implements it this way. Differential Revision: https://phabricator.services.mozilla.com/D52130
70bd926c6ca95e796a9187a437993688ffae3c3d: Bug 1592783 - Update in-tree and spec-tests for trapping change. r=lth
Ryan Hunt <rhunt@eqrion.net> - Tue, 05 Nov 2019 15:27:34 +0000 - rev 565823
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1592783 - Update in-tree and spec-tests for trapping change. r=lth This commit relies on a patch to the spec interpreter/tests to also make the trapping change there [1] [2]. [1] https://github.com/eqrion/wasm-spec/tree/spidermonkey-tree-tests [2] https://github.com/eqrion/wasm-spec/commit/b467c3e4e32f17d1433628ea7f40793b57bd9663 Differential Revision: https://phabricator.services.mozilla.com/D51756
801e6ae4efdeb516250c6800e31f969d337b8f40: Bug 1592783 - Change bulk-memory instructions to trap before writing. r=lth
Ryan Hunt <rhunt@eqrion.net> - Tue, 05 Nov 2019 15:27:07 +0000 - rev 565822
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1592783 - Change bulk-memory instructions to trap before writing. r=lth This commit changes all bulk-memory instructions to perform up-front bounds checks and trap if any access would be out-of-bounds before writing. This affects: * memory.init,copy,fill * table.init,copy,fill * data segment instantiation (reduces to memory.init) * elem segment instantiation (reduces to table.init) Spec issue: https://github.com/WebAssembly/bulk-memory-operations/issues/111 Differential Revision: https://phabricator.services.mozilla.com/D51755
a9d567f1675794fc506a250121338a7d3d17e44e: Bug 1592973 - Fix WebAssembly ABIResultIter for stack arguments r=lth
Andy Wingo <wingo@igalia.com> - Tue, 05 Nov 2019 15:38:39 +0000 - rev 565804
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1592973 - Fix WebAssembly ABIResultIter for stack arguments r=lth Differential Revision: https://phabricator.services.mozilla.com/D51269
f0e9baa206dc4318293804c2c2ccca5c9eb7258e: Bug 1592974 - Spill registers before emitting an interrupt check r=lth
Andy Wingo <wingo@igalia.com> - Tue, 05 Nov 2019 15:40:21 +0000 - rev 565803
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1592974 - Spill registers before emitting an interrupt check r=lth Differential Revision: https://phabricator.services.mozilla.com/D51270
5bfb9d257c441384b0217032236bab42b59374c8: Bug 1593015 - Fix WebAssembly baseline codegen for if/then/else with parameters r=lth
Andy Wingo <wingo@igalia.com> - Tue, 05 Nov 2019 15:42:12 +0000 - rev 565802
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1593015 - Fix WebAssembly baseline codegen for if/then/else with parameters r=lth Differential Revision: https://phabricator.services.mozilla.com/D51285
3cffff8e9f47e1e07f269e818ea7fca20af77ca0: Bug 1591047 part 6 - Add ABIArgType::Pointer and use it for builtin functions. r=lth
Ryan Hunt <rhunt@eqrion.net> - Fri, 01 Nov 2019 14:48:16 +0000 - rev 565369
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1591047 part 6 - Add ABIArgType::Pointer and use it for builtin functions. r=lth When adding a pointer to WasmInstance::memCopy, it appears that we ran out of GPRs for calling and the pointer needed to be passed via stack. GenerateBuiltinThunk uses ABIFunctionType/ABIArgType, and converts it to MIRType for calling StackCopy [1]. ArgType_General is treated as being equal to MIRType::Int32, leading to only half of the pointer being passed correctly on 64bit window systems. This means that all instance functions currently have an incorrect ABIFunctionType but avoid this issue because they don't have enough parameters or don't have a 64bit value that is passed by the stack. We have to use ABIFunctionType here for compatibility with the ARM/ARM64 simulators, otherwise it would be convenient to use a different representation. This commit: 1. Adds an ArgType_Pointer which is equivalent to MIRType::Pointer 2. Adds a helper constexpr for defining ABIFunctionType 3. Fixes the ABIFunctionType used for instance calls 4. Fixes the simulators to recognize the new ABIFunctionType's 5. Adds an assertion that the SymbolicAddressSignature and ABIFunctionType are compatible. Differential Revision: https://phabricator.services.mozilla.com/D51330
756e84749f99443679ca7f2637ce1f731bfed5a9: Bug 1591047 part 5 - Pass heapBase to memCopy/memFill and use that to acquire length. r=lth
Ryan Hunt <rhunt@eqrion.net> - Fri, 01 Nov 2019 13:45:09 +0000 - rev 565368
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1591047 part 5 - Pass heapBase to memCopy/memFill and use that to acquire length. r=lth This commit uses the previous commits to actually optimize the OOL implementations. This is done by: * Passing the heap base pointer to each builtin * Acquiring the WasmArrayRawBuffer/SharedArrayRawBuffer from this pointer - This is trivial as they are embedded a fixed offset before the Wasm heap * Acquiring the heap length from the raw buffer By doing this, we avoid cache misses from accessing: TLSData -> Instance -> WasmMemoryObject -> ArrayBufferObject -> WasmArrayRawBuffer This is enough to get close enough to parity with V8 for small sizes. Further improvements should be done with an inline generated code path. Differential Revision: https://phabricator.services.mozilla.com/D50378
6aa480e46a9f274eaa52a6b1ee876b4858ec0078: Bug 1591047 part 4 - Track Wasm memory length in WasmArrayRawBuffer. r=lth
Ryan Hunt <rhunt@eqrion.net> - Fri, 01 Nov 2019 13:44:14 +0000 - rev 565367
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1591047 part 4 - Track Wasm memory length in WasmArrayRawBuffer. r=lth Currently the Wasm memory length for non-shared memory is stored in a slot of the ArrayBuffer. This commit tracks it in the WasmArrayRawBuffer as well, for use in a future commit. Differential Revision: https://phabricator.services.mozilla.com/D50377
08f232c06c37d80cf005ec8643d019e8069ec6ef: Bug 1591047 part 3 - Expose WasmArrayRawBuffer from 'ArrayBufferObject.h'. r=lth
Ryan Hunt <rhunt@eqrion.net> - Fri, 01 Nov 2019 13:44:00 +0000 - rev 565366
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1591047 part 3 - Expose WasmArrayRawBuffer from 'ArrayBufferObject.h'. r=lth This commit declares WasmArrayRawBuffer in the ArrayBufferObject header. This will allow WasmInstance to access the buffer in a future commit. Differential Revision: https://phabricator.services.mozilla.com/D50376
2a4f822999200ebbe1600ace0c0670dd813f7a20: Bug 1591047 part 2 - Split memCopy/memFill implementations for shared/non-shared modules. r=lth
Ryan Hunt <rhunt@eqrion.net> - Fri, 01 Nov 2019 13:43:45 +0000 - rev 565365
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1591047 part 2 - Split memCopy/memFill implementations for shared/non-shared modules. r=lth Whether a module uses shared memory or not is fixed throughout its lifetime. We can use this to specialize the implementation of memCopy/memFill and remove a branch on the memory type. This will also be useful when acquiring the memory length in a future commit, which will require different code per shared-ness. Differential Revision: https://phabricator.services.mozilla.com/D50375
911c7062f83fe4028f89bd2e70c1f6fb19210d23: Bug 1591047 part 1 - Don't lock when acquiring length of shared Wasm memory. r=lth
Ryan Hunt <rhunt@eqrion.net> - Fri, 01 Nov 2019 14:46:35 +0000 - rev 565364
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1591047 part 1 - Don't lock when acquiring length of shared Wasm memory. r=lth This commit drops the requirement to acquire the shared memory lock when we are only acquiring the length. The length_ field is changed to be an Atomic<SeqCst> in the process. We still need to acquire the lock when growing the memory in order to atomically compute the new length and commit the new pages. Differential Revision: https://phabricator.services.mozilla.com/D50374
90ef5c4f6349447e72cfd2fc50ad103969a66464: Bug 1590920 - Fix popBlockResults(Empty) for jump to outer block r=lth
Andy Wingo <wingo@igalia.com> - Thu, 24 Oct 2019 09:26:17 +0000 - rev 564032
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1590920 - Fix popBlockResults(Empty) for jump to outer block r=lth Differential Revision: https://phabricator.services.mozilla.com/D50448
a9d2b57a99be08cf6942e5dd8c300e75ba0b7501: Bug 1578418 - Use WasmABIResults iterator to place block and function results r=luke,lth
Andy Wingo <wingo@igalia.com> - Tue, 22 Oct 2019 15:30:10 +0000 - rev 563876
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1578418 - Use WasmABIResults iterator to place block and function results r=luke,lth Differential Revision: https://phabricator.services.mozilla.com/D44477
6145f7c31786ebb18ebd6af87c5197a4c697d5ac: Bug 1583251 - P5 - Having some js tests to verify the deserialize function; r=nika,lth
Tom Tung <ttung@mozilla.com> - Wed, 23 Oct 2019 07:20:52 +0000 - rev 563870
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1583251 - P5 - Having some js tests to verify the deserialize function; r=nika,lth Differential Revision: https://phabricator.services.mozilla.com/D48561
8900fd9c1c09a2e4e33caf82a336f718f402345f: Bug 1583251 - P3 - Check if it is okay to allow shared memory while deserializing; r=nika,lth
Tom Tung <ttung@mozilla.com> - Wed, 23 Oct 2019 07:20:18 +0000 - rev 563868
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1583251 - P3 - Check if it is okay to allow shared memory while deserializing; r=nika,lth Differential Revision: https://phabricator.services.mozilla.com/D48349
51bb06ee4062fe6356268096ff3f9ec3efe47618: Bug 1583251 - P2 - Fix some format nits or naming nits for StructuredClone::Write; r=nika,lth
Tom Tung <ttung@mozilla.com> - Wed, 23 Oct 2019 07:20:05 +0000 - rev 563867
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1583251 - P2 - Fix some format nits or naming nits for StructuredClone::Write; r=nika,lth Differential Revision: https://phabricator.services.mozilla.com/D48348
aca2e6cff6b9c66232538f82538d3d1965be4eca: Bug 1578418 - Use WasmABIResults iterator to place block and function results r=luke,lth
Andy Wingo <wingo@igalia.com> - Tue, 22 Oct 2019 09:04:59 +0000 - rev 563766
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1578418 - Use WasmABIResults iterator to place block and function results r=luke,lth Differential Revision: https://phabricator.services.mozilla.com/D44477
250671bb30b342723a521942312ba191aaa9749b: Bug 1590083: Put the wasm block depth test into its own file; r=lth
Benjamin Bouvier <benj@benj.me> - Tue, 22 Oct 2019 07:11:05 +0000 - rev 563701
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1590083: Put the wasm block depth test into its own file; r=lth On my (pretty powerful) machine, running binary.js takes 7 seconds before this patch, 2.5 seconds after the patch. The slow test behaves even worse with Cranelift, taking up to 20 seconds. Splitting this particular test in its own test file makes it run in parallel and reduce overall time spent on binary.js. Differential Revision: https://phabricator.services.mozilla.com/D49926
8204dd5d6f50b6090446793947ccfde46bc9bb2d: Bug 1590083: Disable wasm multi value with Cranelift; r=lth
Benjamin Bouvier <benj@benj.me> - Tue, 22 Oct 2019 07:11:05 +0000 - rev 563700
Push 2218 by ffxbld-merge at Mon, 30 Dec 2019 12:35:14 +0000
Bug 1590083: Disable wasm multi value with Cranelift; r=lth Since wasm multi-value is enabled by default (without a shell switch), there was no way to signal it was disabled in certain configurations, namely Cranelift. Instead, assume multi-value is enabled by default and disable it with Cranelift, and store this information in the CompilerEnvironment so we can use it when iterating on the wasm binary. Differential Revision: https://phabricator.services.mozilla.com/D49925
bfe390ad771b5bbaa5515e376dac91373c7837bd: Bug 1583251 - P5 - Having some js tests to verify the deserialize function; r=nika,lth
Tom Tung <ttung@mozilla.com> - Tue, 15 Oct 2019 11:12:38 +0000 - rev 562806
Push 2195 by ffxbld-merge at Mon, 25 Nov 2019 12:02:33 +0000
Bug 1583251 - P5 - Having some js tests to verify the deserialize function; r=nika,lth Depends on D48560 Differential Revision: https://phabricator.services.mozilla.com/D48561
248ad59168dd79138efdf8bed3d5863473142b75: Bug 1583251 - P3 - Check if it is okay to allow shared memory while deserializing; r=nika,lth
Tom Tung <ttung@mozilla.com> - Tue, 15 Oct 2019 13:42:25 +0000 - rev 562804
Push 2195 by ffxbld-merge at Mon, 25 Nov 2019 12:02:33 +0000
Bug 1583251 - P3 - Check if it is okay to allow shared memory while deserializing; r=nika,lth Differential Revision: https://phabricator.services.mozilla.com/D48349
5d5e3dc1711872b853b30dd061b6bd9030df4f45: Bug 1583251 - P2 - Fix some format nits or naming nits for StructuredClone::Write; r=nika,lth
Tom Tung <ttung@mozilla.com> - Tue, 15 Oct 2019 13:49:26 +0000 - rev 562803
Push 2195 by ffxbld-merge at Mon, 25 Nov 2019 12:02:33 +0000
Bug 1583251 - P2 - Fix some format nits or naming nits for StructuredClone::Write; r=nika,lth Differential Revision: https://phabricator.services.mozilla.com/D48348
f8eba20ecc6475c75ff6cf635d15052a332394a1: Bug 1586991 part 1 - Stop relying on null-terminated strings in wasm::TextToBinary. r=lth
Jan de Mooij <jdemooij@mozilla.com> - Tue, 08 Oct 2019 16:32:05 +0000 - rev 562082
Push 2195 by ffxbld-merge at Mon, 25 Nov 2019 12:02:33 +0000
Bug 1586991 part 1 - Stop relying on null-terminated strings in wasm::TextToBinary. r=lth Differential Revision: https://phabricator.services.mozilla.com/D48486
f7d1df2061e77d556eb36fac6b87c629d12f4038: Bug 1585957 - Minimal support for mips64r6 r=lth
Radovan Birdic <radovan.birdic@rt-rk.com> - Mon, 07 Oct 2019 13:38:17 +0300 - rev 561164
Push 2195 by ffxbld-merge at Mon, 25 Nov 2019 12:02:33 +0000
Bug 1585957 - Minimal support for mips64r6 r=lth