`LoadWrapperTarget` is used when reading properties from the global object. The
alias set can't be `AliasSet::None()`, because the target changes when the
`document` is moved.

Differential Revision: https://phabricator.services.mozilla.com/D90220

I also added a test that I forgot to commit last time.

Differential Revision: https://phabricator.services.mozilla.com/D90545

Differential Revision: https://phabricator.services.mozilla.com/D90464

This patch adds an enum class to track the inlining state per fallback stub and
uses it for the following:

* Don't scan CacheIR of stubs we definitely can't inline (will matter more for getters/setters).
* Similarly, optimize the check for trial-inlined stubs in WarpOracle.
* Assert in WarpOracle that we didn't trial-inline a stub the transpiler doesn't support.
* Ensure we never attempt a second trial-inlining at the same location.

Differential Revision: https://phabricator.services.mozilla.com/D90410

Depends on D90422

Differential Revision: https://phabricator.services.mozilla.com/D90423

Differential Revision: https://phabricator.services.mozilla.com/D90422

Later on we could remove the BytecodeLocation/JSOp use too and replace it with a
tag/flag on trial-inliable stubs.

Differential Revision: https://phabricator.services.mozilla.com/D90230

To help prevent badness (security, perf, memory usage) in pathological cases.

Differential Revision: https://phabricator.services.mozilla.com/D90229

Differential Revision: https://phabricator.services.mozilla.com/D90228

This makes inlining more effective because we can inline more before Warp compilation
happens.

Differential Revision: https://phabricator.services.mozilla.com/D90227

To prevent getting stuck in Baseline because we can't tier up in trial-inlined
scripts.

Differential Revision: https://phabricator.services.mozilla.com/D90226

Differential Revision: https://phabricator.services.mozilla.com/D90225

Differential Revision: https://phabricator.services.mozilla.com/D90224

Problem was a SetProp of the form `x.prop = x` where we pushed the RHS and then
clobbered its register, but that also clobbered the object register on x86 because
it was the same register.

This patch adds an extra temp register to some of these instructions and uses
that instead.

Differential Revision: https://phabricator.services.mozilla.com/D90223

Currently there is a "benign" race between background sweeping and gray
unmarking. The latter does not affect the result of the former, but any data
race is undefined behaviour.

This patch changes the marking bitsmaps to be relaxed atomic to avoid this.
Marking bitmaps were already excluded from TSAN checks.

Differential Revision: https://phabricator.services.mozilla.com/D90239

Rewriting this code to make it obvious that we only attach specialized constructor stubs if we have enough information about `this` to inline.

Note: the old code used `skipAttach` in more cases, but after looking at it more closely, the new script analysis is the only case where it makes sense.

This version matches the corresponding pre-CacheIR call IC code (https://searchfox.org/mozilla-central/rev/3c073ca1ae02fd52fd6be584aa343b78999842fa/js/src/jit/BaselineIC.cpp#3509-3545).

Differential Revision: https://phabricator.services.mozilla.com/D90197

To make sure we're testing recursive inlining, I've tweaked the thresholds to ensure that we can inline two levels deep without any loops. I've also made the inlining heuristics slightly more conservative, which prevents `check-earley-boyer` from timing out.

I've also included a few drive-by fixes. The change to `isRecursive` in `DoTrialInlining` only affects the jitspew message, because both ways of finding the `InliningRoot` are equivalent for the non-recursive case.

Differential Revision: https://phabricator.services.mozilla.com/D89875

AFAICT, outside of the bytecode generator, there is no longer any difference between `JSOp::Super` and `JSOp::New` except for the expression decompiler.

Differential Revision: https://phabricator.services.mozilla.com/D89874

We already did the hard work to handle `this` creation for transpiling, so inlining is pretty straight-forward.

`patchInlinedReturn` needs to know whether we're calling a derived constructor to avoid repeated bailouts in `MReturnFromCtor`. I used a similar solution to what anba did here: https://phabricator.services.mozilla.com/D58785). Once Ion is gone, we could consider modifying `MReturnFromCtor` instead.

Differential Revision: https://phabricator.services.mozilla.com/D89873

Instead of storing a flag in GuardSpecificFunction, I reused the CallFlags that are already being stored in the call. This also lets us avoid a VM call in the baseline IC.

After Ion is gone, we can consider storing a ConstructorKind in CallFlags (with values `None`, `UninitializedThis`, `Template`, and `VMCall`) and moving the template object offset from `MetaTwoByte` into `CallScriptedFunction`.

Differential Revision: https://phabricator.services.mozilla.com/D89872

This add a similar optimization as js::StaticStrings for tiny strings to the
ParserAtoms mechanism. This includes (some) length 1 and length 2 atoms for
fast lookup. This is effective for large minified JS files and can speed up
syntax-parsing by up to 20% in some cases. We extend the atomIndex_ Variant
to have new `StaticParserString{1,2}` types which we use to in toJSAtom to
quickly translate to the corresponding StaticStrings.

Depends on D90152

Differential Revision: https://phabricator.services.mozilla.com/D90153

Later patches will add more types of known-atoms and MaybeOneOf has a limit
on the number of types.

Differential Revision: https://phabricator.services.mozilla.com/D90152

This lets us specialize how and when well-known lookups are done.

Differential Revision: https://phabricator.services.mozilla.com/D90151

Depends on D90149

Differential Revision: https://phabricator.services.mozilla.com/D90150

In this code we often use 'length' to refer to number of char16_t and this
can be a little confusing with UTF-8 so instead use 'nbytes' as the argument
until we establish what length of the inflated sequence is.

Depends on D90148

Differential Revision: https://phabricator.services.mozilla.com/D90149

The `$` and `_` characters are legal JS identifiers and can show up a fair
bit in large minified code-bases. This changes the {to,from}SmallChar which
is used during `StaticStrings::init`. We already use a table-based lookup
while atomizing so there isn't additional perf cost during atomization.

Differential Revision: https://phabricator.services.mozilla.com/D90148

Backed out changeset 71d14ede1fcb (bug 1664312)
Backed out changeset 15482e97aa4a (bug 1664312)
Backed out changeset 210475dc1429 (bug 1664312)
Backed out changeset 7c31676a20cd (bug 1664312)
Backed out changeset 8867b79ee8ea (bug 1664312)
Backed out changeset 2267cc975235 (bug 1664826)

This add a similar optimization as js::StaticStrings for tiny strings to the
ParserAtoms mechanism. This includes (some) length 1 and length 2 atoms for
fast lookup. This is effective for large minified JS files and can speed up
syntax-parsing by up to 20% in some cases. We extend the atomIndex_ Variant
to have new `StaticParserString{1,2}` types which we use to in toJSAtom to
quickly translate to the corresponding StaticStrings.

Depends on D90152

Differential Revision: https://phabricator.services.mozilla.com/D90153

Later patches will add more types of known-atoms and MaybeOneOf has a limit
on the number of types.

Differential Revision: https://phabricator.services.mozilla.com/D90152

This lets us specialize how and when well-known lookups are done.

Differential Revision: https://phabricator.services.mozilla.com/D90151

Depends on D90149

Differential Revision: https://phabricator.services.mozilla.com/D90150

In this code we often use 'length' to refer to number of char16_t and this
can be a little confusing with UTF-8 so instead use 'nbytes' as the argument
until we establish what length of the inflated sequence is.

Depends on D90148

Differential Revision: https://phabricator.services.mozilla.com/D90149

The `$` and `_` characters are legal JS identifiers and can show up a fair
bit in large minified code-bases. This changes the {to,from}SmallChar which
is used during `StaticStrings::init`. We already use a table-based lookup
while atomizing so there isn't additional perf cost during atomization.

Differential Revision: https://phabricator.services.mozilla.com/D90148

Differential Revision: https://phabricator.services.mozilla.com/D88970

Instead of trying to fixup the guard dependencies of MGetDOMPropertyBase I instead just disabled
moving. I think that should prevent the instruction to move across guards that it doesn't directly
depend on, i.e the prototype guards.

Depends on D90011

Differential Revision: https://phabricator.services.mozilla.com/D90087

Differential Revision: https://phabricator.services.mozilla.com/D90011

Differential Revision: https://phabricator.services.mozilla.com/D90010

Differential Revision: https://phabricator.services.mozilla.com/D88970

Differential Revision: https://phabricator.services.mozilla.com/D90243