searching for reviewer(jseward)
ac952f932397268505cdc2b6223d0159de804c03: Bug 1670348 - Remove call to addTelemetry for JS_TELEMETRY_RUN_TIME_US r=jseward
Denis Palmeiro <dpalmeiro@mozilla.com> - Wed, 14 Oct 2020 13:37:05 +0000 - rev 552982
Push 128636 by dpalmeiro@mozilla.com at Wed, 14 Oct 2020 14:16:06 +0000
Bug 1670348 - Remove call to addTelemetry for JS_TELEMETRY_RUN_TIME_US r=jseward Unknown crash due to a corrupt scalar type. It may be caused by this probe, so removing it to see if the crash resolves. Differential Revision: https://phabricator.services.mozilla.com/D93155
b8c9121fdb10e9284193314ccce8282fad4d27f3: Bug 1669938 - Promote widening dot product wasm SIMD instruction to accepted status. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 14 Oct 2020 09:52:46 +0000 - rev 552963
Push 128618 by lhansen@mozilla.com at Wed, 14 Oct 2020 10:16:24 +0000
Bug 1669938 - Promote widening dot product wasm SIMD instruction to accepted status. r=jseward Background: https://github.com/WebAssembly/simd/pull/127 For the widening dot product instruction: - remove the internal 'Experimental' opcode suffix in the C++ code - remove the guard on the instruction in all the C++ decoders - move the test cases from simd/experimental.js to simd/ad-hack.js I have checked that current V8 and wasm-tools use the same opcode mapping. V8 in turn guarantees the correct mapping for LLVM and binaryen. Differential Revision: https://phabricator.services.mozilla.com/D92929
39bdfa950bc1ff247092e4ddb290d69ef23701ba: Bug 1669938 - Promote pseudo-min/max wasm SIMD instructions to accepted status. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 14 Oct 2020 09:52:05 +0000 - rev 552962
Push 128618 by lhansen@mozilla.com at Wed, 14 Oct 2020 10:16:24 +0000
Bug 1669938 - Promote pseudo-min/max wasm SIMD instructions to accepted status. r=jseward Background: https://github.com/WebAssembly/simd/pull/122 For all the pseudo-min/max SIMD instructions: - remove the internal 'Experimental' opcode suffix in the C++ code - remove the guard on experimental Wasm instructions in all the C++ decoders - move the test cases from simd/experimental.js to simd/ad-hack.js I have checked that current V8 and wasm-tools use the same opcode mappings. V8 in turn guarantees the correct mapping for LLVM and binaryen. Differential Revision: https://phabricator.services.mozilla.com/D92928
8ce9fbf57c652dce3997aa776ba47be677f0a4b4: Bug 1669964 - Fix code generation for pmin/pmax on x86. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 14 Oct 2020 09:51:36 +0000 - rev 552961
Push 128618 by lhansen@mozilla.com at Wed, 14 Oct 2020 10:16:24 +0000
Bug 1669964 - Fix code generation for pmin/pmax on x86. r=jseward pmin and pmax handled NaN incorrectly because the wonky semantics of MINPS and MAXPS require arguments to be reversed to properly handle NaN for these wasm SIMD instructions. We fix this the expedient way: we keep the same masm abstraction and introduce moves to rearrange the arguments. This should be optimized eventually and a bug will be filed for that now. Differential Revision: https://phabricator.services.mozilla.com/D92927
d25f2b090cf4bda0d8495bf9738fd846a5939eef: Bug 1669938 - Promote fp rounding wasm SIMD instructions to accepted status. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 14 Oct 2020 09:50:46 +0000 - rev 552960
Push 128618 by lhansen@mozilla.com at Wed, 14 Oct 2020 10:16:24 +0000
Bug 1669938 - Promote fp rounding wasm SIMD instructions to accepted status. r=jseward Background: https://github.com/WebAssembly/simd/pull/232 For all the rounding SIMD instructions: - remove the internal 'Experimental' opcode suffix in the C++ code - remove the guard on experimental Wasm instructions in all the C++ decoders - move the test cases from simd/experimental.js to simd/ad-hack.js I have checked that current V8 and wasm-tools use the same opcode mappings. V8 in turn guarantees the correct mapping for LLVM and binaryen. Drive-by bug fix: the test predicate for f64 square root was wrong, it would round its argument to float. This did not matter for the test inputs we had but started to matter when I added more difficult inputs for testing rounding. Differential Revision: https://phabricator.services.mozilla.com/D92926
7659e8a955103dc537535288c8278fb80c6140af: Bug 1669938 - Pull in latest wast version. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 14 Oct 2020 09:49:56 +0000 - rev 552959
Push 128618 by lhansen@mozilla.com at Wed, 14 Oct 2020 10:16:24 +0000
Bug 1669938 - Pull in latest wast version. r=jseward Differential Revision: https://phabricator.services.mozilla.com/D93475
f0c02e826fc85992113e6c455c44c6aa365b71e8: Bug 1669668 - Rename instructions in test cases to track spec. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Thu, 08 Oct 2020 09:18:35 +0000 - rev 552067
Push 128202 by lhansen@mozilla.com at Thu, 08 Oct 2020 09:42:43 +0000
Bug 1669668 - Rename instructions in test cases to track spec. r=jseward This depends on a new wast crate landing concurrently. See https://github.com/WebAssembly/simd/issues/{297,316,332} for details of the new names. The renaming is completely mechanical except for two aspects: - Previously the tests used the token i8x16.shuffle to trigger a syntax error, but that is now the correct token. The test has been updated to use v8x16.shuffle. - The wast crate has implemented a syntax restriction: a constant lane index cannot be prefixed with '+'. A few tests in spec/simd_lane.js were removed. Any internal renaming will happen later. We need to do a bigger job there anyway. Differential Revision: https://phabricator.services.mozilla.com/D92749
dc2e751e246b63f57cf41e7f3abc9041a4fb355c: Bug 1655042: Support Cranelift-based Wasm validation. r=jseward
Chris Fallin <cfallin@mozilla.com> - Wed, 07 Oct 2020 17:46:18 +0000 - rev 551957
Push 128141 by cfallin@mozilla.com at Wed, 07 Oct 2020 18:26:53 +0000
Bug 1655042: Support Cranelift-based Wasm validation. r=jseward This patch is an update of Benjamin Bouvier's WIP patch that supports Cranelift's new Wasm validator functionality, as introduced in bytecodealliance/wasmtime#2059. Previously, Baldrdash allowed SpiderMonkey to validate Wasm function bodies before invoking Cranelift. The Cranelift PR now causes validation to happen in the function-body compiler. Because the Cranelift backend now takes on this responsibility, we no longer need to invoke the SpiderMonkey function-body validator. This requires some significant new glue in the Baldrdash bindings to allow Cranelift's Wasm frontend to access module type information. Co-authored-by: Benjamin Bouvier <benj@benj.me> Differential Revision: https://phabricator.services.mozilla.com/D92504
ad2fc501557ecb736c943606920f90dbe98112a1: Bug 1669055: Vendor Cranelift e22e2c3722f2fbccd3c8d3230119fa04c332c69c. r=jseward
Chris Fallin <cfallin@mozilla.com> - Wed, 07 Oct 2020 06:25:50 +0000 - rev 551956
Push 128141 by cfallin@mozilla.com at Wed, 07 Oct 2020 18:26:53 +0000
Bug 1669055: Vendor Cranelift e22e2c3722f2fbccd3c8d3230119fa04c332c69c. r=jseward This patch pulls in an updated Cranelift with a new validation strategy, introduced by bytecodealliance/wasmtime#2059. This new design validates the Wasm module as it parses the function bodies. A subsequent patch will adapt Baldrdash to work with this. Differential Revision: https://phabricator.services.mozilla.com/D92503
0807415f1ea5bf7d74ff3390b6eca7c7532cfb63: Bug 1655042: Support Cranelift-based Wasm validation. r=jseward
Chris Fallin <cfallin@mozilla.com> - Wed, 07 Oct 2020 03:44:45 +0000 - rev 551815
Push 128079 by cfallin@mozilla.com at Wed, 07 Oct 2020 05:42:58 +0000
Bug 1655042: Support Cranelift-based Wasm validation. r=jseward This patch is an update of Benjamin Bouvier's WIP patch that supports Cranelift's new Wasm validator functionality, as introduced in bytecodealliance/wasmtime#2059. Previously, Baldrdash allowed SpiderMonkey to validate Wasm function bodies before invoking Cranelift. The Cranelift PR now causes validation to happen in the function-body compiler. Because the Cranelift backend now takes on this responsibility, we no longer need to invoke the SpiderMonkey function-body validator. This requires some significant new glue in the Baldrdash bindings to allow Cranelift's Wasm frontend to access module type information. Co-authored-by: Benjamin Bouvier <benj@benj.me> Differential Revision: https://phabricator.services.mozilla.com/D92504
bb5e11920e1a3f8b0f99337684ad188875e812ea: Bug 1669055: Vendor Cranelift e22e2c3722f2fbccd3c8d3230119fa04c332c69c. r=jseward
Chris Fallin <cfallin@mozilla.com> - Wed, 07 Oct 2020 03:44:43 +0000 - rev 551814
Push 128079 by cfallin@mozilla.com at Wed, 07 Oct 2020 05:42:58 +0000
Bug 1669055: Vendor Cranelift e22e2c3722f2fbccd3c8d3230119fa04c332c69c. r=jseward This patch pulls in an updated Cranelift with a new validation strategy, introduced by bytecodealliance/wasmtime#2059. This new design validates the Wasm module as it parses the function bodies. A subsequent patch will adapt Baldrdash to work with this. Differential Revision: https://phabricator.services.mozilla.com/D92503
34fddbf97cc7adc4fbc6feb379d027b0b94cbe44: Bug 1669055: Vendor Cranelift e22e2c3722f2fbccd3c8d3230119fa04c332c69c. r=jseward
Chris Fallin <cfallin@mozilla.com> - Tue, 06 Oct 2020 16:52:57 +0000 - rev 551753
Push 128044 by cfallin@mozilla.com at Tue, 06 Oct 2020 20:10:38 +0000
Bug 1669055: Vendor Cranelift e22e2c3722f2fbccd3c8d3230119fa04c332c69c. r=jseward This patch pulls in an updated Cranelift with a new validation strategy, introduced by bytecodealliance/wasmtime#2059. This new design validates the Wasm module as it parses the function bodies. A subsequent patch will adapt Baldrdash to work with this. Differential Revision: https://phabricator.services.mozilla.com/D92503
6f49e3c9805304a608399a7c3c7ab9985ea528f7: Bug 1669428 - Properly control experimental SIMD instructions. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Tue, 06 Oct 2020 12:10:56 +0000 - rev 551703
Push 128008 by lhansen@mozilla.com at Tue, 06 Oct 2020 12:13:32 +0000
Bug 1669428 - Properly control experimental SIMD instructions. r=jseward This gets rid of an ad-hoc boolean constant and introduces a configuration flag for experimental SIMD instructions. The flag is on by default in Nightly if SIMD is also enabled; otherwise off. This patch therefore disables support for experimental SIMD instructions in beta and release, where they have been available with the other SIMD instructions behind a pref. This seems OK: code using unstable bits of an in-progress proposal should stick to Nightly. Differential Revision: https://phabricator.services.mozilla.com/D92554
402686aadec108248fe5c83e5ed6496174889c03: Bug 1669196 - Guard a test on word width. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Tue, 06 Oct 2020 08:08:56 +0000 - rev 551676
Push 127989 by lhansen@mozilla.com at Tue, 06 Oct 2020 08:11:34 +0000
Bug 1669196 - Guard a test on word width. r=jseward A test introduced in bug 1669003 should only be run on 32-bit systems for now because (a) that's what it's intended for and (b) it will fail on aarch64 due to bug 1666747 (bad unaligned writes at the end of memory): On 32-bit ARM, the test case performs aligned writes and thus tests what it's supposed to test. On 64-bit ARM, the write will be unaligned and hence fail due to the latter bug. Differential Revision: https://phabricator.services.mozilla.com/D92544
04fdcc8532d8c0662eda45e646f7dd6311cd7f21: Bug 1669003 - Write high word before low when storing I64 on x86 and ARMv7. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Mon, 05 Oct 2020 09:55:50 +0000 - rev 551479
Push 127881 by lhansen@mozilla.com at Mon, 05 Oct 2020 09:58:51 +0000
Bug 1669003 - Write high word before low when storing I64 on x86 and ARMv7. r=jseward When storing an i64 on a 32-bit system, the high word must be stored before the low word so that the guard-page OOB check can trigger before any data are written. The problem affects x86 and ARMv7 (though not MIPS32). This patch fixes both platforms, but note ARMv7 needs additional work to deal with some unaligned stores, see bug 1666747. Differential Revision: https://phabricator.services.mozilla.com/D92370
f93a829f7f1271f2327bc6947fe8db934f3dd3cc: Bug 1609381 - arm64 baseline simd, part 3: masm support. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Fri, 02 Oct 2020 13:09:12 +0000 - rev 551295
Push 127776 by lhansen@mozilla.com at Fri, 02 Oct 2020 16:15:20 +0000
Bug 1609381 - arm64 baseline simd, part 3: masm support. r=jseward Add porting interfaces for arm64 and adapt the baseline compiler to use them. Differential Revision: https://phabricator.services.mozilla.com/D90743
c5c66994bd790503b396f1bde79efce88dcfca26: Bug 1609381 - arm64 baseline simd, part 2: sundry cleanup. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Fri, 02 Oct 2020 13:13:07 +0000 - rev 551294
Push 127776 by lhansen@mozilla.com at Fri, 02 Oct 2020 16:15:20 +0000
Bug 1609381 - arm64 baseline simd, part 2: sundry cleanup. r=jseward Various cleanup: - significantly simplify SIMD emitters in the baseline compiler: we don't need to have various emitters with names like ...WithTemp and ...WithTwoTemps, it is enough to use the base name of the operation and rely on overloading. This in turn leads to opportunities for templates, which are introduced systematically here, leading to the removal of many special-case emitters. - remove some dead SIMD code in the masm - rename a misnamed API (the SIMD averages are unsigned averages) - rename some mismatched parameter names Differential Revision: https://phabricator.services.mozilla.com/D90742
7f28798f0762577356c3fbb897ee3b8c6c326c62: Bug 1609381 - arm64 baseline simd, part 1: config, register sets, stubs. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Fri, 02 Oct 2020 13:12:42 +0000 - rev 551293
Push 127776 by lhansen@mozilla.com at Fri, 02 Oct 2020 16:15:20 +0000
Bug 1609381 - arm64 baseline simd, part 1: config, register sets, stubs. r=jseward This lays the groundwork for ARM64 simd in the baseline compiler and runtime. Mostly this is non-dramatic. The main problem to be solved is SIMD register allocation and save/restore in the stubs. We can't use the register sets in the usual way to do this for reasons that are explained at length in comments in Architecture-arm64.h, WasmStubs.cpp, and WasmBaselineCompile.cpp, so there are a couple of cheats, that basically come down to (sometimes contextually) treating doubles as vectors. By and large this is surprisingly clean. The patch also splits a huge test file (simd/spec/nan-flavors.js) into many smaller files so as to avoid OOM conditions when testing on device with --ion-eager and similar switch settings that cause massive amounts of jit code to be allocated. Differential Revision: https://phabricator.services.mozilla.com/D90740
42ffc70267ab7b83c35caca4d23688a7d82dce86: Bug 1663327 - Fix emulation of tbl instruction. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Mon, 21 Sep 2020 08:59:15 +0000 - rev 550303
Push 127230 by lhansen@mozilla.com at Fri, 25 Sep 2020 08:00:49 +0000
Bug 1663327 - Fix emulation of tbl instruction. r=jseward The emulation must use a temporary register to avoid clobbering the output register early. Differential Revision: https://phabricator.services.mozilla.com/D90739
d8502f45b50499a5f893720fc6ecef9c9dcdcc65: Bug 1664453: vendor Cranelift to 379aed8092cd1241ec7839e77d05557b1dceb234 to resolve two Wasm translation bugs. r=jseward
Chris Fallin <cfallin@mozilla.com> - Tue, 15 Sep 2020 20:01:26 +0000 - rev 548830
Push 126403 by cfallin@mozilla.com at Tue, 15 Sep 2020 20:43:30 +0000
Bug 1664453: vendor Cranelift to 379aed8092cd1241ec7839e77d05557b1dceb234 to resolve two Wasm translation bugs. r=jseward This Cranelift update to revision 379aed8092cd1241ec7839e77d05557b1dceb234 includes its PRs #2197 and #2194, which fix two Wasm translation bugs, as well a other miscellaneous updates and fixes. Fixes both Bug 1664453 and Bug 1663861. Differential Revision: https://phabricator.services.mozilla.com/D90306
da2ca8466508070950b870a6906a595e690abdd3: Bug 1656229 - move unused SIMD code. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Thu, 20 Aug 2020 14:43:13 +0000 - rev 545522
Push 124626 by lhansen@mozilla.com at Thu, 20 Aug 2020 14:55:24 +0000
Bug 1656229 - move unused SIMD code. r=jseward This separates unused SIMD code (from asm.js) from code that's being actively maintained by placing out-of-line definitions in a new file, and creating separate sections in the header for the declarations and in-line definitions. The code is included in the build so that it doesn't go completely stale, but this is not technically required. Differential Revision: https://phabricator.services.mozilla.com/D87307
3da7d219a9e4e4f6e23892e2ef27192de1954f9d: Bug 1656229 - replace a computation by a constant load. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Thu, 20 Aug 2020 14:43:04 +0000 - rev 545521
Push 124626 by lhansen@mozilla.com at Thu, 20 Aug 2020 14:55:24 +0000
Bug 1656229 - replace a computation by a constant load. r=jseward This is technical debt from the initial SIMD work - it's faster to load a constant here than to compute it. Benchmark data not forthcoming, but elsewhere i've found that we break even at two instructions and it's better to load the value than to compute it in three. Differential Revision: https://phabricator.services.mozilla.com/D87306
a475ddc1aeec7006fab0c9d28660e6c90a8c6d2e: Bug 1656229 - Use scratch scopes for v128. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Thu, 20 Aug 2020 14:42:49 +0000 - rev 545520
Push 124626 by lhansen@mozilla.com at Thu, 20 Aug 2020 14:55:24 +0000
Bug 1656229 - Use scratch scopes for v128. r=jseward Always use ScratchSimd128Scope to claim ScratchSimd128Reg. The only hard part is that the register was claimed deep in the assembler in what appears to be a late non-AVX bugfix to work around the fact that compare operations are not three-address on non-AVX. I fixed this by making compare operations two-address and moving the code that shuffles registers for this case into the macroassembler, where the scratch can be claimed correctly. As a result, we have less support for AVX, but since AVX is not supported or tested this does not actually matter. A MOZ_CRASH ensures we'll run into this if testing with AVX. Another couple of similar cases elsewhere have similar local fixes: MOZ_CRASH for AVX, two-address code for the normal case. Differential Revision: https://phabricator.services.mozilla.com/D87284
13ab0525763e6ef70ebe10423c286120faa9f9ff: Bug 1659803: Bump Cranelift to rev 924782191b1cdd85438b707d20a82fbcc8ad40e1. r=jseward
Chris Fallin <cfallin@mozilla.com> - Tue, 18 Aug 2020 19:07:53 +0000 - rev 545203
Push 124427 by cfallin@mozilla.com at Tue, 18 Aug 2020 19:14:12 +0000
Bug 1659803: Bump Cranelift to rev 924782191b1cdd85438b707d20a82fbcc8ad40e1. r=jseward This PR pulls in the latest version of Cranelift, which pulls in regalloc.rs v0.0.30 and consequently includes some improvements in memory allocation rate during compilation. No behavior changes expected. Differential Revision: https://phabricator.services.mozilla.com/D87479
7d08b53eb266494c4ce8f31f41ac5686626991d9: Bug 1659139: Update vendored Cranelift to 279534e27611ee4a13e4590a0a10ffc0fdb95a33. r=jseward
Chris Fallin <cfallin@mozilla.com> - Fri, 14 Aug 2020 18:36:25 +0000 - rev 544737
Push 124232 by cfallin@mozilla.com at Fri, 14 Aug 2020 20:44:28 +0000
Bug 1659139: Update vendored Cranelift to 279534e27611ee4a13e4590a0a10ffc0fdb95a33. r=jseward This pulls in an upgrade to regalloc.rs v0.0.29, which brings several performance improvements. Differential Revision: https://phabricator.services.mozilla.com/D87096
0edbc05d65ff215bb5732d14f43689cdf7794787: Bug 1647288 - Handle NaN in SIMD min, max: Code. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 12 Aug 2020 13:11:03 +0000 - rev 544416
Push 124017 by lhansen@mozilla.com at Wed, 12 Aug 2020 13:15:04 +0000
Bug 1647288 - Handle NaN in SIMD min, max: Code. r=jseward This adds correct NaN handling to the SIMD f32x4/f64x2.min/max code. This is a bit of a horror show actually. There is a reasonable fast path if neither operand contains a NaN, but the slow path to handle NaN is long and there's a lot of code. (This is an Intel-only problem, on other architectures there's a direct mapping.) It is possible the slow-path code could be somewhat improved (both speed and size) by using at least three BLEND instructions, but I consider that a possible optimization that needs investigation and empirical backing. Meanwhile, we can land this plausible code. Differential Revision: https://phabricator.services.mozilla.com/D86318
2fa2317aa4319d5810fca6a4780ac57d475552b8: Bug 1647288 - Handle signalling NaN generally: Test cases. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 12 Aug 2020 13:10:55 +0000 - rev 544415
Push 124017 by lhansen@mozilla.com at Wed, 12 Aug 2020 13:15:04 +0000
Bug 1647288 - Handle signalling NaN generally: Test cases. r=jseward Wasm treats signalling and quiet NaN the same - as quiet NaN. Where convenient, test also signalling NaN. This is complicated by JS not being able to represent signalling NaN directly. Differential Revision: https://phabricator.services.mozilla.com/D86317
f1cdbe186a1598e59f64a740b63f0dcf27e7a22f: Bug 1647288 - Handle NaN in SIMD min, max: Generated test cases. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 12 Aug 2020 13:10:53 +0000 - rev 544414
Push 124017 by lhansen@mozilla.com at Wed, 12 Aug 2020 13:15:04 +0000
Bug 1647288 - Handle NaN in SIMD min, max: Generated test cases. r=jseward These test cases were generated by a script from some of the preliminary test cases in the SIMD spec repository, taking into account the specific NaN types asked for. These tests are temporary: once we have proper generated test cases from the spec repository, these will no longer be needed. Differential Revision: https://phabricator.services.mozilla.com/D86316
5c9edf20c00433845e32eae8fd6251bbfaaac321: Bug 1657628 - Fix bugs in some ad-hack simd tests. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 12 Aug 2020 13:10:50 +0000 - rev 544413
Push 124017 by lhansen@mozilla.com at Wed, 12 Aug 2020 13:15:04 +0000
Bug 1657628 - Fix bugs in some ad-hack simd tests. r=jseward Two bugs: - an accidental redefinition of the 'eq' predicate resulted in the 'permute' function not working and thus in us not testing floating point operations for NaN, Infinity, and some other interesting values. - the previous bug masked the fact that the max and min operations for floating point were not implemented properly; they have to handle NaN specially. Differential Revision: https://phabricator.services.mozilla.com/D86315
2d73a015caaa3e70c175172158a6548625dc6da3: Bug 1656226 - Implement the experimental opcodes. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 12 Aug 2020 13:10:48 +0000 - rev 544412
Push 124017 by lhansen@mozilla.com at Wed, 12 Aug 2020 13:15:04 +0000
Bug 1656226 - Implement the experimental opcodes. r=jseward Implement some of the experimental SIMD opcodes that are supported by all of V8, LLVM, and Binaryen, for maximum compatibility with test content we might be exposed to. Most/all of these will probably make it into the spec, as they lead to substantial speedups in some programs, and they are deterministic. For spec and cpu mapping details, see: https://github.com/WebAssembly/simd/pull/122 (pmax/pmin) https://github.com/WebAssembly/simd/pull/232 (rounding) https://github.com/WebAssembly/simd/pull/127 (dot product) https://github.com/WebAssembly/simd/pull/237 (load zero) The wasm bytecode values used here come from the binaryen changes that are linked from those tickets, that's the best documentation right now. Current binaryen opcode mappings are here: https://github.com/WebAssembly/binaryen/blob/master/src/wasm-binary.h Also: Drive-by fix for signatures of vroundss and vroundsd, these are unary operations and should follow the conventions for these with src/dest arguments, not src0/src1/dest. Also: Drive-by fix to add variants of vmovss and vmovsd on x64 that take Operand source and FloatRegister destination. Differential Revision: https://phabricator.services.mozilla.com/D85982
0cabb34381855218b4032df87f53117df0aefecd: Bug 1656216 - Improve SIMD test cases. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 12 Aug 2020 13:09:20 +0000 - rev 544411
Push 124017 by lhansen@mozilla.com at Wed, 12 Aug 2020 13:15:04 +0000
Bug 1656216 - Improve SIMD test cases. r=jseward This fleshes out the test cases to cover some corner cases that were left uncovered before. No errors were found. Differential Revision: https://phabricator.services.mozilla.com/D85981
c19dcb11b94077f23bf41515a0c2584406823815: Bug 1647288 - Handle NaN in SIMD min, max: Code. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 12 Aug 2020 07:50:45 +0000 - rev 544379
Push 123998 by lhansen@mozilla.com at Wed, 12 Aug 2020 08:21:24 +0000
Bug 1647288 - Handle NaN in SIMD min, max: Code. r=jseward This adds correct NaN handling to the SIMD f32x4/f64x2.min/max code. This is a bit of a horror show actually. There is a reasonable fast path if neither operand contains a NaN, but the slow path to handle NaN is long and there's a lot of code. (This is an Intel-only problem, on other architectures there's a direct mapping.) It is possible the slow-path code could be somewhat improved (both speed and size) by using at least three BLEND instructions, but I consider that a possible optimization that needs investigation and empirical backing. Meanwhile, we can land this plausible code. Differential Revision: https://phabricator.services.mozilla.com/D86318
bfd5e17cb4d0919f4002a490347d70d7cf65f365: Bug 1647288 - Handle signalling NaN generally: Test cases. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 12 Aug 2020 07:50:23 +0000 - rev 544378
Push 123998 by lhansen@mozilla.com at Wed, 12 Aug 2020 08:21:24 +0000
Bug 1647288 - Handle signalling NaN generally: Test cases. r=jseward Wasm treats signalling and quiet NaN the same - as quiet NaN. Where convenient, test also signalling NaN. This is complicated by JS not being able to represent signalling NaN directly. Differential Revision: https://phabricator.services.mozilla.com/D86317
64e82366834a3c20d571e082be358c042f2c8b2e: Bug 1647288 - Handle NaN in SIMD min, max: Generated test cases. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 12 Aug 2020 07:50:15 +0000 - rev 544377
Push 123998 by lhansen@mozilla.com at Wed, 12 Aug 2020 08:21:24 +0000
Bug 1647288 - Handle NaN in SIMD min, max: Generated test cases. r=jseward These test cases were generated by a script from some of the preliminary test cases in the SIMD spec repository, taking into account the specific NaN types asked for. These tests are temporary: once we have proper generated test cases from the spec repository, these will no longer be needed. Differential Revision: https://phabricator.services.mozilla.com/D86316
a6d240ef908b37bf509c46676bd70831174d2102: Bug 1657628 - Fix bugs in some ad-hack simd tests. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 12 Aug 2020 07:50:07 +0000 - rev 544376
Push 123998 by lhansen@mozilla.com at Wed, 12 Aug 2020 08:21:24 +0000
Bug 1657628 - Fix bugs in some ad-hack simd tests. r=jseward Two bugs: - an accidental redefinition of the 'eq' predicate resulted in the 'permute' function not working and thus in us not testing floating point operations for NaN, Infinity, and some other interesting values. - the previous bug masked the fact that the max and min operations for floating point were not implemented properly; they have to handle NaN specially. Differential Revision: https://phabricator.services.mozilla.com/D86315
2e7ddb00c8f9240e148cf5843b50a7ba7b913351: Bug 1656226 - Implement the experimental opcodes. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 12 Aug 2020 07:50:00 +0000 - rev 544375
Push 123998 by lhansen@mozilla.com at Wed, 12 Aug 2020 08:21:24 +0000
Bug 1656226 - Implement the experimental opcodes. r=jseward Implement some of the experimental SIMD opcodes that are supported by all of V8, LLVM, and Binaryen, for maximum compatibility with test content we might be exposed to. Most/all of these will probably make it into the spec, as they lead to substantial speedups in some programs, and they are deterministic. For spec and cpu mapping details, see: https://github.com/WebAssembly/simd/pull/122 (pmax/pmin) https://github.com/WebAssembly/simd/pull/232 (rounding) https://github.com/WebAssembly/simd/pull/127 (dot product) https://github.com/WebAssembly/simd/pull/237 (load zero) The wasm bytecode values used here come from the binaryen changes that are linked from those tickets, that's the best documentation right now. Current binaryen opcode mappings are here: https://github.com/WebAssembly/binaryen/blob/master/src/wasm-binary.h Also: Drive-by fix for signatures of vroundss and vroundsd, these are unary operations and should follow the conventions for these with src/dest arguments, not src0/src1/dest. Also: Drive-by fix to add variants of vmovss and vmovsd on x64 that take Operand source and FloatRegister destination. Differential Revision: https://phabricator.services.mozilla.com/D85982
656340534354efba26af4ffde4e17a4a33eea2b8: Bug 1656216 - Improve SIMD test cases. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Wed, 12 Aug 2020 07:49:12 +0000 - rev 544374
Push 123998 by lhansen@mozilla.com at Wed, 12 Aug 2020 08:21:24 +0000
Bug 1656216 - Improve SIMD test cases. r=jseward This fleshes out the test cases to cover some corner cases that were left uncovered before. No errors were found. Differential Revision: https://phabricator.services.mozilla.com/D85981
5c9c06afd067734f815bbcb59a406f09f7743469: Bug 1657895: update Baldrdash (Cranelift bindings) for minor API changes. r=jseward
Chris Fallin <cfallin@mozilla.com> - Mon, 10 Aug 2020 20:19:48 +0000 - rev 544175
Push 123865 by cfallin@mozilla.com at Mon, 10 Aug 2020 20:35:44 +0000
Bug 1657895: update Baldrdash (Cranelift bindings) for minor API changes. r=jseward Recently Cranelift modified the spelling of `Stackmap` and `stackmap` to two-word forms; this adapts our embedding of Cranelift accordingly. Differential Revision: https://phabricator.services.mozilla.com/D86460
bcea744caa66bee1af52d6064525b82594f03c0d: Bug 1657895: fix fuzzbug by vendoring Cranelift to rev e88d74903102266a18e97489557760b9be67f782. r=jseward
Chris Fallin <cfallin@mozilla.com> - Mon, 10 Aug 2020 20:21:48 +0000 - rev 544174
Push 123865 by cfallin@mozilla.com at Mon, 10 Aug 2020 20:35:44 +0000
Bug 1657895: fix fuzzbug by vendoring Cranelift to rev e88d74903102266a18e97489557760b9be67f782. r=jseward This pulls in (in addition to other miscellaneous changes) a Cranelift PR which fixes a Wasm translation issue in which the value stack was not properly restored to have the if-block-parameters in the else-branch after the if-branch ended in an unreachable opcode: https://github.com/bytecodealliance/wasmtime/pull/2120 Differential Revision: https://phabricator.services.mozilla.com/D86459
a50bfcf246e3810c9a16c84a9171eecd3411dd92: Bug 1657888: Cranelift Wasm backend: zero-extend i32 args as well as returns. r=jseward
Chris Fallin <cfallin@mozilla.com> - Mon, 10 Aug 2020 20:31:36 +0000 - rev 544172
Push 123863 by cfallin@mozilla.com at Mon, 10 Aug 2020 20:34:05 +0000
Bug 1657888: Cranelift Wasm backend: zero-extend i32 args as well as returns. r=jseward The Baldrdash (SpiderMonkey-to-Cranelift) glue layer was properly setting the argument extension mode for 32-bit return values, so that the high bits were zeroed, but it was not correctly setting this for 32-bit arguments. This matters when generated Wasm code calls back into JS or native code; it must zero-extend the value before passing it to the callee. Differential Revision: https://phabricator.services.mozilla.com/D86446
d161f289f9f7a096930007006e736e7421036d73: Bug 1657522: try to work around a jit-test.py quoting bug. r=jseward
Chris Fallin <cfallin@mozilla.com> - Thu, 06 Aug 2020 09:57:58 +0000 - rev 543620
Push 123578 by cfallin@mozilla.com at Thu, 06 Aug 2020 15:45:29 +0000
Bug 1657522: try to work around a jit-test.py quoting bug. r=jseward It seems that a `jit-test` directive telling the testing infra to skip a JIT test is being mangled somehow: the double-quote character is being replaced with a backslash, causing syntax errors later when the directive is interpreted. I haven't worked out what is making this substitution or why, but a single-quote seems to make it through OK. Differential Revision: https://phabricator.services.mozilla.com/D86125
4494f9a71ce5a9516adec808a8cf7dcdd78d1c88: Bug 1649929: re-enable wasm/limits.js JIT-test now that Cranelift/aarch64 backend supports shared memory. r=jseward
Chris Fallin <cfallin@mozilla.com> - Wed, 05 Aug 2020 19:09:20 +0000 - rev 543474
Push 123475 by cfallin@mozilla.com at Wed, 05 Aug 2020 19:12:14 +0000
Bug 1649929: re-enable wasm/limits.js JIT-test now that Cranelift/aarch64 backend supports shared memory. r=jseward This patch re-enables the `wasm/limits.js` test on Cranelift/aarch64, which we had previously disabled on this configuration because it depended on shared memory. Now that this backend supports shared memory, there is no reason to exclude this test any more. Differential Revision: https://phabricator.services.mozilla.com/D86053
e8802c34116d4bdcb632554c20b6487ee3f7d3e2: Bug 1657062: vendor Cranelift to rev fc88898e9ad7766feadfa0954c4594fcccd86b92 to fix fuzzbug. r=jseward
Chris Fallin <cfallin@mozilla.com> - Wed, 05 Aug 2020 17:40:30 +0000 - rev 543469
Push 123470 by cfallin@mozilla.com at Wed, 05 Aug 2020 19:01:04 +0000
Bug 1657062: vendor Cranelift to rev fc88898e9ad7766feadfa0954c4594fcccd86b92 to fix fuzzbug. r=jseward This patch vendors in the latest version of Cranelift, including the following PR, which fixes this fuzzbug: https://github.com/bytecodealliance/wasmtime/pull/2097 Differential Revision: https://phabricator.services.mozilla.com/D86044
c89629b3fca1ce59d6f806bbec48b22b9295f7f7: Bug 1656335 - Improve wasm gating on ARM. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Tue, 04 Aug 2020 10:28:40 +0000 - rev 543199
Push 123296 by lhansen@mozilla.com at Tue, 04 Aug 2020 10:31:27 +0000
Bug 1656335 - Improve wasm gating on ARM. r=jseward Generalizes wasm::HasSupport() on 32-bit ARM so that we check whether the atomic operations are available in all cases, not just when running on the simulator. This was a dumb bug, but an old one. Effectively this means we get wasm only with ARMv7, which we've been assuming anyway. Now we gate it properly. Changes a whitebox test case that explicitly sets the ARM hw capabilities to set capabilities that will pass the new test even on non-simulator builds, and handles the run-time error that results when command line switches select a compiler that has stronger requirements than that general requirement, leaving an empty set of available compilers. (The baseline compiler requires IDIV support.) Renames the test case appropriately. Differential Revision: https://phabricator.services.mozilla.com/D85547
e0ac26d4e4a5634cc38ee21f489a61bef7d82570: Bug 1655848: vendor in new Cranelift to fix fuzzbug. r=jseward
Chris Fallin <cfallin@mozilla.com> - Mon, 03 Aug 2020 16:53:46 +0000 - rev 543145
Push 123255 by cfallin@mozilla.com at Mon, 03 Aug 2020 17:43:20 +0000
Bug 1655848: vendor in new Cranelift to fix fuzzbug. r=jseward This patch vendors in the latest version of Cranelift, rev 026fb8d388964c7c1bace7019c4fe0d63c584560. This includes a fix for bug 1655848 (from GitHub PR #2081), as well as several other miscellaneous changes. Differential Revision: https://phabricator.services.mozilla.com/D85773
684e8b6a41091c9b221bba91696182e558e56182: Bug 1640669 - Part 3: Hide platform-specific bits better. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Fri, 31 Jul 2020 15:07:39 +0000 - rev 542887
Push 123095 by lhansen@mozilla.com at Fri, 31 Jul 2020 15:12:33 +0000
Bug 1640669 - Part 3: Hide platform-specific bits better. r=jseward Factor a predicate that determines whether we should optimize a reduce+branch operation. Differential Revision: https://phabricator.services.mozilla.com/D85261
ce7b1451c1009774c89f46b808eec9e3590ac6d4: Bug 1640669 - Part 2: Optimize bitmask for control. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Fri, 31 Jul 2020 15:07:25 +0000 - rev 542886
Push 123095 by lhansen@mozilla.com at Fri, 31 Jul 2020 15:12:33 +0000
Bug 1640669 - Part 2: Optimize bitmask for control. r=jseward Code generation for i16x8.bitmask is particularly poor, so optimize for control. In the case of i8x16.bitmask and i32x4.bitmask, it's a single SIMD instruction followed by a test, and it's unlikely that something depending on a constant load will do better, so don't optimize these. A subsequent patch will move the code from Lowering.cpp into platform code, now that it is clearly platform-dependent. Differential Revision: https://phabricator.services.mozilla.com/D85260
9d343deee76d59ab5ddb3c367db7876fbf22b45b: Bug 1640669 - Part 1: Optimize all_true and any_true for control. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Fri, 31 Jul 2020 15:07:12 +0000 - rev 542885
Push 123095 by lhansen@mozilla.com at Fri, 31 Jul 2020 15:12:33 +0000
Bug 1640669 - Part 1: Optimize all_true and any_true for control. r=jseward This removes the generation of a boolean result for all_true and any_true operations that will subsequently just be tested to perform control flow. It uses the standard Ion framework for this. The test case tests that the optimization is triggered (in this simple setting), and that it produces correct code. (The optimization also triggers on a couple of test cases in the imported spec test suite.) Differential Revision: https://phabricator.services.mozilla.com/D85180
579816a223371c1c3984bf1f3b8af4e5fe99774e: Bug 1650621: mask the shift count when considering direct lowering of i64x2.shr_s; r=jseward
Benjamin Bouvier <benj@benj.me> - Wed, 15 Jul 2020 15:54:10 +0000 - rev 540572
Push 121803 by bbouvier@mozilla.com at Wed, 15 Jul 2020 15:56:34 +0000
Bug 1650621: mask the shift count when considering direct lowering of i64x2.shr_s; r=jseward When lowering i64x2.shr_s, we can emit a simpler sequence if the shift count is constant and less than 32; otherwise, a bigger code sequence needs to be generated. When making this decision, the shift count wasn't masked, making it so that a negative shift count would satisfy this condition but could be greater than 32, in the immediate case. Masking the shift count solves the issue and makes it also possible to use the constant code sequence for larger shift counts. The mask value of 63 is appropriate per specification, since we're operating on an i64x2 register. Differential Revision: https://phabricator.services.mozilla.com/D82884
3ce9af6580b2748bd34837cb3d1aa074c6f76436: Bug 1644424 - Report triggering of SIMD constant folding. r=jseward
Lars T Hansen <lhansen@mozilla.com> - Mon, 15 Jun 2020 13:53:18 +0000 - rev 535688
Push 119019 by lhansen@mozilla.com at Mon, 15 Jun 2020 14:21:31 +0000
Bug 1644424 - Report triggering of SIMD constant folding. r=jseward Inserts logging (active in DEBUG builds) and adds test cases that check that the constant folding is triggered in at least trivial cases, cf other test cases in the same test file. Differential Revision: https://phabricator.services.mozilla.com/D78928