This ends up changing the NoThrow condition on CheckPrivateField to instead emulate the object check of JSOp::In instead.
As well, to create PrivateOpEmitter::Kind::ErgonomicBrandCheck, it's no longer aliased to the ElemOpEmitter::Kind enum.
Differential Revision: https://phabricator.services.mozilla.com/D114024
This ends up changing the NoThrow condition on CheckPrivateField to instead emulate the object check of JSOp::In instead.
As well, to create PrivateOpEmitter::Kind::ErgonomicBrandCheck, it's no longer aliased to the ElemOpEmitter::Kind enum.
Differential Revision: https://phabricator.services.mozilla.com/D114024
In short, this patch adds support for vector registers on ARM64, including
machinery to save and restore them on the stack. It also cleans up and
documents some of the save/restore logic.
There are many changes:
* We add a new type, Bitset128, that can represent the register set on ARM64
with vector registers. This is a mostly-constexpr class with two uint64_t's
that behaves like a 128-bit integer in the cases we need for register sets.
* Since the new type is 16 bytes wide, misc code throughout the system that
switches on register set width is updated to handle the case.
* The FloatRegisters::SetType is changed to use Bitset128, and various
constants defined in ARM64 FloatRegisters are updated to reflect this. As
the constants are constexpr, we can be reasonably sure that there are no
initialization-order problems introduced by this.
* The registers in ARM64 FloatRegisters are rearranged so that single comes
before double, which comes before vector registers, to conform to the order
used everywhere else.
* In MacroAssembler.h, the semantics required of PushRegsInMask and its
associated functions have been further documented.
* For ARM64, PushRegsInMask and its associated functions (PushRegsInMask,
storeRegsInMask, PopRegsInMaskIgnore, ReduceSetForPush, GetPushSizeInBytes,
getRegisterDumpOffsetInBytes, and new function
FloatRegister::BroadcastToAllSizes), have been rewritten to handle
saving/restoring of SIMD registers. PushRegsInMask and storeRegsInMask have
been merged into a single function so as to reduce code duplication and the
associated danger of mistakenly writing different formats.
* In many places that are ARM64-specific, code guarded by `#ifndef
ENABLE_WASM_SIMD` has been removed, so that in effect we always assume that
SIMD register state is available on the target, and can be loaded and
stored, even though we haven't yet enabled ARM64 SIMD support per se.
* The routines PushRegsInMaskForWasmStubs, PopRegsInMaskForWasmStubs and
GetPushSizeInBytesForWasmStubs have been removed, since their operation has
now been subsumed into their non-`ForWasmStubs` equivalents.
* In Safepoints.cpp, {Write,Read}FloatRegisterMask have been rewritten to
support 128-bit sets. One side effect is that reads/writes of 64-bit chunks
have been changed to use new routines {write,read}Unsigned64 rather than two
uses of {write,read}Unsigned. The effect is to save one byte when
bits 64:32 are all zero.
* Ridealong cleanup: the constant ION_FRAME_SLACK_SIZE has been removed. It
has no known uses.
* Note that RABALDR_SIDEALLOC_V128 is still in place in the wasm baseline
compiler. This patch does not remove it.
Differential Revision: https://phabricator.services.mozilla.com/D100116
There's a separate usecase here that overloaded JS_OPTIMIZED_ARGUMENTS. getMissingArgumentsMaybeSentinelValue returns JS_OPTIMIZED_ARGUMENTS if it can't recreate the arguments object. The comment on createMissingArguments explains that this occurs if the environment is dead; see `tests/debug/Frame-eval-12.js`, where we return an inner function that subsequently tries to access its parent's arguments. There's a bunch of code on the devtools side of the wall to handle this case, and we have test coverage, so instead of ripping this out I'm just rewriting it to use a different magic value.
Depends on D114171
Differential Revision: https://phabricator.services.mozilla.com/D114172
After the previous patches, JSScript still has three flags related to arguments analysis. Two of them are immutable (`argumentsHasVarBinding` and `alwaysNeedsArgsObj`), and one is mutable (`needsArgsObj`). We can simplify this down to just `needsArgsObj`, which is now immutable.
After the simplification, there's no longer any difference between `argsObjAliasesFormals` and `argumentsAliasesFormals`.
Depends on D114034
Differential Revision: https://phabricator.services.mozilla.com/D114035
The `HAS_ARGS_OBJ` flag in BaselineFrame needs to stick around for the baseline interpreter, but it's immutable for the baseline compiler. (The next patch will move `needsArgsObj` from MutableFlags to ImmutableFlags.)
Depends on D114033
Differential Revision: https://phabricator.services.mozilla.com/D114034
This patch moves the alloc kind out of the flags word and places it between the
freespan and the zone. On 64 bit platforms there is 32 bits of padding here
because zone has pointer alignment and the freespan is 32 bits. On 32 bits
platforms this increases the size of the header but there is enough spare that
this doesn't reduce the arena density for any of our alloc kinds.
This also lets us type allocKind appropraitely.
Depends on D114213
Differential Revision: https://phabricator.services.mozilla.com/D114214
This commit implements the extended-constants proposal.
* A new feature flag and pref are added.
* Basic tests are added.
Differential Revision: https://phabricator.services.mozilla.com/D112661
ref.func validates specially.
* In the 'module environment', any function may be the target and using a function
as a target marks it as available to be targeted in the code section.
* The the code section, only functions used in the 'module environment' may
be targeted.
Additionally, any target of ref.func becomes an 'exported function' and will get
a thunk generated for it. The logic for this existed in ModuleGenerator, which
would traverse over all relevant metadata in ModuleEnvironment to find which
functions may be exported. This no longer is trivial, as an InitExpr may
now contain a ref.func instruction encoded in its bytecode vector, instead
of the tagged union that InitExpr was before.
To satisfy all of these requirements, this patch reworks this code.
* A `FuncFlags` enum is added to `FuncDesc` for each function definition.
* `FuncFlags` describes whether a func is exported, eager, and can be
targetted by ref.func.
* Decoding the ModuleEnvironment now updates the flags of functions as
it goes.
* OpIter uses the validation mode to determine whether to check the
func flags for a ref.func, or not.
* ConstExpr::decodeAndValidate updates the flags of functions as it goes.
* ModuleGenerator no longer computes the exported function information
itself, and relies on function flags.
* AsmJS writes to function flags for exported functions specially, as
it previously relied on sharing the exported function code in
ModuleGenerator that has moved to decoding/validation.
Differential Revision: https://phabricator.services.mozilla.com/D112659
This commit rewrites InitExpr so that it supports multiple instructions. This
unlocks the ability to implement the extended-constants proposal, along with
rtt.canon/rtt.sub initializers for the GC proposal.
An InitExpr now contains either a literal value for simple expressions, or
a vector of bytecode to be evaluated later. Decoding an InitExpr now uses OpIter
to iterate over instructions and validate the results. OpIter is tweaked to
support alternate validation rules to support the additional restrictions that
initializer expressions have, such as global.get only working on immutable
imported globals. The exception is ref.func, which has special rules that I
defer to its own commit to follow.
An interpreter loop is added to evaluate the bytecode and yield a wasm::Val.
The loop uses a Decoder directly and assumes that the bytecode has been validated
already. The interpreter is not fast, and I assume it doesn't need to be at
this time.
Much code that assumed InitExp was POD had to be updated. Notably, GlobalDesc's
fields have been reorganized to remove the double nested union to make it
sane to store allocated data in it.
I initially intended for the expanded constant expression support to have
it's own header and implementation file (WasmInitExpr.h, WasmInitExpr.cpp).
I then discovered that InitExpr is involved with a challenging include loop
with WasmTypes.h and settled with a just giving it it's own implementation
file. This is unusual for `wasm/` some I'm open to discussions. In the
longer term, I would like to break up WasmTypes.h.
Differential Revision: https://phabricator.services.mozilla.com/D112658
Non-essential clean up of OpIter to prepare for being used to decode
and validate constant expressions, in addition to function bodies.
Depends on D112655
Differential Revision: https://phabricator.services.mozilla.com/D112656
Non-essential clean-up to split off functionality for binary parsing out
of validation. This is useful for a future interpreter loop which runs
in a non-validation context, and would only like to deal with a
Decoder.
Differential Revision: https://phabricator.services.mozilla.com/D112654
Improved error messages emitted by JSMSG_TYPED_ARRAY_CONSTRUCT_BOUNDS.Error messages improved to specify the type and cause of error.
Added the test to check the error messages modified matches the expected cases.
Differential Revision: https://phabricator.services.mozilla.com/D113874
During calls to read() and write() for JSAutoStructuredCloneBuffer the
data callbacks and closure are ignored also if none are explicitly
passed.
Use them in such case
Differential Revision: https://phabricator.services.mozilla.com/D114195
This is using js::SharedArrayRawBufferRefs that is a private API and not
exported. Leaving it in the header makes linking not to work when using
StructuredClone:
JSStructuredCloneData::~JSStructuredCloneData()':
/usr/include/mozjs-78/js/StructuredClone.h:459:
undefined reference to
`js::SharedArrayRawBufferRefs::~SharedArrayRawBufferRefs()
Differential Revision: https://phabricator.services.mozilla.com/D114128
Introduce moz.configure, WasmFeatures, and StaticPrefList.yaml
machinery to define a config option for relaxed SIMD
(https://github.com/WebAssembly/relaxed-simd). At the moment, there
are no defined relaxed SIMD opcodes, but a dozen or so are in the
works. This just sets us up for implementing those.
Differential Revision: https://phabricator.services.mozilla.com/D114117
Matthew Gaudet
Csoregi Natalia
Steve Fink
Yury Delendik
Julian Seward
Tooru Fujisawa
Narcis Beleuzu
Iain Ireland
Yulia Startsev
Jon Coppeard
Asumu Takikawa
Ryan Hunt
AshwiniWankhede
mr.robot
Marco Trevisan (Treviño)
Sandor Molnar
Lars T Hansen
Brindusan Cristian