This re-arranges some deckchairs, allowing to have the launcher
process query the Windows packaged app environment.
Depends on D129882
Differential Revision: https://phabricator.services.mozilla.com/D130187
After part 1 we can lift the single name operand restriction and emit
`JSOp::OptimizeSpreadCall` for all calls with a single spread argument.
Differential Revision: https://phabricator.services.mozilla.com/D131243
This commit changes the byte code for optimised spread calls to emit the spread
operand only once.
The new `BytecodeEmitter::emitSpreadIntoArray()` method was added to spread an
on-stack value into an array. This method is needed to avoid emitting the spread
operand another time in 'BytecodeEmitter::emitArray()`.
Differential Revision: https://phabricator.services.mozilla.com/D131242
`...arguments` can be seen as if a rest array object had been created for a
function without additional formals:
```js
// |f| and |g| have identical semantics when all iteration related functions
// are still in their initial state.
function f() { h(...arguments); }
function g(...rest) { h(...rest); }
```
The idea when replacing `MArrayFromArgumentsObject` is now as follows:
We replace `MArrayFromArgumentsObject` with the identical instructions we use
when creating a rest array (cf. `WarpBuilder::build_Rest()`), except that we set
the number of formals to zero. So inlined arguments are replaced with either
`MNewArrayObject` or `MNewArray` and non-inlined arguments are replaced with
`MRest`.
We then rely on scalar replacement for these replacements, so that we eventually
end up with all instructions replaced. This works because scalar replacement
processes the graph in reverse post-order and because the new instructions are
placed after `MCreate{Inlined}ArgumentsObject`.
The `ArrayFromArgumentsObjectResult` CacheIR op is changed to hold the shape of
the default array shape. This change is needed so that scalar replacement can
replace `MArrayFromArgumentsObject` with `MNewArrayObject` for the case of
inlined arguments.
Differential Revision: https://phabricator.services.mozilla.com/D130989
When the `arguments` object is still in its initial state (no overridden
elements, length, or iterator), `...arguments` can be optimised to directly
create the spread array from the arguments' content instead of going through
the iterator code.
The CacheIR code additionally disallows overridden or forwarded arguments in
order to further optimise this operation during scalar replacement. See part 4.
Differential Revision: https://phabricator.services.mozilla.com/D130987
The current `JSOp::OptimizeSpreadCall` optimisation only works when the input
is already a packed array. So it won't help to optimise code like
`super(...arguments)`, which is emitted by the TypeScript compiler when
creating default derived class constructors.
For example:
```ts
class Example extends Object {
public name = "field";
}
```
Is compiled to:
```js
class Example extends Object {
constructor() {
super(...arguments);
this.name = "field";
}
}
```
To support this pattern, `JSOp::OptimizeSpreadCall` is changed to return a
packed array instead of returning `true` when the optimisation can be applied.
When the optimisation can't be used, `undefined` is returned instead of `false`.
The emitted byte code looks roughly like:
```
array_or_undef = optimiseSpreadCall(value);
if (array_or_undef === undefined) {
// Emit iterator protocol code.
}
spreadCall(array_or_undef);
```
The additional comparison `array_or_undef === undefined` needs to be handled
during scalar replacement, so we can still scalar replace arrays in optimised
spread calls.
Parts 2-4 will add `arguments` support to `JSOp::OptimizeSpreadCall`.
Differential Revision: https://phabricator.services.mozilla.com/D130986
This required 2 changes:
- fixing WatcherActor notifyTargetAvailable so we get notified about the iframe
target when doing a bfcache navigation (a test case is added in browser_target_command_bfcache.js as well)
- Checking is the target isn't destroyed in inspector onTargetSelected
Differential Revision: https://phabricator.services.mozilla.com/D131471
This patch performs MIR-level folding of bitwise {and/or/xor}{32,64} arising
from wasm inputs. JS handling of and/or/xor is unchanged -- this patch adds a
new path (MIR node) for the wasm/machine-level-semantics versions of these
operations, which then participates in constant folding (via GVN) in the
"normal" way. Changes:
jit-test/tests/wasm/binop-x64-ion-folding.js:
* new file with test cases
jit/MIR.h:
* new node kind MWasmBinaryBitwise for wasm-only {and/or/xor}{32,64}
jit/MIR.cpp:
* new method MWasmBinaryBitwise::foldsTo to handle all folding cases
* added a few small helper functions for ::foldsTo
jit/Lowering.cpp:
* LIRGenerator::visitTest: also accept MWasmBinaryBitwise with subopcode And
when creating LBitAndBranch instructions.
* LIRGenerator::lowerBitOp: change arg type from MBinaryBitwiseInstruction to
MBinaryInstruction so as to also accept MWasmBinaryBitwise.
* LIRGenerator::visitWasmBinaryBitwise: new function. Generate LIR using
scheme identical to that of MBinaryBitwiseInstruction.
wasm/WasmIonCompile.cpp
* a new overload for MDefinition* binary(..), taking a
MWasmBinaryBitwise::SubOpcode value
* generate MWasmBinaryBitwise as appropriate, via function
EmitBitwiseAndOrXor
* remaining uses of EmitBitwise renamed to EmitShift
Differential Revision: https://phabricator.services.mozilla.com/D130038
Added api to collect overlapping snapshots (i.e. those from urls that the user interacted with within an hour of the context url).
This will allow for more relevant snapshot selection.
Differential Revision: https://phabricator.services.mozilla.com/D131132
After part 1 we can lift the single name operand restriction and emit
`JSOp::OptimizeSpreadCall` for all calls with a single spread argument.
Differential Revision: https://phabricator.services.mozilla.com/D131243
This commit changes the byte code for optimised spread calls to emit the spread
operand only once.
The new `BytecodeEmitter::emitSpreadIntoArray()` method was added to spread an
on-stack value into an array. This method is needed to avoid emitting the spread
operand another time in 'BytecodeEmitter::emitArray()`.
Differential Revision: https://phabricator.services.mozilla.com/D131242
`...arguments` can be seen as if a rest array object had been created for a
function without additional formals:
```js
// |f| and |g| have identical semantics when all iteration related functions
// are still in their initial state.
function f() { h(...arguments); }
function g(...rest) { h(...rest); }
```
The idea when replacing `MArrayFromArgumentsObject` is now as follows:
We replace `MArrayFromArgumentsObject` with the identical instructions we use
when creating a rest array (cf. `WarpBuilder::build_Rest()`), except that we set
the number of formals to zero. So inlined arguments are replaced with either
`MNewArrayObject` or `MNewArray` and non-inlined arguments are replaced with
`MRest`.
We then rely on scalar replacement for these replacements, so that we eventually
end up with all instructions replaced. This works because scalar replacement
processes the graph in reverse post-order and because the new instructions are
placed after `MCreate{Inlined}ArgumentsObject`.
The `ArrayFromArgumentsObjectResult` CacheIR op is changed to hold the shape of
the default array shape. This change is needed so that scalar replacement can
replace `MArrayFromArgumentsObject` with `MNewArrayObject` for the case of
inlined arguments.
Differential Revision: https://phabricator.services.mozilla.com/D130989
When the `arguments` object is still in its initial state (no overridden
elements, length, or iterator), `...arguments` can be optimised to directly
create the spread array from the arguments' content instead of going through
the iterator code.
The CacheIR code additionally disallows overridden or forwarded arguments in
order to further optimise this operation during scalar replacement. See part 4.
Differential Revision: https://phabricator.services.mozilla.com/D130987
The current `JSOp::OptimizeSpreadCall` optimisation only works when the input
is already a packed array. So it won't help to optimise code like
`super(...arguments)`, which is emitted by the TypeScript compiler when
creating default derived class constructors.
For example:
```ts
class Example extends Object {
public name = "field";
}
```
Is compiled to:
```js
class Example extends Object {
constructor() {
super(...arguments);
this.name = "field";
}
}
```
To support this pattern, `JSOp::OptimizeSpreadCall` is changed to return a
packed array instead of returning `true` when the optimisation can be applied.
When the optimisation can't be used, `undefined` is returned instead of `false`.
The emitted byte code looks roughly like:
```
array_or_undef = optimiseSpreadCall(value);
if (array_or_undef === undefined) {
// Emit iterator protocol code.
}
spreadCall(array_or_undef);
```
The additional comparison `array_or_undef === undefined` needs to be handled
during scalar replacement, so we can still scalar replace arrays in optimised
spread calls.
Parts 2-4 will add `arguments` support to `JSOp::OptimizeSpreadCall`.
Differential Revision: https://phabricator.services.mozilla.com/D130986
Well, the RDP method "detach" still exists, but is now destroying the target actor.
There is no more intermediate state where the actor is "detached" but not destroyed,
which is confusing and no longer useful now that we can longer attach again.
Differential Revision: https://phabricator.services.mozilla.com/D130916
This might make the leftover "detach" method a bit more special.
But ideally we would get rid of it and convert it to a call to target actor's destroy method.
Differential Revision: https://phabricator.services.mozilla.com/D130915
By doing that, we no longer have to ensure calling attach here and there.
Some followups will be helpful to get rid of detach and all mentions of attach/detach/attached.
Some code, like descriptors and tests are still calling attach, which is now a no-op.
Gettind rid of detach might be slightly more complicated.
Differential Revision: https://phabricator.services.mozilla.com/D130843
Calling attach was important to bootstrap the thread actor and retrieve its actorID.
But now with server target this is done early on and we already retrieve the actorID
via form(). Except for workers, but I fixed that.
The next patch will ensure that, on the server side we fully initialize the target actors
as soon as they are created.
Differential Revision: https://phabricator.services.mozilla.com/D130842
...rather than by unsetting the old remote ssrc on all other conduits that
already have it set.
With this patch we don't risk re-entrancy into UnsetRemoteSSRC (CallWrapper,
VideoConduit) or SetRemoteSSRCConfig (VideoConduit).
Differential Revision: https://phabricator.services.mozilla.com/D130270
Narcis Beleuzu
Gijs Kruitbosch
Ben Hearsum
Nick Alexander
Sebastian Hengst
sotaro
Bryce Seager van Dyk
stransky
André Bargull
ffxbld
Hannah Peuckmann
Nicolas Chevobbe
Julian Seward
Raphael Ferrand
Andrew Creskey
Frederik Braun
Marian-Vasile Laza
amy churchwell
Alexandre Poirot
Henrik Skupin
Kershaw Chang
Gecko
Andreas Pehrson
Christoph Kerschbaumer