Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Private class methods define an internal lambda function for the initializer,
but it currently uses source coordinates of [0,0) which isn't very helpful.
This patch updates it to cover the full field name until end of method body.
These distinctions are generally not exposed to users, but having internal
consistency is still helpful for defining engine invariants.
Differential Revision: https://phabricator.services.mozilla.com/D94612
Add tests to document the BaseScripts generated for different parse
constructs and track the sourceStart/sourceEnd values. This uses the debugger
API to find hidden scripts and access the source values. The details this
test checks are arbitrary implementation details, and the test expectations
can be updated as necessary.
Differential Revision: https://phabricator.services.mozilla.com/D94611
Instead of loading instruction-internal simd constants separately (on
x86/x64) and thus potentially increasing register pressure by
requiring temps, load them as part of the operation.
This patch handles a few remaining single-use-of-loaded-const cases,
none of which are probably all that important, this is just hygiene.
In the case where a loaded const is used multiple times, or a single
use can't be gotten rid of without introducing additional moves, we
assume (for now) that it's OK to load the constant separately. The
cases that remain in this class are blends (that will use a mask and
its negation) and a few floating-point slow paths (some with multiple
uses, some with knotty logic).
Differential Revision: https://phabricator.services.mozilla.com/D94557
Instead of loading instruction-internal simd constants separately (on
x86/x64) and thus increasing register pressure by requiring temps,
load them as part of the operation.
This patch adapts the shuffle operation (pshufb). There's a fair
amount of plumbing in the assemblers but the change amounts to
inlining the constant loads into the instruction, getting rid of a
temp, and making sure we bias in favor of lhs == output.
Differential Revision: https://phabricator.services.mozilla.com/D94556
Load-and-widen can be expressed as a single instruction on x86, so
let's specialize this path (in Ion) to avoid temp registers and extra
instructions.
We do what we did for zero-extend and splat: add an attribute to the
MemoryAccessDesc and let the wasmLoad logic take care of the
instruction selection.
Differential Revision: https://phabricator.services.mozilla.com/D94551
Specialize Ion (only) code generation for v128.load32_splat and
v128.load64_splat to avoid going via an integer register, and select
the best instructions.
For the 32-bit case, simply use a 32-bit floating load instead of an
integer load, and the problem takes care of itself.
For the 64-bit case, introduce an attribute on the MemoryAccess
(similar to the one that is already there for zero-extension) and use
this, and generate a single movddup instruction to load and splat the
value.
Since we're here and touching this code, clean up the asserts on the
MemoryAccess attribute bits throughout the code base.
Differential Revision: https://phabricator.services.mozilla.com/D94441
This is a cleanup patch.
Remove all 'src != dest' guards on moveSimd128, moveSimd128Float, and
moveSimd128Int, because they all have that guard built in.
Rewrite some moves that are under such guards to use that family of
masm instructions, and remove the guard.
In a few cases where we continue to use movaps, movapd, and movdqa
directly, make sure we use the right one for the mode (int or float)
we're currently in. This required adapting one whitebox test.
Differential Revision: https://phabricator.services.mozilla.com/D94074
Change register allocation for the shuffle operators so as to generate
better code. Mostly this is about those shuffles that decay into a
permutation of one of the operands.
Add test cases to check the code generation.
Differential Revision: https://phabricator.services.mozilla.com/D94003
See comment 0 on the bug for background on register preferences.
Mostly this blesses existing code with comments justifying the
existing behavior. But also:
- Generate better code (with fewer moves) for pseudo-min and
pseudo-max on x86, this becomes slightly involved because the masm
interfaces need to change on that platform to account for the
desired rhs = pmax(lhs, rhs) operation. Also test this.
- Get rid of pointless abstractions for integer replace_lane.
- Clean up the code for floating replace_lane, notably, remove most of
the complexity for f64x2, by making the operations two-address.
- Add new test cases that test some untested code paths in the
floating replace_lane operations, and that test replace_lane
code generation in general.
Differential Revision: https://phabricator.services.mozilla.com/D93721
Use useRegister / useRegisterAtStart / define / defineReuseInput (as
well as comments) so as to generate (and document) the best code under
context-less assumptions. See comment 0 on the bug for a more general
description of how we use those functions.
We add test cases to assert that the best code is actually generated
when that makes sense. There are test cases only for operations where
the operation itself has explicit, but optional, reg->reg moves at the
beginning of the emitted code to deal with register misallocation.
The test cases assert that extraneous moves are not inserted at the
start of an operation under ideal circumstances, taking into account
whether the operation prefers src == dest or src != dest. For cases
where the operation prefers src == dest the input register is set up
to be the same as the output register, ie, we use local 0 as the
argument and generate a result in the result register; for cases where
the operation prefers src != dest, we use local 1 as the argument.
The test cases are fairly delicate - they may be sensitive to small
changes in Ion; comments in the test files highlight this, and the
tests are not meant to constrain Ion, only to highlight accidental
changes. That said, these tests have already uncovered bugs, and for
now let's see if we can make them stick.
Drive-by fixes:
- prefer AND-with-literal-mask and XOR-with-literal-mask in a couple
of places (instead of preloading the constant) to generate better
code, mostly where this matters right now because we introduce
tests that need to inspect the code; a more general cleanup of this
type of pattern may happen later
- remove unused/unimplemented generality in the negFloatNNxM,
absFloatNNxM, and notTypeNNxM primitives
- make the reuseInput*() primitives assert that their inputs are
SIMD registers, and adapt client code accordingly; this
prevents some bugs since float registers do not compare equal
if they are not of the same type
- make moveSimd128{Int,Float} no longer emit a move if the source and
destination are the same register
Differential Revision: https://phabricator.services.mozilla.com/D93630
When synthesizing constants we should be interested in type classes
(int vs float) and bit patterns in those classes, not specific tags --
a zero is a zero regardless of whether it is i8x16 or i32x4.
Thus the operator == on SimdConstant that takes type tags into account
is the wrong primitive to find out is a constant is synthesizable,
indeed, it is the wrong primitive in almost every case. So get rid of
it, replace it with more suitable primitives, and use those
everywhere.
Add test cases that test that we are emitting the right instructions
for constants that are easy to synthesize.
Differential Revision: https://phabricator.services.mozilla.com/D94002
Swap operands and/or change the operation of SIMD compares during
lowering to generate better code. Introduce test cases for the
generated code.
The tests are a little brittle, but how else would we test this? And
if the register allocator can't be counted on not to insert spurious
moves when presented with an optimal scenario, what can it be counted
on to do?
Drive-by fixes:
- Introduce an xor-with-constant abstraction (useful here and later)
- Clean up some comments
- Remove a small masm abstraction that did not pay for itself.
Differential Revision: https://phabricator.services.mozilla.com/D93720
Currently we require taking a lock when we make the check that traced atoms are
marked in the atoms marking bitmap. This causes problems if we already hold
another mutex with a lower mutex order - e.g. the helper thread lock.
This fix is to skip this check if we hold this mutex. In future (when the
stencil work lands) we may not need to take the atoms lock and we can remove
this check.
One complication was the logic in Mutex::ownedByCurrentThread which had a race
between checking whther the owning thread ID (defined as a Maybe<ThreadId>) had
a value and if so whether the value was that of the current thread. If the
mutext is held by another thread and then released we can attempt to get the
value when the Maybe is nothing, causing an assertion failure. The ThreadId
type already has a null value however so we can use that without wrapping it in
a Maybe.
Differential Revision: https://phabricator.services.mozilla.com/D91895
Update the SetLine / ColSpan source-notes to be relative to the script's
initial line and column number. This allows for more bytecode sharing.
Differential Revision: https://phabricator.services.mozilla.com/D94116
Update the SetLine / ColSpan source-notes to be relative to the script's
initial line and column number. This allows for more bytecode sharing.
Differential Revision: https://phabricator.services.mozilla.com/D94116
These files were omitted from the original patch because reformatting them required some manual intervention in order to avoid breaking unit tests. Generally the `noqa` lines were already there and just needed to be moved from one line to another (due to the reformatting by `black`), but sometimes `black` saw fit to move a bunch of stuff all onto one line, requiring me to introduce new `noqa` lines.
Besides the autoformat by `black` and some manual fixups, this patch contains no other changes.
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94052
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Update the SetLine / ColSpan source-notes to be relative to the script's
initial line and column number. This allows for more bytecode sharing.
Differential Revision: https://phabricator.services.mozilla.com/D94116
For more consistent locations when generating JS field initializer lambdas,
set the lambda's location as the property name. This ensures that source
notes are inside the function body. When we are generating the initializer
code for simple fields without initializers, the Parser pos() points to the
field name, so including the name in the lambda's SourceExtent ensures the
generated source locations are within the body.
Differential Revision: https://phabricator.services.mozilla.com/D94528
When a script is terminated uncatchably (typically by an interrupt or the
debugger), we get error returns with no exception pending.
Differential Revision: https://phabricator.services.mozilla.com/D94374
Constant fold all strings in MGuardStringToInt32 and MGuardStringToDouble, as
long as we don't need to call into `js_strtod_harder`. `js_strtod_harder`
requires to have a `DtoaState` and because we don't have a `DtoaState` at hand
during constant folding and because we probably don't want to create it for
each and every MGuardStringToInt32 and MGuardStringToDouble node, we don't yet
support constant folding strings with fractional numbers.
Depends on D94302
Differential Revision: https://phabricator.services.mozilla.com/D94303
Split some number parsing functions in preparation for the next part:
`js::GetPrefixInteger()`:
- `JSContext*` is only needed when calling `ComputeAccurateDecimalInteger()`,
so split that call out of `GetPrefixInteger()`, so we can call
`GetPrefixInteger()` from the compiler without a `JSContext*`.
`js::CharsToNumber()`:
- Split `CharToNumber()` and `CharsToNonDecimalNumber()` from `js::CharsToNumber()`,
so we can reuse both functions in the next part more easily.
- Also rename `bp` to `start` to be more consistent with the rest of "jsnum.cpp".
Depends on D94301
Differential Revision: https://phabricator.services.mozilla.com/D94302
`num_parseInt` is no longer accessed outside of "jsnum.cpp", so we might as
well change it to `static`.
Depends on D94300
Differential Revision: https://phabricator.services.mozilla.com/D94301
Using only "Pure" as the suffix is more common throughout the code base than
"HelperPure", so remove "Helper" from `{Int32,Number}ToStringHelperPure`.
Depends on D94299
Differential Revision: https://phabricator.services.mozilla.com/D94300
Use explicit template instantiations instead of using the indirection through
`CharsToNumberImpl`. That way `CharsToNumber` works more similar to the other
parsing functions from this file.
Differential Revision: https://phabricator.services.mozilla.com/D94299
This is only the basic outline.
It doesn't do anything yet, but compile.
As there are no metrics generated for it it can't look up anything.
To note: Actual metric types are implemented in XPIDL later.
The following (priviliged) JavaScript code will soon work (if the
corresponding metrics would be defined):
const { Glean } = ChromeUtils.import("resource://gre/modules/Glean.jsm");
Glean.shared.test_only.count_things.add(1);
Differential Revision: https://phabricator.services.mozilla.com/D92211
Remove the 'Experimental' suffix on the opcodes, and the guard for
experimental SIMD opcodes. Move the test case from experimental.js to
ad-hack.js and use the standard text format for it.
Differential Revision: https://phabricator.services.mozilla.com/D94075
These files were omitted from the original patch because reformatting them required some manual intervention in order to avoid breaking unit tests. Generally the `noqa` lines were already there and just needed to be moved from one line to another (due to the reformatting by `black`), but sometimes `black` saw fit to move a bunch of stuff all onto one line, requiring me to introduce new `noqa` lines.
Besides the autoformat by `black` and some manual fixups, this patch contains no other changes.
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94052
Ricky Stewart
Mihai Alexandru Michis
Ted Campbell
Lars T Hansen
Jon Coppeard
Steve Fink
Bogdan Tara
Iain Ireland
Caroline Cullen
Noemi Erli
Jason Orendorff
Gijs Kruitbosch
André Bargull
Jan-Erik Rediger
Dorel Luca