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