The object flags are only relevant for the last property's shape. Comparing them
to the flags stored in the property's shape could result in doing unnecessary work
in certain (actually redundant) cases.
Differential Revision: https://phabricator.services.mozilla.com/D110222
When allocating a plain object with no reserved slots, the information that we need from the template object is minimal: the shape, the AllocKind, and the number of fixed/dynamic slots. To make it possible to share code between NewObject ICs, this patch reads the relevant information out of the template object in NewObjectIRGenerator and encodes it into the CacheIR. We generate code using a new masm function that effectively inlines `initGCThing` and `initGCSlots` into `createGCObject`.
Conveniently, every `JSOp::NewObject` is a plain object with no reserved slots, so this patch reduces the total number of baseline ICs compiled by 2/3. In a future patch we can get rid of NewObjectIRGenerator::tryAttachTemplateObject completely.
The old code didn't support dynamic slots. It's simple enough that I just went ahead and implemented it. In a quick browser experiment, ~8-10% of NewObject ICs had dynamic slots. To limit the length of the unrolled loop, I capped support at 16, which covers ~2/3 of cases with dynamic slots. (Because we always initialize the entire capacity, which is always a power of 2, this just means we support 16 fixed + 7 dynamic, and 16 fixed + 15 dynamic.) We could also consider a follow-up patch that generates an actual loop for dynamic slots and removes the cap.
Differential Revision: https://phabricator.services.mozilla.com/D110341
If we inline a function, then range analysis may truncate an argument to the inlined function. If the callee changes, we need to recover the non-truncated argument, or else we may get the wrong result. (There's a slightly more detailed walkthrough of the bug on Bugzilla.)
We mark the arguments to inlined functions as implicitly used in `buildInlinedCall`, but we don't set UseRemoved. The difference between the two flags isn't particularly clear anyway, so this patch folds UseRemoved into ImplicitlyUsed.
Adding two reviewers because this indirectly touches range analysis, and I find all this code tricky to reason about.
***
Differential Revision: https://phabricator.services.mozilla.com/D110004
* In `CacheIRWriter::copyStubData`, assert stub fields are aligned based on their size.
* On 32-bit platforms, add padding to `ICCacheIRStub` and `IonICStub` to ensure stub data is aligned to 8 bytes.
* On 32-bit platforms, insert a padding field in `CacheIRWriter::addStubField` if necessary.
* Fix alignment assertions in `CacheIRStubInfo` methods to include the offset.
Differential Revision: https://phabricator.services.mozilla.com/D110221
If we specialize OSR-only phis to `MIRType::Value` during conversion, then it is possible for `adjustPhiInputs` to see a phi that is still `MIRType::None`. On x86, this ends up with us crashing while trying to box a Value.
It's more robust to do a separate pass at the end of phi specialization, before we start converting.
Differential Revision: https://phabricator.services.mozilla.com/D109976
At the same time, the initialization and storage of private methods is changed
to what the PrivateOpEmitter expects.
There are some barely-observable differences in behavior, resulting in two jit-test changes:
* fields/bug1683784.js - An error message changed. Not really better or worse.
* js/src/jit-test/tests/parser/script-source-extent.js - The debugger is able
to observe initializers as individual scripts. We are no longer using
initializers for private methods that can be optimized, and the debugger
therefore observes the change. I adjusted the test to expect the new
behavior.
All js/src/tests pass.
Depends on D108300
Differential Revision: https://phabricator.services.mozilla.com/D108301
The diff is a mess, but this is very straightforward--we have a combination of
if-statements and a switch that could just be a single switch.
Depends on D108295
Differential Revision: https://phabricator.services.mozilla.com/D108296
In order to correctly support this with the optimized storage for methods we
would need new bytecode like GetAliasedVar which is able to traverse
non-EnvironmentObject environments like DebugEnvironmentProxy.
Unfortunately, for safety this means we will ultimately disable this for a number of
different private field and accessor invocations.
Differential Revision: https://phabricator.services.mozilla.com/D109402
By storing NameLocations we also get a BindingKind, which allows us to disambiguate between
PrivateMethods and Synthetics.
Differential Revision: https://phabricator.services.mozilla.com/D109401
This would cause private methods to be marked as such on scopes, except that
the parser still declares them as `DeclarationKind::Synthetic` for now.
Depends on D108293
Differential Revision: https://phabricator.services.mozilla.com/D108294
This affects bytecode, as Synthetic bindings do not get TDZ checks.
This patch also tightens up some assertions when creating ScopeData. There are
several methods that create ScopeData, and they had gotten out of sync. The
assertions check that the ScopeData is not silently dropping bindings that were
present in ParseContext::Scope::declared_.
Depends on D108292
Differential Revision: https://phabricator.services.mozilla.com/D108293
This is currently used only by the bindings in a ClassBodyScope.
The behavior of these bindings is like Var bindings. There is no longer a TDZ
check, and we don't bother marking them as Uninitialized. So the special case
introduced in bug 1683746, peeking at the binding name to see if we should skip
the TDZ check, is no longer needed.
Depends on D108290
Differential Revision: https://phabricator.services.mozilla.com/D108291
This adds a hasPrivateBrand bit to the MemberInitializers struct in the
stencil. It is necessary to persist this bit across compilation units because
emitInitializeInstanceMembers can be called in direct eval code inside a
derived-class constructor.
Since .privateBrand is currently a `let` binding, this currently emits an
unnecessary CheckAliasedLexical instruction in the constructor for each class
that has nonstatic private methods. We'll eliminate these later on.
Depends on D108289
Differential Revision: https://phabricator.services.mozilla.com/D108290
Not every class gets this special binding. It will be needed for all classes
that have any nonstatic private methods, getters, or setters. With this patch,
we create a .privateBrand binding in the scopes for such classes, and populate
it with a symbol when initializing the class. However, it is not yet being used
anywhere; the constructor does not yet stamp instances with the private brand.
Depends on D108288
Differential Revision: https://phabricator.services.mozilla.com/D108289
It is a copy of BlockLexicalEnvironmentObject. Note that
- ClassBodyScope is *not* a LexicalScope, BUT
- ClassBodyLexicalEnvironmentObject *is* a LexicalEnvironmentObject
This is strictly a matter of how much implementation is shared. The word
"Lexical" in LexicalEnvironmentObject, and to some extent throughout
SpiderMonkey, is alas already pretty meaningless. In the language
specification, all environments are lexical environments.
Depends on D108286
Differential Revision: https://phabricator.services.mozilla.com/D108287
Note: This revision will have to be folded with Parts 3 and 4 before landing, as
the op PushLexicalEnv breaks here, and is replaced with PushClassBodyEnv in Part 4.
Depends on D108283
Differential Revision: https://phabricator.services.mozilla.com/D108284
The rt operand may be the ScratchRegister and will cause an assert fail,
now change the implementation of the function to remove the assert.
Differential Revision: https://phabricator.services.mozilla.com/D110086
This is a shell-only helper method that vaguely represents some complex Gecko
use-cases. At the very least we should not crash with scary compartment
errors.
Differential Revision: https://phabricator.services.mozilla.com/D110153
- Add some new function prototypes support
- Add wsbh/dsbh/dshd instructions support
- Sign-extend ins/lwr instructions' result
Differential Revision: https://phabricator.services.mozilla.com/D109865
Note that starting the off-thread compile simply uses the existing
mechanisms. We only need a special "finish" function to avoid automatic
instantiation.
Differential Revision: https://phabricator.services.mozilla.com/D109958
While this API also parses to a Stencil, care must be taken by callers since
parsing JavaScript text as a module vs global script as different semantics
(as defined in ECMAScript spec).
Differential Revision: https://phabricator.services.mozilla.com/D109974
Jan de Mooij
Dorel Luca
Tom Schuster
Cosmin Sabou
Iain Ireland
smolnar
Alexandru Michis
Yulia Startsev
Florian Quèze
Caroline Cullen
Jason Orendorff
Matthew Gaudet
Zhao Jiazhong
Ted Campbell
Liu Yu