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

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

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

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

Bug 1666568 - Initialize null jump table entries only once. r=bbouvier Differential Revision: https://phabricator.services.mozilla.com/D91568

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

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

Bug 1661231 - Add link to ARM64 ICache invalidation discussion. r=bbouvier DONTBUILD Differential Revision: https://phabricator.services.mozilla.com/D88256

Bug 1660976 - Output of mach vendor rust; r=bbouvier. Depends on D88132 Differential Revision: https://phabricator.services.mozilla.com/D88133

Bug 1660976 - Bump Cranelift to 7c856542854bc8c5da9d5fb1a0b41f3c660d8484; r=bbouvier. Differential Revision: https://phabricator.services.mozilla.com/D88132

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bug 1644550 - Clean up rematerialization of constants during multi-return shuffle. r=bbouvier,wingo Differential Revision: https://phabricator.services.mozilla.com/D79102

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

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

Bug 1644554 - Block V128 in the Jit ABI r=bbouvier See bug for further description. Differential Revision: https://phabricator.services.mozilla.com/D79415

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

Bug 1641504: Bump Cranelift to 4d5fdfcbba1a8f38002a4223d7a329fc795d0e9f. r=bbouvier Differential Revision: https://phabricator.services.mozilla.com/D78587

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

Bug 1641504: Bump Cranelift to e3d89c8a92a5fadedd75359b8485d23ac45ecf29. r=bbouvier Differential Revision: https://phabricator.services.mozilla.com/D78587

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

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

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

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

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

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

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

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

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

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

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