Normal arguments that spill on the stack are packed, but not variadic
arguments. This is handled correctly for their placement already, but
code generated on the callee side with va_list expects word-size
sign-extension, so we need to fill the entire word.
Upstreamed as https://github.com/libffi/libffi/pull/577.
Differential Revision: https://phabricator.services.mozilla.com/D87825
All the patches previously applied, except the one from bug 1279096,
are either irrelevant (as pertaining to changes to the upstream build
system we don't use anymore), were applied upstream, or the issue they
fixed were fixed differently upstream.
Two additional patches, sent upstream as
https://github.com/libffi/libffi/pull/579 and
https://github.com/libffi/libffi/pull/580, are needed to fix our build
with, respectively, mingw-clang and GCC.
Our build system is adjusted according to upstream's configure.ac
and configure.host.
Differential Revision: https://phabricator.services.mozilla.com/D87824
It never told libffi what the variadic arguments were.
Also fix the ctypes declaration of test_vector_add_va_cdecl in the unit test,
which is actually wrong, but the test still passed for some reason.
Differential Revision: https://phabricator.services.mozilla.com/D87557
Normal arguments that spill on the stack are packed, but not variadic
arguments. This is handled correctly for their placement already, but
code generated on the callee side with va_list expects word-size
sign-extension, so we need to fill the entire word.
Upstreamed as https://github.com/libffi/libffi/pull/577.
Differential Revision: https://phabricator.services.mozilla.com/D87825
All the patches previously applied, except the one from bug 1279096,
are either irrelevant (as pertaining to changes to the upstream build
system we don't use anymore), were applied upstream, or the issue they
fixed were fixed differently upstream.
Two additional patches, sent upstream as
https://github.com/libffi/libffi/pull/579 and
https://github.com/libffi/libffi/pull/580, are needed to fix our build
with, respectively, mingw-clang and GCC.
Our build system is adjusted according to upstream's configure.ac
and configure.host.
Differential Revision: https://phabricator.services.mozilla.com/D87824
`MStoreElement` with `needsHoleCheck=false` matches the Baseline implementation
of `StoreDenseElementHole`. `MStoreElementHole` handles more cases than the
Baseline (and Ion) implementation of StoreDenseElementHole`, namely it also
allows to set elements for `index > initializedLength`.
The `index > initializedLength` restriction for `StoreDenseElementHole` may be
lifted in the future when it's no longer necessary to call `noteHasDenseAdd()`
for Ion.
Differential Revision: https://phabricator.services.mozilla.com/D87563
Using `MLoadElement` with `needsHoleCheck=true` to trigger a bailout when a
hole is encountered was slightly slower than the new `MGuardElementNotHole`
instruction from this patch, even though the `MLoadElement` from a `JSOp::In`
can be merged with a subsequent `MLoadElement` from a `JSOp::GetElem`. This
sequence happens for the common pattern of `if (i in array) val = array[i]`.
The magic value check in `LGuardElementNotHole` works without unboxing the
value, so it's possible using separate instructions leads to fewer register
dependencies (when compared to merging the `MLoadElement`), which helps
speculative execution. And because the loaded value may still be in a cache,
it doesn't matter to load it repeatedly.
Differential Revision: https://phabricator.services.mozilla.com/D87562
The code generator uses a signed value and the value is implicitly coerced to
`int32_t` anyway (via `Int32Value`), so we might as well directly use `int32_t`
for that function.
Differential Revision: https://phabricator.services.mozilla.com/D87561
`StoreDenseElementHole` and `ArrayPush` are both preceded by shape guards and
are only attached when the object has a writable array length. That means the
generated code doesn't actually need to test `NONWRITABLE_ARRAY_LENGTH`,
because it's implied by the shape guard: Changing the array length to
non-writable through either `js::ArraySetLength` or `js::SetIntegrityLevel`
already changes the shape and thus invalidates the shape guard.
The same applies to the non-extensible bits, so we can assert that, too.
Drive-by change:
Remove the `thisarray->lengthIsWritable()` assertion in `tryAttachArrayPush`
because it's tested just a few lines earlier.
Differential Revision: https://phabricator.services.mozilla.com/D87560
Use Maybe<uint64_t> for the max size in three places where this is required.
Drive-by fix: Use standard printf macros for formatting, and use them correctly.
Differential Revision: https://phabricator.services.mozilla.com/D87710
It appears that the existing limit of 16 args for CacheIR was established when we first added FunApplyArray support in bug 906781 and never revisited.
Depends on D87681
Differential Revision: https://phabricator.services.mozilla.com/D87682
1. tryAttachFunApply was the last remaining use of GuardSpecificNativeFunction.
2. The FunApplyArgs side of GuardFunApply can be reimplemented using existing CacheIR ops. We might be able to do a similar thing with GuardFunApplyArray, but it will require a bit of refactoring, so I'm leaving it as its own op for now.
3. Like FunCall, FunApply now has a Specialized variant that guards on the specific target to make inlining easier.
Differential Revision: https://phabricator.services.mozilla.com/D86856
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
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
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
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
The flag setting in the ModuleEnv if shared memory is available was using the
wrong predicate. In addition to looking at if shared memory is effectively
enabled, it should also look at whether we're fuzzing or not.
This fixes crashes that happen only when fuzzing, that is, running the shell
with --wasm-compiler=cranelift --fuzzing-safe.
Differential Revision: https://phabricator.services.mozilla.com/D87739
The idea behind removing marking of wrapper rooters from the mark phase is OK
except we rely on marking being done by the time we start sweeping (we can't
yield between the end of marking and the start of sweeping) and if we delay
marking these wrappers until the sweep phase we may end up with marking work to
do at this point.
The fix is to mark these in mark slices that may end up sweeping (mostly this
doesn't happen because we yield before we start sweeping). Then the marking
gets done by markUntilBudgetExhausted before we get to the sweep phase.
Differential Revision: https://phabricator.services.mozilla.com/D87459
This data structure is the same between ScriptStencil and BaseScript forms so
it belongs in SharedStencil.h. Avoid pulling in CompileOptions.h by passing
lineno/column explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D87070
Eventually we'll have to adjust on x86_64 mac too if we want to be able
to run some tests under Rosetta, but let's leave that for another day.
Differential Revision: https://phabricator.services.mozilla.com/D87549
Restricting LoadStringCharResult to Latin-1 characters means Warp won't be
able to optimise accesses when Two-Byte characters are present. Instead slow
generic VM calls were used for string accesses.
Differential Revision: https://phabricator.services.mozilla.com/D87101
Implement `MCompare::tryFoldCharCompare` to port the improvements from
bug 813836 and bug 1538690. This wasn't previously handled through `foldsTo`,
because relational comparison support for strings (bug 1538692) wasn't present
at that point of time.
Differential Revision: https://phabricator.services.mozilla.com/D87099
This adjusts the feature test to accept SIMD on beta+release for
x86/x64, since we're letting SIMD ride the trains behind a pref that
is off by default. In the shell, we don't make a distinction for
prefs between nightly and non-nightly, so test that SIMD is on in
beta+release on these platforms. It's complicated: SIMD may be off if
the hardware is feeble. See comment in the test.
(The alternative is to start making that distinction in the setting of
the shell flag, but does anyone benefit from this?)
Differential Revision: https://phabricator.services.mozilla.com/D87224
Ideally this would be reworked to separate out the barrier from HashableValue
but that ended up being more work than expected. This is a small fix to clear
the value and avoid the barrier in this situation.
Differential Revision: https://phabricator.services.mozilla.com/D87293
wasm::ToCString is losing relevance as we have more constructed types. This
commit removes ToCString and replaces all uses with wasm::ToString.
Differential Revision: https://phabricator.services.mozilla.com/D85071
ref.null takes a heaptype immediate. This is backwards compatible for
reference-types, but is a breaking change for the GC proposal. This commit
implements decoding for this refinement.
Differential Revision: https://phabricator.services.mozilla.com/D85069
TypeCode::OptRef is currently used to represent any reference-typed value
for UnpackTypeCodeTypeAbstracted and IsReferenceType. I think it's actually
clearer to have this behind a named constant.
Differential Revision: https://phabricator.services.mozilla.com/D85066
wasm::Table uses wasm::TableKind to determine the element type of the table,
which makes it difficult to extend tables to support more reference types. This
commit drops TableKind in favor of directly storing the element RefType, along
with a flag for whether this table is forAsmJS, which influences the funcref
ABI. RefType is extended to return the existing TableRepr enum, which indicates
the memory representation to use for the table.
wasm::ElemSegment uses wasm::ValType, which is a superset of the allowed
types of an elem segment. This commit switches it to use the proper
RefType class, and tweaks decoding.
Differential Revision: https://phabricator.services.mozilla.com/D85064
This commit renames the TypeCode/ValType/RefType occurrences of 'any' to 'extern'
to match what they actually represent. All public API facing occurrences have
already been switched to 'externref' so this should only be aligning the
internal names with their extern usage.
Comments that only apply to 'externref' code paths are renamed as well.
Differential Revision: https://phabricator.services.mozilla.com/D85063
This commit finishes the split of wasm/gc and wasm/ref-types tests by splitting
the disabled-ref.js test into a GC test and a ref-type test.
Differential Revision: https://phabricator.services.mozilla.com/D85061
Follow-up to the previous commit that moved these tests over to wasm/ref-types,
this commit renames the tests from 'anyref' to 'externref'.
Differential Revision: https://phabricator.services.mozilla.com/D85060
The tests in wasm/gc are a mix of reftypes/gc tests. This commit adds a
ref-types folder and moves relevant tests over.
Differential Revision: https://phabricator.services.mozilla.com/D85059
The function-references spec refined ref.null to take a heaptype, which has a
slightly different text format for non-nullable references. This commit updates
tests to the new syntax.
Differential Revision: https://phabricator.services.mozilla.com/D85056
Wat now implements the module-linking proposal which includes one-level imports.
This commit removes tests of the text format which asserted these were not-valid.
Differential Revision: https://phabricator.services.mozilla.com/D85055
When we removed subtyping, we kept the anyref text syntax as an alias of
externref. This commit completes the migration over to externref. A future
commit will switch uses of externref which should be anyref back.
Differential Revision: https://phabricator.services.mozilla.com/D85053
This adds a thread count for GC parallel tasks calculated from GC parameters
for a helper thread ratio and max helper thread count. It also adds one to
report the number of helper threads used for GC.
This is slightly complicated by the fact that the helper thread system is
per-process and there are potentially many JS runtimes in a process. I
disallowed setting these parameters from workers (i.e. child JS runtimes), but
there may be more than one non-worker JS runtime so this isn't perfect.
I had to swap the mutex order for the GC and helper thread locks. Whatever
reason they were the other way round seems to have gone and this order makes
more sense to me (I see the GC lock as being 'coarser' than the helper thread
lock).
Differential Revision: https://phabricator.services.mozilla.com/D86725
Currently we hack around the protected data checks during helper thread
initialization in GlobalHelperThreadState::ensureContextListForThreadCount.
This removes the need to do that and allows us to simplify that method. I added
some more assertions in JSContext::set/clearHelperThread too.
Differential Revision: https://phabricator.services.mozilla.com/D87423
wasm::ToCString is losing relevance as we have more constructed types. This
commit removes ToCString and replaces all uses with wasm::ToString.
Differential Revision: https://phabricator.services.mozilla.com/D85071
ref.null takes a heaptype immediate. This is backwards compatible for
reference-types, but is a breaking change for the GC proposal. This commit
implements decoding for this refinement.
Differential Revision: https://phabricator.services.mozilla.com/D85069
TypeCode::OptRef is currently used to represent any reference-typed value
for UnpackTypeCodeTypeAbstracted and IsReferenceType. I think it's actually
clearer to have this behind a named constant.
Differential Revision: https://phabricator.services.mozilla.com/D85066
wasm::Table uses wasm::TableKind to determine the element type of the table,
which makes it difficult to extend tables to support more reference types. This
commit drops TableKind in favor of directly storing the element RefType, along
with a flag for whether this table is forAsmJS, which influences the funcref
ABI. RefType is extended to return the existing TableRepr enum, which indicates
the memory representation to use for the table.
wasm::ElemSegment uses wasm::ValType, which is a superset of the allowed
types of an elem segment. This commit switches it to use the proper
RefType class, and tweaks decoding.
Differential Revision: https://phabricator.services.mozilla.com/D85064
This commit renames the TypeCode/ValType/RefType occurrences of 'any' to 'extern'
to match what they actually represent. All public API facing occurrences have
already been switched to 'externref' so this should only be aligning the
internal names with their extern usage.
Comments that only apply to 'externref' code paths are renamed as well.
Differential Revision: https://phabricator.services.mozilla.com/D85063
This commit finishes the split of wasm/gc and wasm/ref-types tests by splitting
the disabled-ref.js test into a GC test and a ref-type test.
Differential Revision: https://phabricator.services.mozilla.com/D85061
Follow-up to the previous commit that moved these tests over to wasm/ref-types,
this commit renames the tests from 'anyref' to 'externref'.
Differential Revision: https://phabricator.services.mozilla.com/D85060
The tests in wasm/gc are a mix of reftypes/gc tests. This commit adds a
ref-types folder and moves relevant tests over.
Differential Revision: https://phabricator.services.mozilla.com/D85059
The function-references spec refined ref.null to take a heaptype, which has a
slightly different text format for non-nullable references. This commit updates
tests to the new syntax.
Differential Revision: https://phabricator.services.mozilla.com/D85056
Wat now implements the module-linking proposal which includes one-level imports.
This commit removes tests of the text format which asserted these were not-valid.
Differential Revision: https://phabricator.services.mozilla.com/D85055
When we removed subtyping, we kept the anyref text syntax as an alias of
externref. This commit completes the migration over to externref. A future
commit will switch uses of externref which should be anyref back.
Differential Revision: https://phabricator.services.mozilla.com/D85053
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
Given that temps never alias inputs as established in the previous patch, this
assertion isn't necessary. It's possible the LSRA allocator did things differently.
The assertion was also weird/wrong because it depends on LDefinition::Type, but
there are multiple Types that could still map to the same Register. It looks
like bug 1067610 broke this; before that refactoring we compared isFloatReg().
Differential Revision: https://phabricator.services.mozilla.com/D87264
Temps cover both the input and output part of the instruction, so their ranges
always overlap with at-start uses (covering the input) and non-at-start uses
(covering both input and output). This means the allocated register must be
different from any uses.
Defs cover only the output part of the instruction so there at-start makes a
difference.
Differential Revision: https://phabricator.services.mozilla.com/D87263
I noticed this while looking at D87232. Using an exhaustive switch makes it easier to find all the places that need to be updated when adding a new ValueType.
Differential Revision: https://phabricator.services.mozilla.com/D87273
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
This adds guards in readValType() and in the validator, and a test
case that checks that the guards are working if SIMD is disabled.
Nearly everything was in place already and this is almost all
plumbing; the exception is the new guard in WasmValidate.h.
Differential Revision: https://phabricator.services.mozilla.com/D86949
`WarpCacheIRTranspiler::emitAssertRecoveredOnBailoutResult()` was copied from the
MCallOptimize implementation. A new `addEffectfulUnsafe()` helper was added to
avoid triggering the safety assertions in `addEffectful()`. The `MResumePoint`
also needs to be created manually to avoid triggering assertions in the
`WarpCacheIRTranspiler::resumeAfter()` helper. Bypassing the safety assertions
should be okay in this case, because `assertRecoveredOnBailout()` is a fuzzy
unsafe testing function, so we can directly control how it is called.
JIT tests which don't (yet) pass in Warp have been disabled and annotated
with "TODO(Warp)".
Drive-by change:
- Use `add()` in `WarpCacheIRTranspiler::addDataViewData()`.
Differential Revision: https://phabricator.services.mozilla.com/D86528
Change Atomics for Uint32 TypedArrays to use Double-typed numbers. That way we
get a stable return type (always Double typed instead of Int32 or Double typed),
which ensures we get a deterministic inlining behaviour in Ion and make it
possible to inline Atomics functions for Uint32 in Warp.
Differential Revision: https://phabricator.services.mozilla.com/D86932
Noticed while working on ArraySlice that ArrayPush and ArrayJoin have
unnecessary rooting. Also found some other places where rooting can
be omitted.
Differential Revision: https://phabricator.services.mozilla.com/D86533
Optimise Array.prototype.slice for packed arrays in CacheIR and Warp. Ion
also optimises `slice()` for non-packed arrays, but unless non-packed arrays
actually appear in user code, only optimising packed arrays should be okay
for now.
The second argument to `slice()` defaults to the array length, which means
we need a non-result version of `LoadInt32ArrayLength`.
Drive-by change:
- Move `IonCacheIRCompiler::emitArrayPush` to the bottom of the file,
next to the other non-implemented methods. Also change from
`MOZ_ASSERT_UNREACHABLE` to `MOZ_CRASH` for consistency.
Differential Revision: https://phabricator.services.mozilla.com/D86532
The test case crashes without this patch when two `AutoScratchRegister`
are added to `BaselineCacheIRCompiler::emitStringFromCodeResult()`.
Differential Revision: https://phabricator.services.mozilla.com/D87028
This adds a thread count for GC parallel tasks calculated from GC parameters
for a helper thread ratio and max helper thread count. It also adds one to
report the number of helper threads used for GC.
This is slightly complicated by the fact that the helper thread system is
per-process and there are potentially many JS runtimes in a process. I
disallowed setting these parameters from workers (i.e. child JS runtimes), but
there may be more than one non-worker JS runtime so this isn't perfect.
I had to swap the mutex order for the GC and helper thread locks. Whatever
reason they were the other way round seems to have gone and this order makes
more sense to me (I see the GC lock as being 'coarser' than the helper thread
lock).
Differential Revision: https://phabricator.services.mozilla.com/D86725
Noticed while working on ArraySlice that ArrayPush and ArrayJoin have
unnecessary rooting. Also found some other places where rooting can
be omitted.
Differential Revision: https://phabricator.services.mozilla.com/D86533
Optimise Array.prototype.slice for packed arrays in CacheIR and Warp. Ion
also optimises `slice()` for non-packed arrays, but unless non-packed arrays
actually appear in user code, only optimising packed arrays should be okay
for now.
The second argument to `slice()` defaults to the array length, which means
we need a non-result version of `LoadInt32ArrayLength`.
Drive-by change:
- Move `IonCacheIRCompiler::emitArrayPush` to the bottom of the file,
next to the other non-implemented methods. Also change from
`MOZ_ASSERT_UNREACHABLE` to `MOZ_CRASH` for consistency.
Differential Revision: https://phabricator.services.mozilla.com/D86532
The CacheIR implementation uses the new `LoadValueTruthyResult` op instead of
the existing `LoadThingTruthyResult` ops to mirror how Warp implements boolean
coercion: Warp doesn't use ICs but instead uses MNot resp. MTest with Value
typed inputs.
Mirroring this approach avoids to have (from the user POV) strange performance
differences where for example using `if (Boolean(v))` can be faster than just
`if (v)`, when `v` is Value-typed, but monomorphic.
Differential Revision: https://phabricator.services.mozilla.com/D86524
We have to loosen this assertion to handle cases where we trial-inline a script because `needsArgsObj` is false, but then we call argumentsOptimizationFailed on that script before we reach the warp oracle.
Depends on D86771
Differential Revision: https://phabricator.services.mozilla.com/D86772
The CacheIR implementation uses the new `LoadValueTruthyResult` op instead of
the existing `LoadThingTruthyResult` ops to mirror how Warp implements boolean
coercion: Warp doesn't use ICs but instead uses MNot resp. MTest with Value
typed inputs.
Mirroring this approach avoids to have (from the user POV) strange performance
differences where for example using `if (Boolean(v))` can be faster than just
`if (v)`, when `v` is Value-typed, but monomorphic.
Differential Revision: https://phabricator.services.mozilla.com/D86524
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
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
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
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
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
A lot of entries in the extended jump table were never used because they were for
jumps/calls to other addresses in the executable memory (JitCodes or trampolines).
This patch takes advantage of the contiguous 2 GB executable code buffer: we know
any address in this buffer can always be jumped to without needing an extended jump
table. This also lets us simplify the jump relocation code more.
With Fission coming soon, max 2 GB JIT code per process will hopefully be sufficient.
Depends on D86374
Differential Revision: https://phabricator.services.mozilla.com/D86375
All pending jumps then have a known (non-null) target, so replace an if-statement
with an assertion.
Other platforms don't define addPatchableJump.
Depends on D86368
Differential Revision: https://phabricator.services.mozilla.com/D86370
The jump instruction itself is sufficient to get the address from the extended jump
table. This has been 'dead' code on x64 since the code landed in 2011. ARM64 copied it.
Differential Revision: https://phabricator.services.mozilla.com/D86368
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
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
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
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
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
As part of DOM node adoption they are transplanted, and their expando chains are copied over.
This copying uses JS_CopyPropertiesFrom, which until this patch, cannot see
private fields as they are excluded from property iteration. This patch adds
property iteration for private fields, and renames JS_CopyPropertiesFrom to
JS_CopyOwnPropertiesAndPrivateFields which is more accurate.
The users of this method are all doing object manipulation in ways where
preserving the copied private field is the better default.
In addition to testing DOM nodes explicitly, this patch also adds a jit-test
which uses transplantableObject to test similar things with FakeDOMObjects.
Differential Revision: https://phabricator.services.mozilla.com/D84737
Uint32 isn't yet supported, because it may return a Double, which is difficult
to represent in CacheIR. Bug 1077305 proposes to unconditionally use Double
for Uint32 Atomics, which will make this easier to implement in CacheIR.
Differential Revision: https://phabricator.services.mozilla.com/D86299
Also add an assertion for this to MacroAssembler::initTypedArraySlots. This replaces
some invalid code that used dataSlotOffset instead of dataOffset.
Not adding the test because with the new assertion this failed jit-tests.
Differential Revision: https://phabricator.services.mozilla.com/D86551
* If WarpBuilder is enabled, use WarpBuilder instead of IonBuilder for the analysis itself.
* Support optimized-arguments accesses in the transpiler (FunApplyArgs is still missing).
* Slow paths insert MGuardNotOptimizedArguments to deoptimize optimized-arguments.
Differential Revision: https://phabricator.services.mozilla.com/D86003
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
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
Replace sequences of `branchTestObject` followed by `unboxObject` with a
single call to `fallibleUnboxObject`.
`fallibleUnboxObject(src, dst, fail)` clobbers `dst` on failure, so for each
updated call site we need to make sure `dst` isn't used when we jump to `fail`.
Differential Revision: https://phabricator.services.mozilla.com/D86158
This makes us use one less tool from MSVC, and removes one more use of wine
in cross builds.
We replace the call to either rc/llvm-rc or windres with a wrapper script.
While the script is not strictly needed for the latter, we use a wrapper
in that case anyway because it's one step towards fixing bug 1498414.
For llvm-rc, however, we need a wrapper because llvm-rc doesn't preprocess
on its own, so the wrapper does that too.
The wrapper script also allows to deal with the default flags passed to
llvm-rc or windres, rather than inherit them from old-configure.
We also need to explicitly pass the codepage to llvm-rc, which was not
necessary with rc (presumably, llvm-rc has a different default).
While here, remove the unused WINDRES subst from js/src/old-configure.in.
Also, while here, we remove --use-temp-file, because as described in the
linked bug and in the windres manual page, it was used to work around bugs
on Windows 98 and earlier.
Differential Revision: https://phabricator.services.mozilla.com/D86312
This can cause the URL preloader to think that initialization has succeeded
when it hasn't. This add observer call can fail if we're late in shutdown,
because the observer service still exists, but it isn't taking new
observers. I'm not sure how much it matters that we're failing to listen for
an observer that can't possibly fire at this stage, but a failure to check
for this seems to have contributed to the crash in bug 1656973, so we
might as well just fail.
Differential Revision: https://phabricator.services.mozilla.com/D86031
Some of the entry points into the URL preloader check sInitialized, and only
use it if it is true. However, if we're late in shutdown and we've already
cleared the singleton for the preloader then our failure to clear the
sInitialized flag means we'll recreate the preloader, which is going
to fail in various ways.
I think this won't help in the case of bug 1656973, because that seems
to go through AutoBeginReading, which unconditionally creates a new
singleton if one does not exist.
Differential Revision: https://phabricator.services.mozilla.com/D86030
Today we don't require that `mach` `CommandProvider`s subclass from any particular parent class and we're very lax about the requirements they must meet. While that's convenient in certain circumstances, it has some unfortunate implications for feature development.
Today the only requirements that we have for `CommandProvider`s are that they have an `__init__()` method that takes either 1 or 2 arguments, the second of which must be called `context` and is populated with the `mach` `CommandContext`. Again, while this flexibility is occasionally convenient, it is limiting. As we add features to `mach`, having a better idea what the shape of our `CommandProvider`s are and how we can instantiate them and use them is increasingly important, and this gives us additional control when having `mach` configure `CommandProvider`s based on data that is only available at the `mach` level. In particular, we plan to leverage this in bugs 985141 and 1654074.
Here we add validation to the `CommandProvider` decorator to ensure all classes inherit from `MachCommandBase`, update all `CommandProvider`s in-tree to inherit from `MachCommandBase`, and update source and test code accordingly.
Follow-up work: we now require (de facto) that the `context` be populated with a `topdir` attribute by the `populate_context_handler` function, since instantiating the `MachCommandBase` requires a `topdir` be provided. This is fine for now in the interest of keeping this patch reasonably sized, but some additional refactoring could make this cleaner.
Differential Revision: https://phabricator.services.mozilla.com/D86255
This adds a new job variant `arm64-cranelift-sim` to the SpiderMonkey
build configurations, and adds a Taskherder CI configuration to run it.
The job uses the aarch64 simulator support built-in to SpiderMonkey, so
it does not need to run on native aarch64 hardware.
A few tests needed to be added to the "slow tests" list as they time out
under the simulator otherwise.
This also fixes an issue with an error message in `build-sm.sh` in which
the overloading of the backtick's meaning (code-quotes in
Markdown-world, and command interpolation in shell scripts) led to an
amusing attempt to execute parts of the error message.
Finally, this fixes an error that seems unrelated to Cranelift or
WebAssembly in a GC jit-test, wherein its way of measuring maximum stack
recursion depth was failing.
Differential Revision: https://phabricator.services.mozilla.com/D86131
Check that we will actually need to fill slots before calling
getFixedSlotOffset. This fixes some sanity check asserts, but the issue is
benign in optimized builds because the invalid `offset` is not used if there
are not slots to fill.
Differential Revision: https://phabricator.services.mozilla.com/D86383
Rather than allowing test code to replace HostResolveImportedModule directly, this adds a test function to register a module and specifier such that attempting to import that specifier later finds the given module (which was what the hook was mostly used to acheive).
Mostly this is test code updates. I deleted test code for bugs which were only caused by the existence of this API in the first place.
Differential Revision: https://phabricator.services.mozilla.com/D85560
Callers to `GetBuiltinPrototype()` rely on inlining the function itself plus
optimising the object access, so that the property value is directly seen as a
constant in the compiler. By changing `GetBuiltinPrototype()` and
`GetBuiltinConstructor()` to be directly translated into a JSOp, we can avoid
heavily relying on the compiler to optimise these two functions.
The new opcode replaces the existing JSOp::FunctionProto opcode. It doesn't
use JSProtoKey directly in order to help jsparagus (bug 1622530), but instead
uses its own set of mapping from enum values to built-in prototypes and
constructors.
This change also resolves bug 1377264.
Differential Revision: https://phabricator.services.mozilla.com/D84991
Inling `ObjectHasPrototype()` using the `GuardProto` CacheIR op for the normal
case when the prototype chain wasn't modified.
Also change `intrinsic_ObjectHasPrototype()` to expect that both objects are
`NativeObject`, because then we don't need to handle proxies in CacheIR.
Drive-by change:
- Use `staticPrototype()` in ObjectOperations-inl.h instead of effectively inlining it.
Differential Revision: https://phabricator.services.mozilla.com/D84984
This is part two to support comparing strictly different types in Warp.
The operation doesn't have any result, so when folding it, `MNop` is used to
optimise it away when the value tags are already different at compile time.
Differential Revision: https://phabricator.services.mozilla.com/D84980
Swapping `bi`'s operands should depend on `bi` itself being commutative.
Drive-by change: Use `std::swap` to swap the operands.
Differential Revision: https://phabricator.services.mozilla.com/D84977
LoadValueTag is used when comparing strictly different types. This happens in
the string built-ins when the this-value is a primitive string and it is
compared against null or undefined.
Value tags are represented as MIRType::Int32 and folding is supported to be
able to optimise away the checks after inlining.
Differential Revision: https://phabricator.services.mozilla.com/D84976
This assert was intended to assure that off-thread parse realm sets the same
special prototype flags off-thread as on-thread. In practice though, the
`setImmutablePrototype` testing function allows us to set the flag on a
common prototype which confuses the assert.
Differential Revision: https://phabricator.services.mozilla.com/D86243
This improves performance a lot when a long string is atomized more than once. This
is happening on Reddit (strings with length 1897).
The cache is also used to de-duplicate strings during nursery GC before it's purged.
This handles some cases the existing string deduplication doesn't handle and if a
string is in the StringToAtomCache it should be faster.
Differential Revision: https://phabricator.services.mozilla.com/D86171
Steve Fink
Cosmin Sabou
Kannan Vijayan
Adam Vandolder
Mike Hommey
Bogdan Tara
Tooru Fujisawa
André Bargull
Lars T Hansen
Caroline Cullen
Iain Ireland
Jeff Walden
Tom Schuster
Benjamin Bouvier
Jon Coppeard
Nicolò Ribaudo
Ted Campbell
Ryan Hunt
Jan de Mooij
Dorel Luca
Kris Maglione
Csoregi Natalia
Razvan Maries
kanishk509
yulia
Sylvestre Ledru
Matthew Gaudet
Ricky Stewart
Chris Fallin
daemon1024
Evan Welsh
Andrew McCreight
Mihai Alexandru Michis