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
Short of solving this by fully embracing the monorepo build and removing
the projects/ workarounds (which will also require a compat more with
older clang versions we still build with the same script), we can solve
the bustage with a small hack.
Differential Revision: https://phabricator.services.mozilla.com/D131458
The way CommitStyles called into servo caused it to call the closure
multiple times, and we were not dealing with that properly.
Handle the "was called" state internally.
Differential Revision: https://phabricator.services.mozilla.com/D131411
The command site manager needs to be able to do ad-hoc pip
installations, while the Mach site manager needs to manage
the system `sys.path` and conditionally create an on-disk
virtualenv.
By splitting the class into two, we can now give each use case the
attention it deserves.
Differential Revision: https://phabricator.services.mozilla.com/D129529
Sorry for the flip-flop on technique here :S
`validate_environment_packages()` was originally run when checking if a
site is up-to-date to ensure that ad-hoc pip installs didn't replace
needed packages with those of different versions.
However, since it was added, a few notes have come up:
1. The case where requirements change isn't caught by this - that is
caught earlier by the cheap "a requirements file has changed on-disk"
check.
2. This is really slow, and doing it for most Mach commands is not worth
it (as evident by how the `skip_pip_package_check` was already added
for the Mach site's use case).
3. Since the tree as-is doesn't have (common) cases where ad-hoc
installations break an environment, then this check, though helpful,
isn't adding a significant amount of value considering its performance
cost.
However, these aren't to say that this won't be valuable in the future:
I'd like to reach a point where sites are considered "sealed" by
default: no ad-hoc pip installations are allowed.
However, add the ability to mark sites as unsealed/"allowing
ad-hoc pip installations". Then, re-add the pip package check, but only
for such flexible, unsealed virtualenvs.
Differential Revision: https://phabricator.services.mozilla.com/D129692
IIRC, this was added prematurely for an upcoming test due to a faulty
VCS commit split.
Let's temporarily remove this parameter, then re-add it when needed for
whatever test consumes it.
Differential Revision: https://phabricator.services.mozilla.com/D129691
