The code that uses these fields is part of a subsequent patch. This patch is just getting the tracing right.
Differential Revision: https://phabricator.services.mozilla.com/D48782
--HG--
extra : moz-landing-system : lando
Right now there BinAST is the only case, but subsequent patches will add GC pointers to XDR encoders and decoders.
Differential Revision: https://phabricator.services.mozilla.com/D48781
--HG--
extra : moz-landing-system : lando
JS_BIT and JS_BITMASK are only used in contexts where uint32_t is used, so these
two functions are now typed to accept and return uint32_t.
JS_HOWMANY and the three JS_ROUND functions are only used with size_t inputs,
so these four functions are now typed to accept and return size_t.
Differential Revision: https://phabricator.services.mozilla.com/D51142
--HG--
extra : moz-landing-system : lando
Both macros compute the same result, so we can replace ROUNDUP with JS_ROUNDUP.
Differential Revision: https://phabricator.services.mozilla.com/D51141
--HG--
extra : moz-landing-system : lando
When the `Debugger` API sets a breakpoint in a JSScript or wasm::Instance, the
BreakpointSite and Breakpoint objects belong to the code's compartment
(logically, at least - they're C++ objects and don't actually have any
compartment). Since a `Debugger` and its debuggees must be in separate
compartments, the Breakpoint's references to its owning `Debugger` and its
handler object must go through cross-compartment wrappers.
If we have nuked the `Debugger`'s compartment, it's not clear how we're still
trying to set breakpoints in its debuggees, but we should at least throw an
error, to capture a JavaScript stack when it occurs.
Differential Revision: https://phabricator.services.mozilla.com/D51210
--HG--
extra : moz-landing-system : lando
Use a single implementation in CacheIRCompiler.cpp for CacheIR emitters which
can be updated to the changed AutoCallVM class.
Differential Revision: https://phabricator.services.mozilla.com/D49922
--HG--
extra : moz-landing-system : lando
The previous parts had separate Baseline and Ion implementations for some
CacheIR ops, because AutoCallVM only supports Values as the return type. With
this patch AutoCallVM can deduce the return types from VM calls, so more return
types than just Values can be supported.
Differential Revision: https://phabricator.services.mozilla.com/D49921
--HG--
extra : moz-landing-system : lando
Comparisons between BigInts and Strings is the only remaining unsupported
sloppy equality operation. Add support for these operand types, so there's
no unexpected performance cliff for non-Object operands in equality
comparisons.
Differential Revision: https://phabricator.services.mozilla.com/D49920
--HG--
extra : moz-landing-system : lando
When comparing a BigInt against an Int32, it's not actually necessary to call
into the VM, because we only need to perform some range checks and unsigned
comparisons, which can all be performed directly in inline assembly. This
gives another easy >2x performance improvement compared to the previous part.
Differential Revision: https://phabricator.services.mozilla.com/D49918
--HG--
extra : moz-landing-system : lando
Adds support to compare BigInt and Number values against each other. In contrast
to binary operations, comparison operations allow mixing BigInts and Numbers.
For example when testing if a BigInt value is negative, `bigInt < 0` can be used
in addition to `bigInt < 0n`.
Differential Revision: https://phabricator.services.mozilla.com/D49917
--HG--
extra : moz-landing-system : lando
Comparing Booleans with either Doubles or Strings always performs ToNumber on
the Boolean operand. So when we add a Boolean to (boxed) Number operation to
CacheIR, we can reuse the existing support for comparing Numbers resp. comparing
Numbers and Strings and further trim down the list of unsupported sloppy equality
operations.
Differential Revision: https://phabricator.services.mozilla.com/D49916
--HG--
extra : moz-landing-system : lando
Comparing a Symbol with one of {String,Boolean,Number,BigInt} is always false (resp.
true for NE/STRICTNE), so it's easy to support this case, too.
Differential Revision: https://phabricator.services.mozilla.com/D49915
--HG--
extra : moz-landing-system : lando
The list of unsupported operations with missing some entries and wasn't
consistent when to omit equivalent cases.
Differential Revision: https://phabricator.services.mozilla.com/D49914
--HG--
extra : moz-landing-system : lando
The separate `LBitOpV` class is no longer needed, because `LBitOpV` and
`LBinaryV` now both use `Value` for their input and output parameters.
Differential Revision: https://phabricator.services.mozilla.com/D49913
--HG--
extra : moz-landing-system : lando
Ion never emitted MBinaryCache for bitwise- and shift-operations, so we never
used Ion CacheIR for these operations on BigInt values and instead always emitted
a LBitOpV, i.e. a VM call. With this patch, the changes in part 4 now also lead
to a performance improvement in Ion code.
Differential Revision: https://phabricator.services.mozilla.com/D49912
--HG--
extra : moz-landing-system : lando
Adds new CacheIR ops to support comparison operations with BigInt operands. All
methods simply call into the VM to perform the actual operation. Comparisons
between two BigInt values can't GC or perform any side-effects, so we can use
an ABI call, which saves us an extra indirection through a VM function wrapper
and makes it possible to use a shared implementation in CacheIRCompiler.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D49911
--HG--
extra : moz-landing-system : lando
Adds new CacheIR ops to support binary operations with BigInt operands. All
methods simply call into the VM to perform the actual operation.
JSOP_URSH isn't supported because it always throws when used with BigInts.
Parts 14/15 move the separate Baseline and Ion implementations into a single
implementation in CacheIRCompiler.
Differential Revision: https://phabricator.services.mozilla.com/D49910
--HG--
extra : moz-landing-system : lando
Adds new CacheIR ops to support unary operations with BigInt operands. All
methods simply call into the VM to perform the actual operation.
Parts 14/15 move the separate Baseline and Ion implementations into a single
implementation in CacheIRCompiler.
Differential Revision: https://phabricator.services.mozilla.com/D49909
--HG--
extra : moz-landing-system : lando
Adds the 'LoadBigIntTruthyResult' CacheIR op to handle BigInts in boolean contexts.
Differential Revision: https://phabricator.services.mozilla.com/D49908
--HG--
extra : moz-landing-system : lando
When adding a pointer to WasmInstance::memCopy, it appears that we ran out of
GPRs for calling and the pointer needed to be passed via stack.
GenerateBuiltinThunk uses ABIFunctionType/ABIArgType, and converts it to
MIRType for calling StackCopy [1]. ArgType_General is treated as being equal to
MIRType::Int32, leading to only half of the pointer being passed correctly on
64bit window systems.
This means that all instance functions currently have an incorrect
ABIFunctionType but avoid this issue because they don't have enough parameters
or don't have a 64bit value that is passed by the stack.
We have to use ABIFunctionType here for compatibility with the ARM/ARM64
simulators, otherwise it would be convenient to use a different representation.
This commit:
1. Adds an ArgType_Pointer which is equivalent to MIRType::Pointer
2. Adds a helper constexpr for defining ABIFunctionType
3. Fixes the ABIFunctionType used for instance calls
4. Fixes the simulators to recognize the new ABIFunctionType's
5. Adds an assertion that the SymbolicAddressSignature and ABIFunctionType
are compatible.
Differential Revision: https://phabricator.services.mozilla.com/D51330
--HG--
extra : moz-landing-system : lando
This commit uses the previous commits to actually optimize the OOL
implementations.
This is done by:
* Passing the heap base pointer to each builtin
* Acquiring the WasmArrayRawBuffer/SharedArrayRawBuffer from this pointer
- This is trivial as they are embedded a fixed offset before the Wasm heap
* Acquiring the heap length from the raw buffer
By doing this, we avoid cache misses from accessing:
TLSData -> Instance -> WasmMemoryObject -> ArrayBufferObject -> WasmArrayRawBuffer
This is enough to get close enough to parity with V8 for small sizes. Further
improvements should be done with an inline generated code path.
Differential Revision: https://phabricator.services.mozilla.com/D50378
--HG--
extra : moz-landing-system : lando
Currently the Wasm memory length for non-shared memory is stored in a slot of
the ArrayBuffer. This commit tracks it in the WasmArrayRawBuffer as well, for
use in a future commit.
Differential Revision: https://phabricator.services.mozilla.com/D50377
--HG--
extra : moz-landing-system : lando
This commit declares WasmArrayRawBuffer in the ArrayBufferObject header. This
will allow WasmInstance to access the buffer in a future commit.
Differential Revision: https://phabricator.services.mozilla.com/D50376
--HG--
extra : moz-landing-system : lando
Whether a module uses shared memory or not is fixed throughout its lifetime. We
can use this to specialize the implementation of memCopy/memFill and remove a
branch on the memory type. This will also be useful when acquiring the memory
length in a future commit, which will require different code per shared-ness.
Differential Revision: https://phabricator.services.mozilla.com/D50375
--HG--
extra : moz-landing-system : lando
This commit drops the requirement to acquire the shared memory lock when we
are only acquiring the length. The length_ field is changed to be an
Atomic<SeqCst> in the process. We still need to acquire the lock when growing
the memory in order to atomically compute the new length and commit the new
pages.
Differential Revision: https://phabricator.services.mozilla.com/D50374
--HG--
extra : moz-landing-system : lando
Spec compliance requires us to check the element type of the
TypedArray at the same time as we check it's a shared TypedArray, not
later. This results in some tests being done twice, but only for the
slow C++ path.
Differential Revision: https://phabricator.services.mozilla.com/D50158
--HG--
extra : moz-landing-system : lando
