The new `MAdd` and `MSub` constructors with a `MIRType` argument can be used
in these places to directly set the return type and the specialisation. That
way we no longer have to call `setInt32Specialization()` manually.
`MMul` already has a compatible constructor which the desired semantics, so
we can remove the `setInt32Specialization()` call here, too.
Differential Revision: https://phabricator.services.mozilla.com/D69781
--HG--
extra : moz-landing-system : lando
Similar to the previous part, add `MSub::NewWasm` to handle the wasm-specific
initialisation bits, so that `MSub(MDefinition, MDefinition, MIRType)` only
sets the return type and the specialisation.
Differential Revision: https://phabricator.services.mozilla.com/D69780
--HG--
extra : moz-landing-system : lando
Add `MAdd::NewWasm` similar to how we have a separate `MMul:NewWasm` function.
For wasm we want to default to `MDefinition::Truncate` and set the "commutative"
flag for Int32 values.
This frees up the `MAdd(MDefinition, MDefinition, MIRType)` to only set the
specialisation and the return type, which will be required for later patches to
work correctly.
Differential Revision: https://phabricator.services.mozilla.com/D69779
--HG--
extra : moz-landing-system : lando
Later patches will require a constructor with the signature
`MAdd(MDefinition, MDefinition, MIRType)`, which neither sets the truncation
mode nor sets the "commutative" flag. Both things happen with the existing
constructor which has a compatible signature and which is currently called
for the use sites modified in this patch. (The existing constructor is the
one directly appearing before the newly added one.)
The existing constructor defaults to `MDefinition::Truncate` and all callers to
that constructor use the `MIRType::Int32` specialisation. Because all callers
use `MIRType::Int32`, we can omit the type parameter for the new constructor.
The existing constructor is also called from WasmIonCompile, the next part will
handle that caller.
Differential Revision: https://phabricator.services.mozilla.com/D69778
--HG--
extra : moz-landing-system : lando
Ion doesn't use ICs for bit-not `~` with String inputs, which resulted in
`+int32AsString` being noticeably faster than `~~int32AsString`. Handling
string indices makes `~~int32AsString` faster than the IC code, which is what
we'd normally expect.
Drive-by change:
- Reuse `SimpleBitOpOperand()` for `bitnotTrySpecialized()`.
Differential Revision: https://phabricator.services.mozilla.com/D69519
--HG--
extra : moz-landing-system : lando
- `emitGuardAndGetNumberFromString()` was changed to use `ScratchDoubleScope`,
because `FloatReg0` isn't available for Unary ICs. (Lowering doesn't reserve it.)
- `unaryArithTrySpecializedOnBaselineInspector()` now needs to filter String
values to avoid bailouts.
Differential Revision: https://phabricator.services.mozilla.com/D69518
--HG--
extra : moz-landing-system : lando
Directly convert Strings to Int32 to make `+int32AsString` faster and to be
able to have narrower type information for Ion/Warp. Without this change the
unary String ICs for Int32 results from the next part are actually slower than
the ICs for Double results.
`emitGuardAndGetInt32FromString()` is based on the existing
`emitGuardAndGetNumberFromString()` method.
Differential Revision: https://phabricator.services.mozilla.com/D69517
--HG--
extra : moz-landing-system : lando
I've went with `LoadInt32Result` and `LoadDoubleResult` to match the existing
`LoadObjectResult` CacheIR opcode.
The arguments `jsop_binary_arith()` in `IonBuilder::jsop_pos()` needed to be
swapped to match the requirements in `arithUnaryBinaryCache()`.
Differential Revision: https://phabricator.services.mozilla.com/D69516
--HG--
extra : moz-landing-system : lando
`tryAttachNumber()` can actually assert the result is a number when the input
is a number.
Differential Revision: https://phabricator.services.mozilla.com/D69515
--HG--
extra : moz-landing-system : lando
vm/Interpreter-inl.h:
- `IncOperation()` and `DecOperation()` should use a non-mutable handle for their
`val` parameter.
vm/Interpreter.cpp:
- It's not necessary to create two mutable handles for the same input value.
jit/BaselineIC.cpp:
jit/IonIC.cpp:
- Only when caling `BitNot()` and `NegOperation()` we need to copy the input value.
Differential Revision: https://phabricator.services.mozilla.com/D69514
--HG--
extra : moz-landing-system : lando
When D56742 (Bug 1583863) moved BrowsingContext to using SyncedContext
a few comments were left which refer to non-existent files / methods.
I've updated these comments to be consistent with the current code,
moved them to a more appropriate location and removed/updated the stale
references.
Differential Revision: https://phabricator.services.mozilla.com/D69152
--HG--
extra : moz-landing-system : lando
Similarly to changeset cfa64a6b5a87, a scope's enclosing scope is no longer updated by MovingTracer::onScopeEdge following the changes in bug 1625212. Update the suppression list accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D69986
--HG--
extra : moz-landing-system : lando
This patch modifies the reloadConsoleAndLog helper so it can
consumes an array of expected messages, and not only a number
of expected messages.
This should prevent the performance variations caused by new
warning messages being added.
Differential Revision: https://phabricator.services.mozilla.com/D69816
--HG--
extra : moz-landing-system : lando
I tested this works by adding things like this to `Compartment::wrap(cx, obj)`
and then executing `newGlobal({newCompartment: true})`:
```
RootedId id(cx);
cx->check(id, obj);
```
Differential Revision: https://phabricator.services.mozilla.com/D70019
--HG--
extra : moz-landing-system : lando
bindgen::CargoCallbacks will emit rustc-rerun-if-changed for included headers
so that the build system can re-run build.rs if any header used is changed.
Differential Revision: https://phabricator.services.mozilla.com/D69882
--HG--
extra : moz-landing-system : lando
It seems there was no unit test exercising this code in e10s.
This copies the simple test from test_esni_dns_fetch.js to make sure
we have a little code coverage for the IPC code too.
Differential Revision: https://phabricator.services.mozilla.com/D69327
--HG--
extra : moz-landing-system : lando
This patch makes nsIDNSByTypeRecord extend nsIDNSRecord, but implementations
will safely forward the nsIDNSRecord methods to `nullptr`, meaning they will
throw an error when called.
Consumers should try to QI the nsIDNSRecord to nsIDNSByTypeRecord (or any
future types) and use that.
Differential Revision: https://phabricator.services.mozilla.com/D69326
--HG--
extra : moz-landing-system : lando
`inputmode=none` means that OSK is closed.
`SetInputContext` doesn't call `DismissOnScreenKeyboard` directly since
`DismissOnScreenKeyboard` has no hack of Firefox VR.
Depends on D68316
Differential Revision: https://phabricator.services.mozilla.com/D68317
--HG--
extra : moz-landing-system : lando
As long as I test on my environment, bug 1226148 isn't fixed. Since native
message queue has high priority, Gecko may check whether focus is changed
before changing focus to another.
So we shouldn't use native message queue for this. It is better to use idle
queue instead.
Depends on D68315
Differential Revision: https://phabricator.services.mozilla.com/D68316
--HG--
extra : moz-landing-system : lando
Unfortunately, current on-screen keyboard (OSK) code in Gecko doesn't work on
current Windows 10. Actually, Windows automatically control OSK when getting
focus. But this isn't good for web browser since `inputmode` spec can close
OSK by `none` value.
Windows 10 RS1 has new API (IInputPane [*1]) to control software keyboard. So
we have to use it if OS is RS1 or later.
TSF has new flag as `TS_SD_INPUTPANEMANUALDISPLAYENABLE` not to control OSK by
TSF. We should use it.
IMM doesn't have this feature to manage OSK. This will become a limitation for
`inputmode` implementation.
[*1] https://docs.microsoft.com/en-us/uwp/api/windows.ui.viewmanagement.inputpane
Depends on D68314
Differential Revision: https://phabricator.services.mozilla.com/D68315
--HG--
extra : moz-landing-system : lando
Current WHATWG spec is that `inputmode` attribute supports non-input element.
I would like to remove input element check for bug 142484 that is
contenteditable support.
Microsoft IME, Google IME and etc refer 1st input scope that they support, so
we will add both input scopes from `type` and `inputmode`.
Depends on D68313
Differential Revision: https://phabricator.services.mozilla.com/D68314
--HG--
extra : moz-landing-system : lando
Current WHATWG spec means that `numeric` is `IS_DIGITS` and `decimal` is
`IS_NUMBER`.
Depends on D68312
Differential Revision: https://phabricator.services.mozilla.com/D68313
--HG--
extra : moz-landing-system : lando
Gecko has duplicated code for input scope support, so I would like to clean up
this.
Differential Revision: https://phabricator.services.mozilla.com/D68312
--HG--
extra : moz-landing-system : lando
This patch changes the test that browsertime runs for speedometer from `raptor-speedometer-APP` to `speedometer` and changes some other small issues like the missing app name in the `extraOptions` field in the perfherder data.
Differential Revision: https://phabricator.services.mozilla.com/D69581
--HG--
extra : moz-landing-system : lando
Previously we could start more parallel tasks than there were work items. This changes things around so we take a work item when we create a ParallelWorker, so that we can stop creating them if we run of of work.
I change the foreground cell update code to not use ParallelWorker at all for work that happens entirely on the main thread and doesn't need synchronisation.
Differential Revision: https://phabricator.services.mozilla.com/D66962
--HG--
extra : moz-landing-system : lando
This adds the ability to do four-stage PGO builds. This was surprisingly straightforward thanks to PGO being a well-supported scenario in LLVM's cmake.
For reference, the stages are:
stage1: Initial build with gcc
stage2: Instrumented build using stage1
stage3: Train by using the instrumented stage2 to build the clang tree
stage4: Optimize using the stage3 compiler and the profdata created with it
Differential Revision: https://phabricator.services.mozilla.com/D69080
--HG--
extra : moz-landing-system : lando
Separating out the mechanical/"boring" changes to make the next patch more clear. This patch adds the ability to build a fourth stage that for now doesn't do anything special.
I changed to using >= to make it more obvious that e.g. "here is what's going to happen for stage 2" -- the off-by-one was too hard on my brain.
Differential Revision: https://phabricator.services.mozilla.com/D69079
--HG--
extra : moz-landing-system : lando
Otherwise, PGO builds would fail to find asan at stage2 because the instrumented build uses `LLVM_BUILD_RUNTIME=No`.
Differential Revision: https://phabricator.services.mozilla.com/D69082
--HG--
extra : moz-landing-system : lando
This will partially atone for making builds longer with PGO.
Depends on D69618
Differential Revision: https://phabricator.services.mozilla.com/D69620
--HG--
extra : moz-landing-system : lando
