searching for reviewer(bbouvier)
94aa4cd72aed19410ec3cfb69bdc9c4de0543d72: Bug 1668532 part 1 - Port MIonToWasmCall optimization to Warp. r=bbouvier,iain
Jan de Mooij <jdemooij@mozilla.com> - Tue, 13 Oct 2020 14:33:42 +0000 - rev 552921
Push 37860 by ccoroiu@mozilla.com at Wed, 14 Oct 2020 16:38:28 +0000
Bug 1668532 part 1 - Port MIonToWasmCall optimization to Warp. r=bbouvier,iain Mostly based on IonBuilder::inlineWasmCall. Because there's a post-conversion instruction for i64 => BigInt, we unfortunately have to relax some assertions around resume points. Differential Revision: https://phabricator.services.mozilla.com/D92579
d548bb7ebca0a5fc219a31e570baa28605837fcd: Bug 1668398: vendor Cranelift 57fed697920cb888c6cb7e406d13518f7edd12ea. r=bbouvier
Chris Fallin <cfallin@mozilla.com> - Fri, 02 Oct 2020 20:02:51 +0000 - rev 551337
Push 37830 by nbeleuzu@mozilla.com at Sat, 03 Oct 2020 10:23:35 +0000
Bug 1668398: vendor Cranelift 57fed697920cb888c6cb7e406d13518f7edd12ea. r=bbouvier This patch pulls in the latest version of Cranelift, which includes necessary updates to support some recent work on the Wasm backend (e.g., support for the new ABI in PR #2223). Differential Revision: https://phabricator.services.mozilla.com/D92000
92a01ad5e890aeda140d46dc4d075bca585d45c4: Bug 1668398: vendor Cranelift b8f0dc429f2b886e7423122223393b2c7ee3cd4f. r=bbouvier
Chris Fallin <cfallin@mozilla.com> - Thu, 01 Oct 2020 17:28:30 +0000 - rev 551145
Push 37825 by abutkovits@mozilla.com at Fri, 02 Oct 2020 04:10:47 +0000
Bug 1668398: vendor Cranelift b8f0dc429f2b886e7423122223393b2c7ee3cd4f. r=bbouvier This patch pulls in the latest version of Cranelift, which includes necessary updates to support some recent work on the Wasm backend (e.g., support for the new ABI in PR #2223). Differential Revision: https://phabricator.services.mozilla.com/D92000
8cee8448e4d28cb7dc58fe963f836e97c0e8c616: Bug 1668261 - ARM64 cache simulator must be under ifdef. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Thu, 01 Oct 2020 13:38:46 +0000 - rev 551086
Push 37825 by abutkovits@mozilla.com at Fri, 02 Oct 2020 04:10:47 +0000
Bug 1668261 - ARM64 cache simulator must be under ifdef. r=bbouvier The cache simulation must be guarded by the correct ifdef. Also, two debug-only variables should be flagged as such. Differential Revision: https://phabricator.services.mozilla.com/D91927
6a81d2da051d9870405d833303567112ccd17e85: Bug 1666568 - Initialize null jump table entries only once. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Mon, 28 Sep 2020 13:38:36 +0000 - rev 550544
Push 37818 by btara@mozilla.com at Mon, 28 Sep 2020 21:28:24 +0000
Bug 1666568 - Initialize null jump table entries only once. r=bbouvier Differential Revision: https://phabricator.services.mozilla.com/D91568
4d530fda38c294549a80f51db315c9279fdbec77: Bug 1660862 - Use the JIT's interpreter-trampoline for Wasm exports with lazy stubs. r=bbouvier
Jan de Mooij <jdemooij@mozilla.com> - Fri, 28 Aug 2020 14:29:11 +0000 - rev 546786
Push 37737 by csabou@mozilla.com at Sat, 29 Aug 2020 09:12:26 +0000
Bug 1660862 - Use the JIT's interpreter-trampoline for Wasm exports with lazy stubs. r=bbouvier This ensures isWasmWithJitEntry() is always true for the function, fixing a perf cliff with ICs (function was called with native ABI instead of JIT ABI). It also fixes an assertion failure when Warp is enabled. Differential Revision: https://phabricator.services.mozilla.com/D88383
80dd9793528686d9235ed71f884a9e42cba6efc6: Bug 1661064 - Enable wasm atomics when compiling via the Cranelift x64 new backend. r=bbouvier.
Julian Seward <jseward@acm.org> - Wed, 26 Aug 2020 15:27:58 +0000 - rev 546321
Push 37734 by ccoroiu@mozilla.com at Thu, 27 Aug 2020 09:30:43 +0000
Bug 1661064 - Enable wasm atomics when compiling via the Cranelift x64 new backend. r=bbouvier. As of bug 1660976, the in-tree Cranelift copy supports wasm atomics when compiling via the new x64 back end. This small patch contains the SM-side changes required to allow wasm atomics to be passed into that compilation pipeline. Differential Revision: https://phabricator.services.mozilla.com/D88245
3cb239ffbc9275e47016e482bb8dccd3c76f1736: Bug 1661231 - Add link to ARM64 ICache invalidation discussion. r=bbouvier DONTBUILD
Nicolas B. Pierron <nicolas.b.pierron@nbp.name> - Wed, 26 Aug 2020 12:56:18 +0000 - rev 546308
Push 37733 by nbeleuzu@mozilla.com at Wed, 26 Aug 2020 21:41:21 +0000
Bug 1661231 - Add link to ARM64 ICache invalidation discussion. r=bbouvier DONTBUILD Differential Revision: https://phabricator.services.mozilla.com/D88256
6fd91eb3163b03c881f9380ba21e1c425fa748db: Bug 1660976 - Output of mach vendor rust; r=bbouvier.
Julian Seward <jseward@acm.org> - Tue, 25 Aug 2020 10:56:36 +0000 - rev 546119
Push 37731 by apavel@mozilla.com at Wed, 26 Aug 2020 03:24:37 +0000
Bug 1660976 - Output of mach vendor rust; r=bbouvier. Depends on D88132 Differential Revision: https://phabricator.services.mozilla.com/D88133
59f6bb8d7ca213be70ea53a0d20ffbf22fe66232: Bug 1660976 - Bump Cranelift to 7c856542854bc8c5da9d5fb1a0b41f3c660d8484; r=bbouvier.
Julian Seward <jseward@acm.org> - Tue, 25 Aug 2020 10:55:46 +0000 - rev 546118
Push 37731 by apavel@mozilla.com at Wed, 26 Aug 2020 03:24:37 +0000
Bug 1660976 - Bump Cranelift to 7c856542854bc8c5da9d5fb1a0b41f3c660d8484; r=bbouvier. Differential Revision: https://phabricator.services.mozilla.com/D88132
bd8b53cf8058f0f5d1e3f7030731160a50925dec: Bug 1659667 - expect less specific NaN values. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Thu, 20 Aug 2020 14:08:40 +0000 - rev 545500
Push 37715 by apavel@mozilla.com at Thu, 20 Aug 2020 21:21:07 +0000
Bug 1659667 - expect less specific NaN values. r=bbouvier These test cases expected specific payloads for some NaN results but the wasm spec does not guarantee that, and some implementations of some architectures will not return the same payloads as x64. So adjust the tests. Differential Revision: https://phabricator.services.mozilla.com/D87455
6ee66102bad00997af60452e6eb0c3a718b3724d: Bug 1656832 - Remove setARMHwCapFlags testing functions. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Mon, 17 Aug 2020 13:07:49 +0000 - rev 544926
Push 37706 by csabou@mozilla.com at Mon, 17 Aug 2020 21:46:02 +0000
Bug 1656832 - Remove setARMHwCapFlags testing functions. r=bbouvier This removes the testing function and adjusts the tests that use it. One test is removed because wasm, and asm.js, are not available without floating point support (guarded against in HasSupport). The patch also documents the meaning and logic of the remaining hardware flag management. There is already a command line switch for setting the ARM flags (and an environment variable) so we don't need to introduce anything to allow flags to be set. However, this code needed to be updated to properly compute the JIT flags after setting the ARM flags. Test cases are introduced to test that wasm is not available in situations where the required hardware is not in place. A final adjustment is made to HasSupport: It can call JitSupportsAtomics() rather than test the ARM flags directly, since the jit tests those flags on ARM. Differential Revision: https://phabricator.services.mozilla.com/D87262
2d117fa859d8fd79811a745041335b5f3a9b620d: Bug 1645310 - Make presence of the WebAssembly object not depend on the debugger having been activated. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Thu, 30 Jul 2020 09:10:38 +0000 - rev 542582
Push 37652 by cbrindusan@mozilla.com at Thu, 30 Jul 2020 15:44:30 +0000
Bug 1645310 - Make presence of the WebAssembly object not depend on the debugger having been activated. r=bbouvier This changes the meaning of wasm::HasSupport() to depend only on settings and context (eg, whether in a secure context or not), not to depend on whether circumstances have made wasm compilation possible or not. In particular, if the baseline compiler is not enabled and the debugger is then activated, then compilation will become impossible. Up till now HasSupport would go from returning true to returning false when that happens. But HasSupport is used to determine whether the global WebAssembly object should be (lazily) created. Thus the presence of that object in the JS environment would depend on whether a debugger was instantiated before the object needed to be lazily created. Instead, HasSupport can be invariant of that, we just need to test for compiler support in a couple of other places instead. Differential Revision: https://phabricator.services.mozilla.com/D85134
6199e8c135f3f2b39a755fc1c83facd00b1d8fc6: Bug 1645310 - Make presence of the WebAssembly object not depend on the debugger having been activated. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Thu, 30 Jul 2020 08:02:36 +0000 - rev 542577
Push 37652 by cbrindusan@mozilla.com at Thu, 30 Jul 2020 15:44:30 +0000
Bug 1645310 - Make presence of the WebAssembly object not depend on the debugger having been activated. r=bbouvier This changes the meaning of wasm::HasSupport() to depend only on settings and context (eg, whether in a secure context or not), not to depend on whether circumstances have made wasm compilation possible or not. In particular, if the baseline compiler is not enabled and the debugger is then activated, then compilation will become impossible. Up till now HasSupport would go from returning true to returning false when that happens. But HasSupport is used to determine whether the global WebAssembly object should be (lazily) created. Thus the presence of that object in the JS environment would depend on whether a debugger was instantiated before the object needed to be lazily created. Instead, HasSupport can be invariant of that, we just need to test for compiler support in a couple of other places instead. Differential Revision: https://phabricator.services.mozilla.com/D85134
d5744b7630496535168f1f3964662a46764df329: Bug 1653977 - misc bugs for immutable v128 globals. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Tue, 28 Jul 2020 09:31:39 +0000 - rev 542298
Push 37646 by btara@mozilla.com at Tue, 28 Jul 2020 15:04:40 +0000
Bug 1653977 - misc bugs for immutable v128 globals. r=bbouvier Two bugs for the price of one test case! - when initializing an immutable exported v128 global, a code path in WasmGlobalObject::setVal was taken that would MOZ_CRASH, but should not. - the baseline compiler did not have a code path for reading an immutable v128 global, and would MOZ_CRASH. No drama, just corner cases that were unimplemented and untested. Differential Revision: https://phabricator.services.mozilla.com/D84999
f3792719ddb6c57476d9503694c48b27637f50cc: Bug 1651799 - Add test to ensure experimental features are not released. r=bbouvier
Ryan Hunt <rhunt@eqrion.net> - Mon, 27 Jul 2020 21:13:53 +0000 - rev 542240
Push 37645 by ccoroiu@mozilla.com at Tue, 28 Jul 2020 09:47:25 +0000
Bug 1651799 - Add test to ensure experimental features are not released. r=bbouvier This commit adds a test that tracks all experimental wasm features and asserts that if they are enabled, then we must be in nightly. Each feature is also given a small feature detection module that will fail to compile when it's not enabled for extra protection. Differential Revision: https://phabricator.services.mozilla.com/D83424
9961de8d65f88be010a39d982173eca9d90e2026: Bug 1651799 - Remove bulk-memory configuration options. r=bbouvier
Ryan Hunt <rhunt@eqrion.net> - Mon, 27 Jul 2020 21:13:35 +0000 - rev 542239
Push 37645 by ccoroiu@mozilla.com at Tue, 28 Jul 2020 09:47:25 +0000
Bug 1651799 - Remove bulk-memory configuration options. r=bbouvier Bulk memory is now enabled for all compilers and platforms, so let's remove the configuration machinery for it. Differential Revision: https://phabricator.services.mozilla.com/D83423
83c8b8ce71a887e8bf67fd1f9314675275fc3f24: Bug 1651799 - Don't set reference-types pref when compile-flag is not set. r=bbouvier
Ryan Hunt <rhunt@eqrion.net> - Mon, 27 Jul 2020 21:12:25 +0000 - rev 542238
Push 37645 by ccoroiu@mozilla.com at Tue, 28 Jul 2020 09:47:25 +0000
Bug 1651799 - Don't set reference-types pref when compile-flag is not set. r=bbouvier The pref will have no effect if the compile-flag isn't set, but this can confuse some users who will see the pref in about:config. Differential Revision: https://phabricator.services.mozilla.com/D83422
67f9e60ed1db9f1eda4cbf5f2016686f57a3f087: Bug 1649718 - Do not panic when fuzzing results in nonsensical flags. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Mon, 27 Jul 2020 14:30:52 +0000 - rev 542183
Push 37644 by cbrindusan@mozilla.com at Mon, 27 Jul 2020 20:32:01 +0000
Bug 1649718 - Do not panic when fuzzing results in nonsensical flags. r=bbouvier Fuzzing can get us into a situation where we have only Ion (or Cranelift) but debugging is also enabled. Guards higher up in the stack would normally prevent us from getting as far as the wasm compiler, but the fuzzing intercession point introduced in the previous patch disables the sniffing that causes the presence of the debugger to disable Ion; thus we come in here with debug && ion. Since it's fine to turn this from a release assert into a run-time error, in the way where we error out below in the case when no compilers are defined, then let's do so, instead of making things even more complicated. Depends on D81840 Differential Revision: https://phabricator.services.mozilla.com/D84990
7c91f246f03fe5a6161278063be529d240be8788: Bug 1649718 - Introduce fuzzing intercession points in feature switches. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Mon, 27 Jul 2020 14:23:18 +0000 - rev 542182
Push 37644 by cbrindusan@mozilla.com at Mon, 27 Jul 2020 20:32:01 +0000
Bug 1649718 - Introduce fuzzing intercession points in feature switches. r=bbouvier The fuzzing intercession points allow us to switch off a feature if fuzzing is selected and only compilers that don't support the feature are enabled. To be conservative, I limit it to cases where only a single compiler is selected. This does introduce another point in the code where we have to maintain feature selection, but as the number of unsupported features goes down, this should remain maintainable, I think. Differential Revision: https://phabricator.services.mozilla.com/D81840
f6988ba45a538070ee082ee8e0b0c35f116ccf8c: Bug 1649718 - Factor the reading of the switches. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Mon, 27 Jul 2020 14:23:08 +0000 - rev 542181
Push 37644 by cbrindusan@mozilla.com at Mon, 27 Jul 2020 20:32:01 +0000
Bug 1649718 - Factor the reading of the switches. r=bbouvier Instead of going directly to the options object, abstract the reading so that we can introduce an intercession point more easily. Differential Revision: https://phabricator.services.mozilla.com/D81839
2d7379d72655e6cb6a9c3a4e174160e4ea05245c: Bug 1649718 - Rename multi-value flag. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Mon, 27 Jul 2020 14:22:56 +0000 - rev 542180
Push 37644 by cbrindusan@mozilla.com at Mon, 27 Jul 2020 20:32:01 +0000
Bug 1649718 - Rename multi-value flag. r=bbouvier In keeping with the reftypes flag, platform-dependent flag names should carry the names of the platforms on which they depend. And there's no reason to have an open-ended ifdef here. Differential Revision: https://phabricator.services.mozilla.com/D81837
4848ee762ec8fa5fe448f8e6d5ffeec1f814bcbd: Bug 1649718 - Introduce fuzzing intercession points in feature switches. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Mon, 27 Jul 2020 11:32:20 +0000 - rev 542166
Push 37644 by cbrindusan@mozilla.com at Mon, 27 Jul 2020 20:32:01 +0000
Bug 1649718 - Introduce fuzzing intercession points in feature switches. r=bbouvier The fuzzing intercession points allow us to switch off a feature if fuzzing is selected and only compilers that don't support the feature are enabled. To be conservative, I limit it to cases where only a single compiler is selected. This does introduce another point in the code where we have to maintain feature selection, but as the number of unsupported features goes down, this should remain maintainable, I think. Differential Revision: https://phabricator.services.mozilla.com/D81840
00b2ac4f48b77b25f0a964b0cace53a4ea3f6299: Bug 1649718 - Factor the reading of the switches. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Mon, 27 Jul 2020 11:32:13 +0000 - rev 542165
Push 37644 by cbrindusan@mozilla.com at Mon, 27 Jul 2020 20:32:01 +0000
Bug 1649718 - Factor the reading of the switches. r=bbouvier Instead of going directly to the options object, abstract the reading so that we can introduce an intercession point more easily. Differential Revision: https://phabricator.services.mozilla.com/D81839
1f33b13d7bee415659fca21656c29d167a2e6b93: Bug 1649718 - Rename multi-value flag. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Mon, 27 Jul 2020 11:32:02 +0000 - rev 542164
Push 37644 by cbrindusan@mozilla.com at Mon, 27 Jul 2020 20:32:01 +0000
Bug 1649718 - Rename multi-value flag. r=bbouvier In keeping with the reftypes flag, platform-dependent flag names should carry the names of the platforms on which they depend. And there's no reason to have an open-ended ifdef here. Differential Revision: https://phabricator.services.mozilla.com/D81837
d5657e2d4be921b970e499407d881ef37cb77472: Bug 1653502: Update vendored Cranelift to fix fuzzbug. r=bbouvier
Chris Fallin <cfallin@mozilla.com> - Mon, 20 Jul 2020 10:04:31 +0000 - rev 541276
Push 37619 by apavel@mozilla.com at Mon, 20 Jul 2020 21:42:26 +0000
Bug 1653502: Update vendored Cranelift to fix fuzzbug. r=bbouvier This patch pulls in revision 1b3b2dbfd00492161032760992a8699d19b640ca of Cranelift. This includes PR bytecodealliance/wasmtime#2042, which fixes bug 1653502 by properly masking the shift amount in a shift incorporated into an aarch64 arithmetic instruction. This patch also includes various other miscellaneous Cranelift improvements that have been merged since the last version-bump, including some aarch64 codegen improvements. Differential Revision: https://phabricator.services.mozilla.com/D84101
4e1b5cf39203a94c081932140c6e95cd8a89bf45: Bug 1633721, part 2 of 2: Reftypes support on aarch64 using Cranelift. r=bbouvier
Chris Fallin <cfallin@mozilla.com> - Thu, 16 Jul 2020 19:15:08 +0000 - rev 540776
Push 37609 by rmaries@mozilla.com at Fri, 17 Jul 2020 03:27:56 +0000
Bug 1633721, part 2 of 2: Reftypes support on aarch64 using Cranelift. r=bbouvier This patch adds support for Wasm reference types when using the Cranelift/aarch64 Wasm backend in SpiderMonkey. The changes on the SpiderMonkey side principally involve (i) updating the compiler-selection logic to allow Cranelift when reftypes are enabled, and (ii) conveying the stackmaps from Cranelift to SpiderMonkey. This also fixes an assert failure hit in the VIXL-based MacroAssembler in a debug build. The assert was checking that the source of a move-to-FP-reg was not the zero register (xzr); a move like `mov v0.d[0], xzr` is perfectly valid, and should be allowed. Unsure why this assert had not been hit before, but it seems unrelated to reftype support. Differential Revision: https://phabricator.services.mozilla.com/D83583
ef358dbeceef9853351685d28f50f3427dd26715: Bug 1633721, part 1 of 2: Bump Cranelift to revision 5e0268a542f612fee36d0256ed1f6a0e18dc02b3. r=bbouvier
Chris Fallin <cfallin@mozilla.com> - Thu, 16 Jul 2020 19:15:05 +0000 - rev 540775
Push 37609 by rmaries@mozilla.com at Fri, 17 Jul 2020 03:27:56 +0000
Bug 1633721, part 1 of 2: Bump Cranelift to revision 5e0268a542f612fee36d0256ed1f6a0e18dc02b3. r=bbouvier This patch updates the vendored version of Cranelift, pulling in the reference-types support recently merged in Cranelift's PR bytecodealliance/wasmtime#1852. Usage of this update to support reftypes in SpiderMonkey on aarch64 is added in the subsequent commit. Differential Revision: https://phabricator.services.mozilla.com/D83582
da778e8edbdc36c25da730f1b1ee089cc3e45954: Bug 1648885 and Bug 1649432: vendor latest Cranelift to get Spectre mitigations and fix fuzzbug. r=bbouvier
Chris Fallin <cfallin@mozilla.com> - Thu, 02 Jul 2020 15:47:56 +0000 - rev 538454
Push 37563 by cbrindusan@mozilla.com at Thu, 02 Jul 2020 21:49:48 +0000
Bug 1648885 and Bug 1649432: vendor latest Cranelift to get Spectre mitigations and fix fuzzbug. r=bbouvier This patch pulls in Cranelift revision 47a218f908e6bdeb7a0fb65ed74e58a0b608080d, which incorporates several relevant changes: - It includes the Spectre mitigation for explicit heap bounds checks merged in PR bytecodealliance/wasmtime#1930, resolving Bug 1648885. - It includes the fix for an out-of-bounds subtraction on large shift amounts merged in PR bytecodealliance/wasmtime#1954, resolving Bug 1649432. We need to temporarily disable the `wasm/limits.js` jit-test on Cranelift configurations because it now needs shared memory to work, and the Cranelift backend does not support this yet. Given that this should be ready in the next month at most (requires atomics support on AArch64, which is currently being examined), it seems simpler to temporarily disable the test on aarch64 than to try to disentangle the bits that depend on shared memories explicitly. This patch also edits the `regexp/bug1445907.js` jit-test to run only if Wasm debugging is supported. This is needed for the test not to fail with `--wasm-compiler=cranelift` (which disables Baseline, the only Wasm compiler that supports debugging). Differential Revision: https://phabricator.services.mozilla.com/D81936
8e577c5158b874486e5c5a52c607f592ae8af7f4: Bug 1646663 - Conditionally align loop head. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Thu, 02 Jul 2020 07:38:58 +0000 - rev 538380
Push 37562 by nerli@mozilla.com at Thu, 02 Jul 2020 15:21:09 +0000
Bug 1646663 - Conditionally align loop head. r=bbouvier For wasm compilations, align the loop head properly. Tight loops will benefit from this, sometimes substantially. Differential Revision: https://phabricator.services.mozilla.com/D80851
826ca60bab00200040493caf08ff9f742e1704c3: Bug 1648697 - Disable --enable-avx. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Fri, 26 Jun 2020 08:54:48 +0000 - rev 537569
Push 37545 by nerli@mozilla.com at Sat, 27 Jun 2020 09:38:32 +0000
Bug 1648697 - Disable --enable-avx. r=bbouvier I disable this with an error message and a comment, but do not remove it, because it is currently buggy and unsupported but may well make a comeback when we have time to clean it up and we see whether wasm SIMD on the web starts demanding it. It is of course possible that we will never do this in Ion but will wait for Cranelift, but we don't have to make that decision today. Differential Revision: https://phabricator.services.mozilla.com/D81293
49d2c9efa9dee4aac2eedbb5bd472b41e42e6afb: Bug 1644550 - Clean up rematerialization of constants during multi-return shuffle. r=bbouvier,wingo
Lars T Hansen <lhansen@mozilla.com> - Wed, 17 Jun 2020 13:24:18 +0000 - rev 536231
Push 37517 by malexandru@mozilla.com at Thu, 18 Jun 2020 04:43:29 +0000
Bug 1644550 - Clean up rematerialization of constants during multi-return shuffle. r=bbouvier,wingo Differential Revision: https://phabricator.services.mozilla.com/D79102
f7ec4a92054042fc68ec3fccde54925cac626180: Bug 1645610 - Use the export's funcIndex to get the func export. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Wed, 17 Jun 2020 11:41:13 +0000 - rev 536079
Push 37516 by cbrindusan@mozilla.com at Wed, 17 Jun 2020 21:52:06 +0000
Bug 1645610 - Use the export's funcIndex to get the func export. r=bbouvier This fixes some debugging code that assumed a function could be exported only once. This code has been unchanged at least since the Big Source Reformatting and is not a recent regression. This particular bug is clearly specific to fuzzing-safe. Differential Revision: https://phabricator.services.mozilla.com/D79652
48eb6e27ac50b0c3fe07bc4dd8f6261c46d13ee4: Bug 1643653 - document the logic of wasm compiler and feature availability. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Tue, 16 Jun 2020 03:33:36 +0000 - rev 535790
Push 37510 by abutkovits@mozilla.com at Tue, 16 Jun 2020 09:29:00 +0000
Bug 1643653 - document the logic of wasm compiler and feature availability. r=bbouvier High-level documentation for how compiler and feature selection are used to compute compiler and feature availability. Differential Revision: https://phabricator.services.mozilla.com/D78485
af354efba63aa90f773464f8956f8a90aee29a83: Bug 1644554 - Block V128 in the Jit ABI r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Fri, 12 Jun 2020 08:58:57 +0000 - rev 535432
Push 37501 by nbeleuzu@mozilla.com at Sat, 13 Jun 2020 03:21:52 +0000
Bug 1644554 - Block V128 in the Jit ABI r=bbouvier See bug for further description. Differential Revision: https://phabricator.services.mozilla.com/D79415
23fd1073665e01e8c51dd474f2734fb0cb926c65: Bug 1641504: Adapt to Cranelift API changes. r=bbouvier
Chris Fallin <cfallin@mozilla.com> - Thu, 11 Jun 2020 23:34:48 +0000 - rev 535200
Push 37498 by apavel@mozilla.com at Fri, 12 Jun 2020 03:05:25 +0000
Bug 1641504: Adapt to Cranelift API changes. r=bbouvier This is an updated version of Ben Bouvier's patch D77227. Co-authored-by: Benjamin Bouvier <benj@benj.me> Differential Revision: https://phabricator.services.mozilla.com/D78588
7b4f55719649f932ae6b2a9490c99d76e8b75283: Bug 1641504: Bump Cranelift to 4d5fdfcbba1a8f38002a4223d7a329fc795d0e9f. r=bbouvier
Chris Fallin <cfallin@mozilla.com> - Thu, 11 Jun 2020 23:34:39 +0000 - rev 535199
Push 37498 by apavel@mozilla.com at Fri, 12 Jun 2020 03:05:25 +0000
Bug 1641504: Bump Cranelift to 4d5fdfcbba1a8f38002a4223d7a329fc795d0e9f. r=bbouvier Differential Revision: https://phabricator.services.mozilla.com/D78587
bf1919e75e6586dc79e2557b8924606212f539e2: Bug 1641504: Adapt to Cranelift API changes. r=bbouvier
Chris Fallin <cfallin@mozilla.com> - Tue, 09 Jun 2020 22:37:16 +0000 - rev 535160
Push 37498 by apavel@mozilla.com at Fri, 12 Jun 2020 03:05:25 +0000
Bug 1641504: Adapt to Cranelift API changes. r=bbouvier This is an updated version of Ben Bouvier's patch D77227. Co-authored-by: Benjamin Bouvier <benj@benj.me> Differential Revision: https://phabricator.services.mozilla.com/D78588
dedeac296eaa2cf8e90675d0b371a42d5a55d4e5: Bug 1641504: Bump Cranelift to e3d89c8a92a5fadedd75359b8485d23ac45ecf29. r=bbouvier
Chris Fallin <cfallin@mozilla.com> - Tue, 09 Jun 2020 22:37:06 +0000 - rev 535159
Push 37498 by apavel@mozilla.com at Fri, 12 Jun 2020 03:05:25 +0000
Bug 1641504: Bump Cranelift to e3d89c8a92a5fadedd75359b8485d23ac45ecf29. r=bbouvier Differential Revision: https://phabricator.services.mozilla.com/D78587
57fdda3872e8f7c6e8054718b716bd1f4186771b: Bug 1599634 - Remove dummyFunction from asm.js. r=bbouvier,djvj
Ted Campbell <tcampbell@mozilla.com> - Wed, 10 Jun 2020 16:30:20 +0000 - rev 535094
Push 37498 by apavel@mozilla.com at Fri, 12 Jun 2020 03:05:25 +0000
Bug 1599634 - Remove dummyFunction from asm.js. r=bbouvier,djvj These days, FunctionBox can be created without a JSFunction which is also suitable for the asm.js dummyFunction case. Remove the function and pass name and flags directly to the FunctionBox. We set flags to INTERPRETED_NORMAL since that is only type of function allowed at this point in the asm.js context. Differential Revision: https://phabricator.services.mozilla.com/D78802
a7cf4676f6d164ea37c94d711248cbe2a6609199: Bug 1644507 - Remove an inappropriate MOZ_ASSERT. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Wed, 10 Jun 2020 07:57:14 +0000 - rev 534825
Push 37495 by btara@mozilla.com at Wed, 10 Jun 2020 21:40:41 +0000
Bug 1644507 - Remove an inappropriate MOZ_ASSERT. r=bbouvier When the SIMD code landed, all aligned loads/stores (except constant loads) were changed to be unaligned, so as to not have to worry about aligning SIMD parameters and locals. But I forgot to remove this assert. Differential Revision: https://phabricator.services.mozilla.com/D79036
19e5e3e94bf47b6159fb151a1cac28f3b8d96dce: Bug 1643681 - Fold scalar.const+NxM.splat as v128.const. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Tue, 09 Jun 2020 06:48:47 +0000 - rev 534587
Push 37492 by apavel@mozilla.com at Tue, 09 Jun 2020 15:16:49 +0000
Bug 1643681 - Fold scalar.const+NxM.splat as v128.const. r=bbouvier Emscripten will generate eg f32.const + f32x4.splat instead of f32x4.const when the same value is used for all lanes, presumably because this is more compact bytecode. Fold the MIR node to recover the constant, for all types. Differential Revision: https://phabricator.services.mozilla.com/D78646
a5ba8c617b118404852cc3ed478c6e2fd07bbec3: Bug 1643681 - Fold scalar.const+NxM.splat as v128.const. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Mon, 08 Jun 2020 16:53:16 +0000 - rev 534580
Push 37492 by apavel@mozilla.com at Tue, 09 Jun 2020 15:16:49 +0000
Bug 1643681 - Fold scalar.const+NxM.splat as v128.const. r=bbouvier Emscripten will generate eg f32.const + f32x4.splat instead of f32x4.const when the same value is used for all lanes, presumably because this is more compact bytecode. Fold the MIR node to recover the constant, for all types. Differential Revision: https://phabricator.services.mozilla.com/D78646
834b400f034f43a6cf6fd9daed0025704551fb3c: Bug 1599634 - Move the JS::WasmModule definition to own header r=bbouvier
Ted Campbell <tcampbell@mozilla.com> - Thu, 04 Jun 2020 15:36:11 +0000 - rev 534235
Push 37484 by dluca@mozilla.com at Sat, 06 Jun 2020 09:46:03 +0000
Bug 1599634 - Move the JS::WasmModule definition to own header r=bbouvier Also add `JS::WasmModule::createObjectForAsmJS` which is similar to `createObject` but does not set the WasmModule prototype. Also mark these methods as const so they work with the `SharedModule` definition. Differential Revision: https://phabricator.services.mozilla.com/D78088
0e9a6b2370510ed4597c3693bc84816ed5cdceba: Bug 1642503 - Fix the name and type gdb uses to catch wasm's SIGSEGV handler r=bbouvier
Steve Fink <sfink@mozilla.com> - Tue, 02 Jun 2020 08:01:34 +0000 - rev 534031
Push 37481 by ncsoregi@mozilla.com at Fri, 05 Jun 2020 04:39:26 +0000
Bug 1642503 - Fix the name and type gdb uses to catch wasm's SIGSEGV handler r=bbouvier Differential Revision: https://phabricator.services.mozilla.com/D77718
cfe5dc930b4c234f60d064abac3cb052c98ab65e: Bug 1641973 - Make sure to check inDeadCode. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Tue, 02 Jun 2020 09:58:25 +0000 - rev 533484
Push 37473 by cbrindusan@mozilla.com at Wed, 03 Jun 2020 04:20:58 +0000
Bug 1641973 - Make sure to check inDeadCode. r=bbouvier Several of the SIMD instruction emitters in WasmIonCompile did not check the dead-code flag, and some might therefore access null pointers resulting from popping the value stack in dead code regions. Differential Revision: https://phabricator.services.mozilla.com/D77766
e3cb77c5f17e09a5c91711bd485505343eee55df: Bug 1641684: Add documentation about cross-compiling SpiderMonkey. r=bbouvier
Chris Fallin <cfallin@mozilla.com> - Fri, 29 May 2020 16:30:38 +0000 - rev 533024
Push 37461 by ccoroiu@mozilla.com at Fri, 29 May 2020 21:46:31 +0000
Bug 1641684: Add documentation about cross-compiling SpiderMonkey. r=bbouvier This patch updates `js/src/doc/build.rst` to include up-to-date instructions for cross-compiling a SpiderMonkey binary; for example, how to build a Linux/aarch64 binary on a Linux/x86-64 host. It also adds information about how to use `qemu` to run JIT-tests on this cross-compiled binary without requiring native hardware at all. It has been tested on the above platform pair (x86 to aarch64). Differential Revision: https://phabricator.services.mozilla.com/D77360
8c5496bf0b81291f5c850aae52c951c6fcaca571: Bug 1639845 - Fix SIMD link errors for beta sim. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Mon, 25 May 2020 09:37:06 +0000 - rev 531857
Push 37447 by nbeleuzu@mozilla.com at Mon, 25 May 2020 15:42:48 +0000
Bug 1639845 - Fix SIMD link errors for beta sim. r=bbouvier An annoying fact is that MIR and LIR nodes cannot be conditional on ifdefs, because the preprocessors that generate code from the node definitions are not ifdef-aware. In the case of SIMD, which has new MIR and LIR nodes, there are stub definitions in Lowering-shared.cpp for the ifndef ENABLE_WASM_SIMD case to implement stub lowering methods on non-SIMD platforms, including x64 when SIMD is disabled. (The stubs all MOZ_CRASH.) But we additionally need to have stub definitions for the x64 code generation methods for builds on x64 when SIMD is disabled. Here I've implemented those by moving the ifdefs inside the function bodies, which seemed like the simplest fix for now. Only x64 is affected as the new LIR nodes are x64-specific. Differential Revision: https://phabricator.services.mozilla.com/D76381
38d4e11b069b609199ed6017ce80e199d2c5773b: Bug 1631228 - wasm ion simd, part 3: ion code generation. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Wed, 20 May 2020 07:03:54 +0000 - rev 530963
Push 37435 by apavel@mozilla.com at Wed, 20 May 2020 15:28:23 +0000
Bug 1631228 - wasm ion simd, part 3: ion code generation. r=bbouvier Add SIMD opcodes to WasmIonCompile and implement code generation for them on x64. In truth, the code generation would look almost the same for x86, so this code could go into x86-shared if we were to implement just a few Int64 porting interfaces for x86. That's follow-up work though. Differential Revision: https://phabricator.services.mozilla.com/D71820
9aacd7b8b25246a69c2adbe855b630fe3d21bdbd: Bug 1631228 - wasm ion simd, part 2: MacroAssembler and other infrastructure. r=bbouvier
Lars T Hansen <lhansen@mozilla.com> - Wed, 20 May 2020 07:02:49 +0000 - rev 530962
Push 37435 by apavel@mozilla.com at Wed, 20 May 2020 15:28:23 +0000
Bug 1631228 - wasm ion simd, part 2: MacroAssembler and other infrastructure. r=bbouvier Housekeeping: Fix a few things at the lowering/codegen/masm level that are not directly related to adding SIMD ops to WasmIonCompile. Note the division between this and the WasmIonCompile patch is a little arbitrary. Differential Revision: https://phabricator.services.mozilla.com/D73422