On x86/x64 platforms, we were using a call and then immediately popping and
ignoring the return value, so use a jump instead. For architectures that use
a link-register, we no longer clobber it but it was already ignored.
Differential Revision: https://phabricator.services.mozilla.com/D72697
Use helper methods to access the size and length of each trailing array.
We shave 40 bytes off each IonScript by using the difference between two
arrays to compute size rather than storing a dedicated size field.
Differential Revision: https://phabricator.services.mozilla.com/D72675
Order the trailing arrays by descending alignment requirements and use a
similar approach to JitScript for computing sizes and initializing.
Differential Revision: https://phabricator.services.mozilla.com/D72674
This type is a mixin with helper methods for casting and initializing arrays
that follow a struct in the same allocation. Use this for existing JitScript,
PrivateScriptData, RuntimeScriptData, ImmutableScriptData types.
Differential Revision: https://phabricator.services.mozilla.com/D72672
This is used during codegen only so we can simplify the SafepointIndex that
is stored in the IonScript. The resolve method is replaced by a constructor
from CodegenSafepointIndex to SafepointIndex.
Differential Revision: https://phabricator.services.mozilla.com/D72671
This exists for mips-32 targets which expect double values to be 8-byte
aligned. This patch removes the `offset` argument which was misleading.
Instead a `alignedForABI` method is added to the ExitFrameFooter type. This
skips over additional padding added in the MIPS32 trampolines.
Differential Revision: https://phabricator.services.mozilla.com/D72549
We don't support mixing self-hosted and native accessors in `JSPropertySpec`,
therefore we need to move the setter into self-hosted code, too, even though
we only need to have the getter self-hosted to be able to inline it.
Differential Revision: https://phabricator.services.mozilla.com/D72670
This is based on the similar changes for JSOp::Pos (bug 1626297 part 3).
JSOp::Pos and JSOp::ToNumeric are very similar and are now optimized the same
way. Baseline had a fast path for numbers and we now use an IC. The IC should
be faster for BigInt code and has optimizations for string inputs. This will also
give us better type information in Warp.
Differential Revision: https://phabricator.services.mozilla.com/D72333
This is part 5 of implementing the Wasm BigInt<>I64 conversion proposal for inlined Ion to Wasm calls.
This part adds additional Wasm BigInt tests that are aimed specifically to test limits of the inlined calls and
to test more conversion cases that should be covered (e.g., to test ToBigInt instruction cases).
Differential Revision: https://phabricator.services.mozilla.com/D65238
This is part 4 of implementing the Wasm BigInt<>I64 conversion proposal for inlined Ion to Wasm calls.
This part adds the support for I64/BigInt arguments for inlined calls in the MCallOptimize.cpp part of
the IonBuilder. With this commit, the I64 arguments will work on 64-bit platforms, except where arguments
are required to be spilled to the stack due to the ABI (this case is more complicated to support).
On 32-bit platforms, this commit disables the BigInt/I64 support for the inlined call as it does not work
without further changes.
Differential Revision: https://phabricator.services.mozilla.com/D65237
Add a `BufferRelocationOverlay` type and use placement-new when inserting
direct-forward pointers. Also avoid the `HeapSlot*` type since elements may
be free-form in the case of typed-arrays.
Differential Revision: https://phabricator.services.mozilla.com/D72683
In BrowsingContext::SetDocShell(), we indicate that any remote outer window
proxies need to be cleaned up, if we've transitioned from a remote window
proxy to a local one. However, we don't actually do the cleanup until
nsGlobalWindowOuter::SetNewDocument(), so don't assert if we find remote
window proxies when we're in between these two periods.
Also includes a formatting fix by clang-format.
Differential Revision: https://phabricator.services.mozilla.com/D72251
Wasm JS-API objects should be subclassable, and the following should work:
```js
class M extends WebAssembly.Module {};
m = new M(...)
m instanceof M // true
```
The current code will always set the prototype to the original Wasm prototype,
and not the derived prototype.
This commit was written by following the example of
`ArrayBufferObject::class_constructor` which handles this situation.
Differential Revision: https://phabricator.services.mozilla.com/D70965
The `mozilla::IsPod<HashMapEntry` specialisation was only needed for the static
assertions in "js/src/frontend/NameCollections.h". Part 3 removed those, so we
can now also remove `mozilla::IsPod<HashMapEntry`.
Drive-by change:
- Remove no longer needed "mozilla/PodOperations.h" include in mfbt/HashTable.h.
- And then fix up previously transitively included files for RootingAPI.h,
jsfriendapi.h, and Bench.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D69201
We can't use `std::is_trivial` for the table entry type, because the entry value
isn't trivially default constructible. (Neither `mozilla::HashMapEntry` nor
`RecyclableAtomMapValueWrapper` are trivially default constructible.)
So instead of using `std::is_trivial<EntryType>` directly, we have to check
`std::is_trivial<KeyType>` and `std::is_trivial<ValueType>` separately, where
we potentially need to unwrap `ValueType` in case it's
`IsRecyclableAtomMapValueWrapper`.
This allows to remove the `mozilla::IsPod` specialisations for `NameLocation`,
`DeclaredNameInfo`, `MaybeCheckTDZ`, and `RecyclableAtomMapValueWrapper`.
Differential Revision: https://phabricator.services.mozilla.com/D69200
Similar to part 1, use both `std::is_trivial` and `std::is_trivially_destructible`
instead of `mozilla::IsPod` to ensure the vector elements are POD values, so we
can skip constructor/destructor calls.
There's no `mozilla::IsPod` specialisation to remove for this part.
Differential Revision: https://phabricator.services.mozilla.com/D69199
Replace `mozilla::IsPod` with `std::is_trivial` and `std::is_trivially_destructible`,
which should cover the requirements for LifoAlloc. (`std::is_trivial` implies
`is_trivially_default_constructible` and `is_trivially_copyable`.)
`IsPod<OffsetAndDefIndex>` can then be removed.
Differential Revision: https://phabricator.services.mozilla.com/D69198