searching for reviewer(bbouvier)
fdf46ac2cd6468f3e4bfd7c028c9f1e88a57abbe: Bug 1539806 - Use zydis to disassemble cranelift code. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Tue, 02 Apr 2019 11:46:34 +0200 - rev 476793
Push 36107 by btara@mozilla.com at Tue, 04 Jun 2019 16:06:21 +0000
Bug 1539806 - Use zydis to disassemble cranelift code. r=bbouvier This performs the actual disassembly by calling the disassembler from Cranelift. Since the disassembler emits to a buffer we can use the jitspew for printing, thus we get output-to-file etc for free. Differential Revision: https://phabricator.services.mozilla.com/D27852
ccb4138ed2ff4f4a497492edc96b3f47c9646c5e: Bug 1556641 - mach vendor rust. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Tue, 04 Jun 2019 09:18:11 +0200 - rev 476790
Push 36107 by btara@mozilla.com at Tue, 04 Jun 2019 16:06:21 +0000
Bug 1556641 - mach vendor rust. r=bbouvier Pull in file changes after re-pointing cranelift to current HEAD. Differential Revision: https://phabricator.services.mozilla.com/D33599
8c0c1b2054ffa3ce7f8df63fd8564e00ab8d667c: Bug 1556641 - Re-point cranelift to current HEAD. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Tue, 04 Jun 2019 09:17:12 +0200 - rev 476789
Push 36107 by btara@mozilla.com at Tue, 04 Jun 2019 16:06:21 +0000
Bug 1556641 - Re-point cranelift to current HEAD. r=bbouvier We need this to be able to land the second half of the jump tables patch, since cranelift APIs have changed. Differential Revision: https://phabricator.services.mozilla.com/D33598
28264a198767c9081a59c119d240297890785de7: Bug 1547752 - Support jump tables in cranelift. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Tue, 21 May 2019 15:52:17 +0200 - rev 476788
Push 36107 by btara@mozilla.com at Tue, 04 Jun 2019 16:06:21 +0000
Bug 1547752 - Support jump tables in cranelift. r=bbouvier This patch uses the machinery submitted in https://github.com/CraneStation/cranelift/pull/774 to split the jump table (and any other read-only data) apart from the compiled code, so as to make room for the epilogue and proper alignment. The only difficult part about this is to update the instructions referencing the tables, and the table entries, when the tables are moved. Differential Revision: https://phabricator.services.mozilla.com/D32458
b32580fad0489689aa78fd4f43e58ee56ae33580: Bug 1554080 part 5 - Replace the masm.loadJitCodeNoArgCheck in GenerateImportJitExit with a TLS load. r=bbouvier
Jan de Mooij <jdemooij@mozilla.com> - Mon, 27 May 2019 14:14:46 +0000 - rev 475733
Push 36072 by dluca@mozilla.com at Tue, 28 May 2019 09:38:00 +0000
Bug 1554080 part 5 - Replace the masm.loadJitCodeNoArgCheck in GenerateImportJitExit with a TLS load. r=bbouvier This way we have two loads instead of three. Differential Revision: https://phabricator.services.mozilla.com/D32445
81d0d9e9990d250792aa42969236c9e248c04c45: Bug 1554080 part 4 - Store JitScript* instead of BaselineScript* in FuncImportTls. r=bbouvier
Jan de Mooij <jdemooij@mozilla.com> - Mon, 27 May 2019 14:08:23 +0000 - rev 475732
Push 36072 by dluca@mozilla.com at Tue, 28 May 2019 09:38:00 +0000
Bug 1554080 part 4 - Store JitScript* instead of BaselineScript* in FuncImportTls. r=bbouvier This has a few benefits: * Less toggling when we discard/reallocate the BaselineScript without discarding the JitScript. * Wasm's JIT exit optimization will work with the Baseline Interpreter in the future. * The next part will use this to eliminate a load. Differential Revision: https://phabricator.services.mozilla.com/D32444
e8484107b29e114c3d55338aae70e182a9441416: Bug 1554080 part 3 - Use UniquePtr for BaselineScript::dependentWasmImports_. r=bbouvier
Jan de Mooij <jdemooij@mozilla.com> - Mon, 27 May 2019 14:08:07 +0000 - rev 475731
Push 36072 by dluca@mozilla.com at Tue, 28 May 2019 09:38:00 +0000
Bug 1554080 part 3 - Use UniquePtr for BaselineScript::dependentWasmImports_. r=bbouvier Differential Revision: https://phabricator.services.mozilla.com/D32443
e98c9d639879d0e63fd435702094bc8a01d686b3: Bug 1554080 part 2 - Allow Wasm FFI calls to lazy link stub. r=bbouvier
Jan de Mooij <jdemooij@mozilla.com> - Mon, 27 May 2019 14:07:51 +0000 - rev 475730
Push 36072 by dluca@mozilla.com at Tue, 28 May 2019 09:38:00 +0000
Bug 1554080 part 2 - Allow Wasm FFI calls to lazy link stub. r=bbouvier The lazy link stub used to assume a JIT caller but this is no longer the case. We can then fold clearDependentWasmImports into unlinkDependentWasmImports. Differential Revision: https://phabricator.services.mozilla.com/D32442
2e66b838b3b6f6be9ce490c521744b391704d3ba: Bug 1554080 part 1 - Move jitCodeSkipArgCheck_ from JSScript to JitScript. r=bbouvier,iain
Jan de Mooij <jdemooij@mozilla.com> - Mon, 27 May 2019 14:07:32 +0000 - rev 475729
Push 36072 by dluca@mozilla.com at Tue, 28 May 2019 09:38:00 +0000
Bug 1554080 part 1 - Move jitCodeSkipArgCheck_ from JSScript to JitScript. r=bbouvier,iain This removes a word from JSScript and corresponding Wasm data structures. Furthermore, the skip-argument-type-checks optimization depends on JitScript's lifetime so moving it to JitScript feels right and might help catch bugs. Differential Revision: https://phabricator.services.mozilla.com/D32441
5a24881392eee8ac60706dcd4ffe9a7206766caf: Bug 1554111 - Add js/src/wasm/cranelift/src/ to the rustfmt list r=bbouvier
Sylvestre Ledru <sledru@mozilla.com> - Mon, 27 May 2019 07:22:04 +0000 - rev 475673
Push 36072 by dluca@mozilla.com at Tue, 28 May 2019 09:38:00 +0000
Bug 1554111 - Add js/src/wasm/cranelift/src/ to the rustfmt list r=bbouvier Differential Revision: https://phabricator.services.mozilla.com/D32437
c858f52192ad5f0a0169ccfe673beb5095cb0a36: Bug 1554053 - Wasm via Cranelift: size of interrupt check comparison is incorrect. r=bbouvier
Julian Seward <jseward@acm.org> - Fri, 24 May 2019 12:46:24 +0000 - rev 475365
Push 36060 by cbrindusan@mozilla.com at Fri, 24 May 2019 21:47:21 +0000
Bug 1554053 - Wasm via Cranelift: size of interrupt check comparison is incorrect. r=bbouvier This patch changes Wasm-via-CL to always use a 32-bit comparison for interrupt checks. Wasm-via-Cranelift generates code to do interrupt checks by doing a machine-word sized comparison. However, the compared-against value, TlsData::interrupt, is an Atomic<uint32_t, mozilla::Relaxed>, and so the comparison is incorrect on all 64 bit targets: it also compares the 4 bytes following TlsData::interrupt, which look to me as if they are an alignment hole (iow, junk). This is obviously incorrect, and it's observably inconsistent with what the -via-Ion and -baseline routes do, which is to always generate a 32-bit comparison. It also holds a potential danger of a store-forwarding stall (big read after small write), although, based on the struct layout and detailed reading of the Intel opt guide, I think it's probably harmless for the Intel Core architecture family. Differential Revision: https://phabricator.services.mozilla.com/D32421
978eb962906f3cc5e61b8c7364bb627b325a6231: Bug 1544041 - Add test-also support to wpt-in-jstests; r=bbouvier
Ms2ger <Ms2ger@igalia.com> - Tue, 16 Apr 2019 10:03:55 +0000 - rev 469645
Push 35878 by apavel@mozilla.com at Tue, 16 Apr 2019 15:43:40 +0000
Bug 1544041 - Add test-also support to wpt-in-jstests; r=bbouvier Differential Revision: https://phabricator.services.mozilla.com/D27478
9573e2163ca4009956027b6f2936871d8bb67586: Bug 1544041 - Add test-also support to wpt-in-jstests; r=bbouvier
Ms2ger <Ms2ger@igalia.com> - Mon, 15 Apr 2019 13:49:54 +0000 - rev 469497
Push 35873 by ccoroiu@mozilla.com at Mon, 15 Apr 2019 21:36:26 +0000
Bug 1544041 - Add test-also support to wpt-in-jstests; r=bbouvier Differential Revision: https://phabricator.services.mozilla.com/D27478
a4ad642832f5549367870e18b5b5f39ff36de373: Bug 1544383 - Fix WebAssembly class init in fuzzing target. r=bbouvier
Christian Holler <choller@mozilla.com> - Mon, 15 Apr 2019 12:24:50 +0000 - rev 469491
Push 35873 by ccoroiu@mozilla.com at Mon, 15 Apr 2019 21:36:26 +0000
Bug 1544383 - Fix WebAssembly class init in fuzzing target. r=bbouvier Differential Revision: https://phabricator.services.mozilla.com/D27486
c78a264f3226710b96db8832efaa1b30a9cd25a0: Bug 1538465 - WebAssembly Fuzzing Target. r=bbouvier
Christian Holler <choller@mozilla.com> - Thu, 11 Apr 2019 09:22:04 +0000 - rev 468966
Push 35855 by aciure@mozilla.com at Thu, 11 Apr 2019 16:11:15 +0000
Bug 1538465 - WebAssembly Fuzzing Target. r=bbouvier Differential Revision: https://phabricator.services.mozilla.com/D25919
3add6d625683792a585b16a13f3b82620a1e4aee: Bug 1538465 - WebAssembly Fuzzing Target. r=bbouvier
Christian Holler <choller@mozilla.com> - Wed, 10 Apr 2019 17:15:20 +0000 - rev 468899
Push 35854 by aciure@mozilla.com at Thu, 11 Apr 2019 09:50:57 +0000
Bug 1538465 - WebAssembly Fuzzing Target. r=bbouvier Differential Revision: https://phabricator.services.mozilla.com/D25919
babe08d04201153f26d7b1f0fa7400bcc7f1790c: Bug 1529957 - Baldr: don't accept asm.js functions for table elements (r=bbouvier)
Luke Wagner <luke@mozilla.com> - Tue, 26 Mar 2019 20:31:56 -0500 - rev 466812
Push 35781 by opoprus@mozilla.com at Fri, 29 Mar 2019 21:56:26 +0000
Bug 1529957 - Baldr: don't accept asm.js functions for table elements (r=bbouvier) Differential Revision: https://phabricator.services.mozilla.com/D25011
ace72ffa3103e0c937c995b08f9127960d4ed183: Bug 1529957 - Baldr: create lazy stubs even more lazily (r=bbouvier)
Luke Wagner <luke@mozilla.com> - Tue, 26 Mar 2019 20:09:43 -0500 - rev 466811
Push 35781 by opoprus@mozilla.com at Fri, 29 Mar 2019 21:56:26 +0000
Bug 1529957 - Baldr: create lazy stubs even more lazily (r=bbouvier) Differential Revision: https://phabricator.services.mozilla.com/D25010
5de97868cb80ae505bf52312dc47590e221d64bb: Bug 1529957 - Baldr: don't require WASM_CODEGEN_DEBUG for JitOptions that disable opts (r=bbouvier)
Luke Wagner <luke@mozilla.com> - Tue, 26 Mar 2019 19:58:23 -0500 - rev 466810
Push 35781 by opoprus@mozilla.com at Fri, 29 Mar 2019 21:56:26 +0000
Bug 1529957 - Baldr: don't require WASM_CODEGEN_DEBUG for JitOptions that disable opts (r=bbouvier) Differential Revision: https://phabricator.services.mozilla.com/D25008
8fc0d70bdba10bc969603f5bcbbc3b4e86bb190b: Bug 1529957 - Baldr: allow wasm functions to have func indices (r=bbouvier)
Luke Wagner <luke@mozilla.com> - Tue, 26 Mar 2019 18:47:14 -0500 - rev 466809
Push 35781 by opoprus@mozilla.com at Fri, 29 Mar 2019 21:56:26 +0000
Bug 1529957 - Baldr: allow wasm functions to have func indices (r=bbouvier) Differential Revision: https://phabricator.services.mozilla.com/D25007
29582b2a7db1f46fd30d47769a965d9c693a2019: Bug 1529681 - Update bindgen. r=bbouvier
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 27 Mar 2019 14:39:41 +0000 - rev 466373
Push 35768 by opoprus@mozilla.com at Thu, 28 Mar 2019 09:55:54 +0000
Bug 1529681 - Update bindgen. r=bbouvier This works around an LLVM bug and also pulls a fair amount of bugfixes and perf improvements. None of the breaking changes affect either the style system or cranelift stuff. Changelog for convenience: https://github.com/rust-lang/rust-bindgen/compare/v0.43.2...v0.49.0 Differential Revision: https://phabricator.services.mozilla.com/D20899
009a7361fc1b4dd6852300e52cfc5b541d9f58f0: Bug 1535609 - Root pointer args in callExport. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Tue, 19 Mar 2019 18:01:40 +0100 - rev 465453
Push 35739 by ccoroiu@mozilla.com at Thu, 21 Mar 2019 22:00:13 +0000
Bug 1535609 - Root pointer args in callExport. r=bbouvier In the slow callExport path, we convert arguments left-to-right and these conversions can both OOM and error out for other reasons, and they may perform various computations, notably allocation. Therefore any reference arguments must be rooted until all the conversions are finished. However, the arguments are computed into a plain Vector<> whose layout we need to control tightly and whose elements are not easily rootable. So we keep a separate rooted vector of reference values and when we encounter a reference argument we push that argument onto this, and before the actual call we move the reference values (which may have been altered by GC) into the argument array; this copying is atomic with respect to gc + the invocation, and once we're in the callee the normal rooting logic (via stackmaps) takes over. Differential Revision: https://phabricator.services.mozilla.com/D24061
38c2cb5142ebe1494b1f8720c9439bd8448f2255: Bug 1533932 - Handle prebarriers properly for wasm tables. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Fri, 15 Mar 2019 13:17:18 +0100 - rev 465370
Push 35737 by ncsoregi@mozilla.com at Thu, 21 Mar 2019 10:41:32 +0000
Bug 1533932 - Handle prebarriers properly for wasm tables. r=bbouvier Two problems needed to be fixed: - JS::Heap<> only has a postbarrier, not a prebarrier also; this is what triggered the original error report. The type in table-of-anyref therefore needs to be js::HeapPtr<>, so that we get both barriers. (It can't be GCPtr because the vector storage may be moved as the table grows.) - The API for table.get returns a pointer into underlying vector storage or null; if not null, the pointer must be dereferenced to obtain the actual value. Since the vector storage may move during GC and grow operations the pointer is really only valid until the next operation that might move the vector. That lifetime restriction was not enforced in Ion-generated code and the dereference could in principle move far enough during optimization for it to become invalid, though in practice it is extremely unlikely that this was actually a problem. We fix this by flagging the dereference as non-movable, and by changing some names and comments to highlight the issue. Differential Revision: https://phabricator.services.mozilla.com/D23665
add98afa5f0ca1ca17aa87eaa045442a3e1fa07a: Bug 1529691 - use futures in order to process in parallel clang-format. r=bbouvier
Andi-Bogdan Postelnicu <bpostelnicu@mozilla.com> - Tue, 12 Mar 2019 18:58:46 +0000 - rev 463693
Push 35691 by nbeleuzu@mozilla.com at Tue, 12 Mar 2019 21:43:52 +0000
Bug 1529691 - use futures in order to process in parallel clang-format. r=bbouvier Parts of this patch were taken from the original work of :bbouvier in Bug 1521772. We needed to revert Bug 1521772 since it broken Windows compatibility. Differential Revision: https://phabricator.services.mozilla.com/D23100
4e5dbbdb10f31f6cf8460011c46a47dd4d135b7f: Bug 1490048 - add cranelift to raptor wasm-misc and wasm-godot tests. r=bbouvier,rwood
Joel Maher <jmaher@mozilla.com> - Tue, 12 Mar 2019 14:42:45 +0000 - rev 463638
Push 35691 by nbeleuzu@mozilla.com at Tue, 12 Mar 2019 21:43:52 +0000
Bug 1490048 - add cranelift to raptor wasm-misc and wasm-godot tests. r=bbouvier,rwood add cranelift to raptor wasm-misc and wasm-godot tests. Differential Revision: https://phabricator.services.mozilla.com/D23144
1f10307fec284c52fbaf8d8423b47e762b9f0990: Bug 1532851 - Unbreak BSDs build on powerpc64 after bug 1462566. r=bbouvier
Jan Beich <jbeich@FreeBSD.org> - Wed, 06 Mar 2019 02:35:04 +0000 - rev 462596
Push 35656 by ncsoregi@mozilla.com at Wed, 06 Mar 2019 16:13:00 +0000
Bug 1532851 - Unbreak BSDs build on powerpc64 after bug 1462566. r=bbouvier Define R32_sig, R01_sig based on: https://github.com/openbsd/src/blob/master/sys/arch/powerpc/include/signal.h https://github.com/netbsd/src/blob/trunk/sys/arch/powerpc/include/mcontext.h https://github.com/freebsd/freebsd/blob/master/sys/powerpc/include/ucontext.h
74ab0e9aebf5cea683ca7c9b8fd77303e223c3b9: Bug 1531731 - Register MWasmLoadRef and MWasmStoreRef with AliasAnalysis. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Fri, 01 Mar 2019 14:10:40 +0100 - rev 462095
Push 35635 by rmaries@mozilla.com at Sat, 02 Mar 2019 09:41:56 +0000
Bug 1531731 - Register MWasmLoadRef and MWasmStoreRef with AliasAnalysis. r=bbouvier These new nodes participate in alias analysis and so must be made known to the alias analysis framework. Differential Revision: https://phabricator.services.mozilla.com/D21681
9453f4e1827d249f898b214f549c2fc08931d81c: Bug 1531670 - Replace ENABLE_WASM_GENERALIZED_TABLES. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Fri, 01 Mar 2019 09:33:31 +0100 - rev 462094
Push 35635 by rmaries@mozilla.com at Sat, 02 Mar 2019 09:41:56 +0000
Bug 1531670 - Replace ENABLE_WASM_GENERALIZED_TABLES. r=bbouvier Replace all uses of ENABLE_WASM_GENERALIZED_TABLES with ENABLE_WASM_REFTYPES, plus some knock-on effects. Replace all uses of wasmGeneralizedTables with wasmReftypesEnabled. Drive-by fix: replace 'anyfunc' in a couple of error strings with the canonical 'funcref'. Drive-by fix: remove isSimdAvailable, it is not used and we have no SIMD. Differential Revision: https://phabricator.services.mozilla.com/D21653
b79be6791cfaf2fc5ba2a89b0eb89e2dce52f1bf: Bug 1524923 - Support local.get, local.set, global.get, global.set. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Thu, 28 Feb 2019 09:55:51 +0100 - rev 461740
Push 35628 by opoprus@mozilla.com at Thu, 28 Feb 2019 21:47:53 +0000
Bug 1524923 - Support local.get, local.set, global.get, global.set. r=bbouvier I've only added support for these, renamed in a couple of error messages and a few test cases, not renamed all the uses, because there are so many. Will file followup bugs for that work, but it won't be urgent. Note, wabt no longer recognizes get_local et al, it requires local.get etc. But we should remain backward compatible for a long while still. Differential Revision: https://phabricator.services.mozilla.com/D21502
5c4daba349dc2484188abd2c301b35ccd2d4aa08: Bug 1530273 - Make 'funcref' the canonical name. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Wed, 27 Feb 2019 18:03:44 +0100 - rev 461739
Push 35628 by opoprus@mozilla.com at Thu, 28 Feb 2019 21:47:53 +0000
Bug 1530273 - Make 'funcref' the canonical name. r=bbouvier Wabt is now supporting funcref exclusively, and with the reftypes proposal I think there's broad agreement that we will stop using anyfunc. So let's accept funcref both in the text format and in the table creation dictionary, and let's use this name as the canonical name in error messages and similar. But let's also continue to accept anyfunc, since there may be in-flight tests and other content that uses it. This includes a couple of emscripten-compiled benchmarks currently in the repo; I chose not to change those. Differential Revision: https://phabricator.services.mozilla.com/D21388
8eb14440dc5b45373528a2feb57e03a45254fcc8: Bug 1515917 - Multiple test-also flags + fix disablement tests. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Tue, 26 Feb 2019 09:08:44 +0100 - rev 461637
Push 35626 by csabou@mozilla.com at Thu, 28 Feb 2019 11:31:08 +0000
Bug 1515917 - Multiple test-also flags + fix disablement tests. r=bbouvier Allowing test-also to take multiple flags improves test coverage since we can test eg --wasm-gc --wasm-compiler=ion. Doing so uncovered some weaknesses in the tests that test what happens when features are disabled either by configuration or by flag, so this patch also fixes those problems and comments them more carefully." Differential Revision: https://phabricator.services.mozilla.com/D21180
4d220064bcf8acbb47a26c9d622c45d3df67231d: Bug 1529681 - Update bindgen. r=bbouvier
Emilio Cobos Álvarez <emilio@crisal.io> - Mon, 25 Feb 2019 09:25:10 -0800 - rev 460935
Push 35613 by nerli@mozilla.com at Tue, 26 Feb 2019 03:52:35 +0000
Bug 1529681 - Update bindgen. r=bbouvier
e99833064d36f1a2d144d2719acab4dc970bcc92: Bug 1529681 - Update bindgen. r=bbouvier
Emilio Cobos Álvarez <emilio@crisal.io> - Mon, 25 Feb 2019 09:43:11 +0000 - rev 460909
Push 35613 by nerli@mozilla.com at Tue, 26 Feb 2019 03:52:35 +0000
Bug 1529681 - Update bindgen. r=bbouvier This works around an LLVM bug and also pulls a fair amount of bugfixes and perf improvements. None of the breaking changes affect either the style system or cranelift stuff. Changelog for convenience: https://github.com/rust-lang/rust-bindgen/compare/v0.43.2...v0.47.2 Differential Revision: https://phabricator.services.mozilla.com/D20899
191134cfd07c213003c5153473df6780603068ba: Bug 1529349 - Baldr: detect invalid section before code section during streaming compilation (r=bbouvier)
Luke Wagner <luke@mozilla.com> - Fri, 22 Feb 2019 09:35:19 -0600 - rev 460705
Push 35597 by rmaries@mozilla.com at Sat, 23 Feb 2019 04:15:57 +0000
Bug 1529349 - Baldr: detect invalid section before code section during streaming compilation (r=bbouvier)
10030bd8ac3dd4d0333aae3a44ecfbbe5bb75bec: Bug 1520931 - Baldr: another follow-up simplification from asm.js caching removal (r=bbouvier)
Luke Wagner <luke@mozilla.com> - Mon, 18 Feb 2019 17:12:31 -0600 - rev 459828
Push 35575 by cbrindusan@mozilla.com at Tue, 19 Feb 2019 04:40:03 +0000
Bug 1520931 - Baldr: another follow-up simplification from asm.js caching removal (r=bbouvier)
412fb2a5ae54cebfbcfe8ab7a4cd544c3bfad9e5: Bug 1466464 - rename grow_memory and current_memory. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Thu, 14 Feb 2019 18:05:17 +0100 - rev 459746
Push 35571 by csabou@mozilla.com at Mon, 18 Feb 2019 15:52:47 +0000
Bug 1466464 - rename grow_memory and current_memory. r=bbouvier Rename the uses of current_memory and grow_memory in wasm text content as memory.size and memory.grow, since these are canonical. Rename GrowMemory as MemoryGrow and CurrentMemory as MemorySize everywhere in C++ source code, in honor of their new .wat names -- consistency is good. I chose "Memory" over "Mem" because I like the longer name better, and I think we should rename uses of "Mem" as "Memory" (but not in this patch). Also handle some similar cases, like the growMemory_i32 and currentMemory_i32 Instance methods. Note a couple of changes in cranelift. I did not remove support for the old .wat names yet, I figure we can do that some other year, if ever. Differential Revision: https://phabricator.services.mozilla.com/D19816
6cb3a502e891550adfb1754001169885c891f375: Bug 1526579 - Rabaldr arm64 stack alignment fix. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Tue, 12 Feb 2019 10:39:23 +0100 - rev 458720
Push 35546 by rmaries@mozilla.com at Wed, 13 Feb 2019 04:27:59 +0000
Bug 1526579 - Rabaldr arm64 stack alignment fix. r=bbouvier Problem: When a stack chunk had to be popped as part of a control flow instruction, the amount to pop was not always computed as a multiple of ChunkSize. The reason is that the fixed amount of stack that should not be popped isn't necessarily a multiple of ChunkSize, yet this was assumed. A small adjustment to the calculation fixes that. Also added an assertion that would have caught this problem more easily. Also did some desirable drive-by fixes to clarify documentation and to factor the resulting code. The TC sets up a situation where we require a chunk to be created and then destroyed in the 'else' arm of the 'if', at the same time as the fixed amount of stack is not a multiple of ChunkSize. Differential Revision: https://phabricator.services.mozilla.com/D19470
7b01a3234d6911eeb3a854106ecdb585b48fc9fc: Bug 1520931 - Remove nestedShell() testing function (r=bbouvier)
Luke Wagner <luke@mozilla.com> - Mon, 11 Feb 2019 11:43:00 -0600 - rev 458544
Push 35537 by btara@mozilla.com at Mon, 11 Feb 2019 21:55:45 +0000
Bug 1520931 - Remove nestedShell() testing function (r=bbouvier)
94cf160df1de8e168671f872f6fee08b9d6ce121: Bug 1520931 - Remove asm.js cache hooks JS API (r=bbouvier)
Luke Wagner <luke@mozilla.com> - Mon, 11 Feb 2019 11:41:57 -0600 - rev 458543
Push 35537 by btara@mozilla.com at Mon, 11 Feb 2019 21:55:45 +0000
Bug 1520931 - Remove asm.js cache hooks JS API (r=bbouvier)
d7989f40291e2d1551e4e86c611e9b5cde008da5: Bug 1522298 - ARM64: Ensure that the emulated stack pointer is restored when returning from WASM. r=bbouvier,sstangl
Nicolas B. Pierron <nicolas.b.pierron@nbp.name> - Mon, 11 Feb 2019 13:07:15 +0000 - rev 458477
Push 35536 by btara@mozilla.com at Mon, 11 Feb 2019 21:54:04 +0000
Bug 1522298 - ARM64: Ensure that the emulated stack pointer is restored when returning from WASM. r=bbouvier,sstangl Differential Revision: https://phabricator.services.mozilla.com/D19185
5d720cbe1187b8ef658ab5098fdaf9f36e532504: Bug 1521939 - Correct the offset for reading stack args on ARM64. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Thu, 07 Feb 2019 11:12:06 +0100 - rev 458290
Push 35523 by nbeleuzu@mozilla.com at Sat, 09 Feb 2019 03:36:09 +0000
Bug 1521939 - Correct the offset for reading stack args on ARM64. r=bbouvier In the optimized stub, we forgot to account for the frameAlignExtra word when computing the offset from the SP at which stack args are read. The test case finds the problem on the ARM64 simulator, and does not need any special parameters, just to run long enough for a JS JIT to kick in. Also a drive-by fix for an incorrect NaN canonicalization along the non-toValue path, cf the Double case right above it. This code changed recently when I introduced the ScratchFloat32Scope, but the bug predates that. Differential Revision: https://phabricator.services.mozilla.com/D18942
cf80e6400e94f8c75681c897df19b17872447c50: Bug 1524256 - Remove two copies of wast.js; r=bbouvier
Ms2ger <Ms2ger@igalia.com> - Thu, 31 Jan 2019 14:51:04 +0100 - rev 456242
Push 35476 by rmaries@mozilla.com at Thu, 31 Jan 2019 16:58:27 +0000
Bug 1524256 - Remove two copies of wast.js; r=bbouvier
5653b13f5b382b08a020bafa8f9b32b1551579b0: Bug 1522499 - Allow normal OOM in gc/bug-1214781.js. r=bbouvier
Tooru Fujisawa <arai_a@mac.com> - Thu, 24 Jan 2019 16:03:47 +0000 - rev 455282
Push 35428 by nbeleuzu@mozilla.com at Thu, 24 Jan 2019 21:42:11 +0000
Bug 1522499 - Allow normal OOM in gc/bug-1214781.js. r=bbouvier Differential Revision: https://phabricator.services.mozilla.com/D17517
7543b4c2813c76e1e2a3cc70fea991e725654877: Bug 1515917 - Generalize testing for wasm GC availability. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Fri, 21 Dec 2018 12:41:52 +0100 - rev 453408
Push 35355 by rmaries@mozilla.com at Fri, 11 Jan 2019 15:31:02 +0000
Bug 1515917 - Generalize testing for wasm GC availability. r=bbouvier Generalize the testing of GC availability so that it more accurately reflects whether GC support is actually available, this is a complicated predicate at present. (This was motivated by an attempt to generalize the testing directives, but that generalization does not land yet because it has some obscure effects that need to be addressed first.) The generalization sets us up for splitting apart the code and test cases for the "reftypes" and "gctypes" proposals in a subsequent patch.
676b002d0640f8bc91806f65043f5bdf28f93556: Bug 1511429 - Run a test only if no JS jit compilation. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Thu, 03 Jan 2019 13:42:41 +0100 - rev 453244
Push 35350 by btara@mozilla.com at Thu, 10 Jan 2019 17:21:43 +0000
Bug 1511429 - Run a test only if no JS jit compilation. r=bbouvier We're looking for a specific stack layout here and we'll not run the test if there are jits that may upset the stack. (The alternative would be to add more stack candidates but since we're really only interested in testing write wasm barrier functionality that's not necessary.)
0d11eb20a6af24bb4d332cbbc7bacc4d6cebcc36: Bug 1508665 - Split BaseStackFrame to simplify it. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Mon, 26 Nov 2018 15:15:59 +0100 - rev 449158
Push 35145 by aciure@mozilla.com at Sun, 02 Dec 2018 09:46:48 +0000
Bug 1508665 - Split BaseStackFrame to simplify it. r=bbouvier BaseStackFrame is split into two parts: - BaseStackFrameAllocator is now responsible for dealing with stack allocation and deallocation in all complex cases (which means everything except for the simple native masm.Push and masm.Pop cases). - What's left of BaseStackFrame is then a simple-to-use API for the rest of the compiler that maintains and checks invariants and does various kinds of bookkeeping and hides the remaining differences between the chunky and non-chunky stacks. The latter class inherits from the former because this is simplest (and it's easy to accomplish with 'protected'). There are a couple of minor functional changes here: - The variable maxFramePushed_ now actually records the maximum value of masm.framePushed, not the maximum stack height. The new behavior is correct even with the chunky stack, since this value is used for stack overflow checking. There should however be no observable changes because of this. (Trivial reason: only ARM64 is affected and we have no ARM64 products. Deeper reason: stacks are aligned at coarser boundaries than our stack chunks, and have lots of headroom.) - Member variables tracking the stack height are now set up in a new method, onFixedStackAllocated(), which is called after beginFunction() has allocated the space for the Header and Local areas of the frame. The old behavior was correct but very obscure. The new code is easier to understand.
3d330442ef3b3beddb0e71a95573e5cce49207dc: Bug 1507819 - Update to Cranelift 0.25. r=bbouvier
Dan Gohman <sunfish@mozilla.com> - Tue, 27 Nov 2018 00:06:00 +0200 - rev 448403
Push 35112 by csabou@mozilla.com at Wed, 28 Nov 2018 04:08:44 +0000
Bug 1507819 - Update to Cranelift 0.25. r=bbouvier
45b378c260d9308b6b067e42da3412961d431128: Bug 1507785 - Use logical, not physical, frame size at block exit. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Mon, 19 Nov 2018 09:45:32 +0100 - rev 447971
Push 35101 by ncsoregi@mozilla.com at Mon, 26 Nov 2018 16:18:20 +0000
Bug 1507785 - Use logical, not physical, frame size at block exit. r=bbouvier Background: When we branch out of a block we must adjust the physical stack pointer along the edge so that it will be equal to the physical stack pointer as it is when we fall out of the block at the bottom. But along the edge we do not do anything to adjust the logical stack pointer, because the logical stack pointer is determined by the non-branching path through the code. But when we fall out of a block we must adjust both the physical and the logical stack pointers: the logical stack pointer may need to pop a few items to get to where it was on entry to the block (the stack can be higher because of pushes followed by an UNREACHABLE), and if the code is not dead we may also have to deallocate some stack memory by changing the physical stack pointer. Previously, we used values for the physical stack pointers as guards on the block-exit code, but this is WRONG since it prevents us from doing something when the physical stack pointer does not change, as the case is on ARM64 when we do need to pop something logically but the stack stays within the currently allocated chunk - we would end up doing nothing when we should adjust the logical stack pointer. Instead, we should use the logical stack pointers for the guard, and then popChunkyBytes will take care of translating the difference in logical pointers for us so that a chunk is popped if that is required by the amount of deallocation. To catch these errors earlier we add an assertion on the logical stack frame size that is tested for every instruction we compile. The test case is reduced from the fuzzing test that found the bug.
31a42178a876106cc4cce885b94afef0275d89c7: Bug 1507944 - Baldr: ensure signal handlers in asm.js instantiation (r=bbouvier)
Luke Wagner <luke@mozilla.com> - Mon, 19 Nov 2018 14:43:56 -0600 - rev 447332
Push 35074 by shindli@mozilla.com at Tue, 20 Nov 2018 21:44:49 +0000
Bug 1507944 - Baldr: ensure signal handlers in asm.js instantiation (r=bbouvier)
5931ccb19e50e7e40e53173b8caa4403c9b35b8e: Bug 1506352 - Add a --log-wptreport option to jstests; r=bbouvier,jgraham
Ms2ger <Ms2ger@igalia.com> - Tue, 20 Nov 2018 14:00:23 +0100 - rev 447258
Push 35074 by shindli@mozilla.com at Tue, 20 Nov 2018 21:44:49 +0000
Bug 1506352 - Add a --log-wptreport option to jstests; r=bbouvier,jgraham