`mozExtensions` is now only used for the `patternOption` property, because
`dateStyle` and `timeStyle` are no longer custom extensions. So instead of
testing for `mozExtensions`, we can simply only test if `patternOptions` is
present.
And update `Intl_DateTimeFormat_resolvedOptions` to only set the "hour12"
and "hourCycle" options when `timeStyle` is used.
Differential Revision: https://phabricator.services.mozilla.com/D73894
In baseline we can't really optimize the typed variant because we have to return boxed values anyway.
(Ion does not use Call ICs so MOZ_CRASH for now at least)
We ensure that the slot argument is constant by checking in the BytecodeEmitter
Differential Revision: https://phabricator.services.mozilla.com/D78949
Previously there was a quirk of nursery size rounding where requesting a nursery size of just less than a chunk resulted in a smaller size than a chunk being used even if one chunk was the nearest valid size.
This was to avoid having a sub-chunk size greater than the amount of usable space in a chunk, but that is not possible anyway as long as the sub-chunk step is greater than the chunk trailer size.
The patch simplifies the rounding code and updates the test code to add a size that will give different results depending on chunk size. I had to add a gcparam to get the chunk size to make this work.
Differential Revision: https://phabricator.services.mozilla.com/D79148
CLDR provides date-time patterns, not skeletons, for date/time-styles, so
when either `hour12` or `hourCycle` is present, we need to adjust the returned
pattern to use the correct hour symbol.
Drive-by change:
- Move `replaceHourRepresentation` for standard options to C++.
- Change `resolveDateTimeFormatInternals` to no longer change the hour
symbol when the non-standard `patternOption` is used.
Differential Revision: https://phabricator.services.mozilla.com/D73896
`mozExtensions` is now only used for the `patternOption` property, because
`dateStyle` and `timeStyle` are no longer custom extensions. So instead of
testing for `mozExtensions`, we can simply only test if `patternOptions` is
present.
And update `Intl_DateTimeFormat_resolvedOptions` to only set the "hour12"
and "hourCycle" options when `timeStyle` is used.
Differential Revision: https://phabricator.services.mozilla.com/D73894
In-tree users of `Math.pow` show that the function is often called with the base operand equal to
two. This case can easily be optimised to a series of shift-instructions for any power of two. For
now this optimisation is only taken for 2^i with i in {1..8} to avoid generating too many
consecutive shift-instructions. 2^8 = 256 was chosen as the limit, because it is the maximum power
of two base operand for `Math.pow` used in-tree.
Differential Revision: https://phabricator.services.mozilla.com/D37587
Similar to `LIRGeneratorX86Shared::lowerForALU`, try to use the same register when multiplying an
operand with itself.
This change improves the generated assembly for `Math.pow(x, 2)` from:
```
# instruction MoveGroup
movl %eax, %ecx
# instruction MulI
imull %ecx, %eax
jo .Lfrom0000
```
to:
```
# instruction MulI
imull %eax, %eax
jo .Lfrom0000
```
Differential Revision: https://phabricator.services.mozilla.com/D37586
That way the trailing DoubleToInt32 doesn't emit the negative zero check sequence:
```
movq %xmm0, %rax
cmpq $0x1, %rax
jo .Lfrom0000
```
When MPow is used with a constant power which can be folded to MMul, this change
will lead to better codegen, too. For example `Math.pow(x, 2)` where `x` is an
Int32 value, currently generates the following assembly:
```
# instruction MoveGroup
movl %eax, %ecx
# instruction MulI:CanBeNegativeZero
imull %ecx, %eax
jo .Lfrom0000
testl %eax, %eax
je .Lfrom0000
```
With this patch, this assembly will be generated:
```
# instruction MoveGroup
movl %eax, %ecx
# instruction MulI
imull %ecx, %eax
jo .Lfrom0000
```
Differential Revision: https://phabricator.services.mozilla.com/D37584
When the SIMD code landed, all aligned loads/stores (except constant loads)
were changed to be unaligned, so as to not have to worry about aligning
SIMD parameters and locals. But I forgot to remove this assert.
Differential Revision: https://phabricator.services.mozilla.com/D79036
In-tree users of `Math.pow` show that the function is often called with the base operand equal to
two. This case can easily be optimised to a series of shift-instructions for any power of two. For
now this optimisation is only taken for 2^i with i in {1..8} to avoid generating too many
consecutive shift-instructions. 2^8 = 256 was chosen as the limit, because it is the maximum power
of two base operand for `Math.pow` used in-tree.
Differential Revision: https://phabricator.services.mozilla.com/D37587
Similar to `LIRGeneratorX86Shared::lowerForALU`, try to use the same register when multiplying an
operand with itself.
This change improves the generated assembly for `Math.pow(x, 2)` from:
```
# instruction MoveGroup
movl %eax, %ecx
# instruction MulI
imull %ecx, %eax
jo .Lfrom0000
```
to:
```
# instruction MulI
imull %eax, %eax
jo .Lfrom0000
```
Differential Revision: https://phabricator.services.mozilla.com/D37586
That way the trailing DoubleToInt32 doesn't emit the negative zero check sequence:
```
movq %xmm0, %rax
cmpq $0x1, %rax
jo .Lfrom0000
```
When MPow is used with a constant power which can be folded to MMul, this change
will lead to better codegen, too. For example `Math.pow(x, 2)` where `x` is an
Int32 value, currently generates the following assembly:
```
# instruction MoveGroup
movl %eax, %ecx
# instruction MulI:CanBeNegativeZero
imull %ecx, %eax
jo .Lfrom0000
testl %eax, %eax
je .Lfrom0000
```
With this patch, this assembly will be generated:
```
# instruction MoveGroup
movl %eax, %ecx
# instruction MulI
imull %ecx, %eax
jo .Lfrom0000
```
Differential Revision: https://phabricator.services.mozilla.com/D37584
Introduce an IS_BLINTERP_FRAME flag to ProfilingStackFrame to distinguish C++
and Baseline interpreter frames. In the profile data this sets the
"implementation" to "blinterp".
Differential Revision: https://phabricator.services.mozilla.com/D78725
Round the number of reserved flag bits up to 16. This leaves 16-bits for the
category (so 64k subcategories). Also make the baseprofiler consistent.
Differential Revision: https://phabricator.services.mozilla.com/D78724
This renames the pref to remove 'experimental' and turns it on by default.
For integration with the CC, any DOM objects that are the target of a WeakRef or registered with a FinalizationRegistry have their wrappers preserved. WeakRef.deref() checks whether any wrapper is still preserved and returns undefined if not, to avoid giving out references to wrappers whose DOM object has been cycle collected.
Tests exercising browser integration are under js/xpconnect/tests/mochitest/.
Differential Revision: https://phabricator.services.mozilla.com/D77656
Move call_indirect's signature check after pushing the frame. We are going to start to implement trampolines as inline code in call_indirect and so, we will push frame and only then tail call to one of the function entries.
Differential Revision: https://phabricator.services.mozilla.com/D75924
Move call_indirect's signature check after pushing the frame. We are going to start to implement trampolines as inline code in call_indirect and so, we will push frame and only then tail call to one of the function entries.
Differential Revision: https://phabricator.services.mozilla.com/D75924
Emscripten will generate eg f32.const + f32x4.splat instead of
f32x4.const when the same value is used for all lanes, presumably
because this is more compact bytecode. Fold the MIR node to recover
the constant, for all types.
Differential Revision: https://phabricator.services.mozilla.com/D78646
Emscripten will generate eg f32.const + f32x4.splat instead of
f32x4.const when the same value is used for all lanes, presumably
because this is more compact bytecode. Fold the MIR node to recover
the constant, for all types.
Differential Revision: https://phabricator.services.mozilla.com/D78646
Implements the 6 eager methods onto %Iterator.prototype%:
`reduce`, `toArray`, `forEach`, `some`, `every`, and `find`,
as well as adding corresponding unit tests.
Differential Revision: https://phabricator.services.mozilla.com/D78080
Sweeping finalization records can push marking working in zones that are still marking, so we may need to drain the mark stack again after this happens.
Differential Revision: https://phabricator.services.mozilla.com/D78662
Nursery reszing has got pretty complicted. This simplifies things by factoring out the ideal size calculation and then clamping the result to the allowed size range.
Differential Revision: https://phabricator.services.mozilla.com/D78502
This has the side effect that gcparam() will report the values that are actually in use rather than the value that are set, which seems like a good thing. I had to update test code expectations due to this.
Differential Revision: https://phabricator.services.mozilla.com/D78500
This caused problems elsewhere due to limited resolution of 'float'. double is the default type for floating point values in C++ and we should use it everywhere unless there is a compelling reason not.
Differential Revision: https://phabricator.services.mozilla.com/D78497
A couple of notes:
1. In the previous patch in this stack, I significantly reduced the default size of handleArena and uniquePtrArena (from 4K each down to 128 bytes). We are using SegmentedVector because we need to grow without moving the contents, not because we expect to grow frequently.
2. I'm reporting the owned memory of the RegExpStack if it has any, but the owned memory is pretty transient. RegExp execution is wrapped in a RegExpStackScope, which should free the owned memory when we're done executing. (That might not always be the case when executing RegExps directly from jitcode, though.)
Differential Revision: https://phabricator.services.mozilla.com/D78521
By default, SegmentedVector allocated in segments of 4096 bytes. That's incredible overkill for the arenas in Isolate that store roots and pseudo-roots, because the only place in irregexp where we allocate more than a small constant number of roots is named captures, where we allocate one string per name. Shrinking these down to 128 bytes instead of 4096 still leaves room for 20+ names without allocating another segment.
While testing this change, I noticed that we had a memory leak. When we allocate named capture information in the parser, we don't have a HandleScope on the stack, so we root the handles in the implicit global handlescope. That scope isn't cleared out during the lifetime of the Isolate. I moved the HandleScope in CompilePattern up to enclose the parser, and added assertions in DestroyIsolate to verify that there aren't any other leaks.
Differential Revision: https://phabricator.services.mozilla.com/D78520
Fix recent regression when standalone functions started being allocated by
instantiateStencils. This adds an `isStandalone` flag to the function box
that we can check in addition to `wasEmitted` (which is not set for these
standalone functions). Also remove some dead code.
Differential Revision: https://phabricator.services.mozilla.com/D78604
Nursery reszing has got pretty complicted. This simplifies things by factoring out the ideal size calculation and then clamping the result to the allowed size range.
Differential Revision: https://phabricator.services.mozilla.com/D78502
This has the side effect that gcparam() will report the values that are actually in use rather than the value that are set, which seems like a good thing. I had to update test code expectations due to this.
Differential Revision: https://phabricator.services.mozilla.com/D78500
This caused problems elsewhere due to limited resolution of 'float'. double is the default type for floating point values in C++ and we should use it everywhere unless there is a compelling reason not.
Differential Revision: https://phabricator.services.mozilla.com/D78497
Move call_indirect's signature check after pushing the frame. We are going to start to implement trampolines as inline code in call_indirect and so, we will push frame and only then tail call to one of the function entries.
Differential Revision: https://phabricator.services.mozilla.com/D75924
For general background see the bug's description. This patch
implements the iNxM.bitmask instructions for x86+x64 in baseline+ion,
and adds some simple test cases.
Differential Revision: https://phabricator.services.mozilla.com/D77784
This is mostly code removal: we remove the platform-specific lowering
and code generation for scalarized i64x2.mul. In its place we use
Andrew Brown's code for a platform-agnostic SIMD implementation, this
fits in very neatly in the existing code generation pipeline.
Differential Revision: https://phabricator.services.mozilla.com/D78015
Move call_indirect's signature check after pushing the frame. We are going to start to implement trampolines as inline code in call_indirect and so, we will push frame and only then tail call to one of the function entries.
Differential Revision: https://phabricator.services.mozilla.com/D75924
This is equivalent to `regexp/non-unicode-case-folding.js`, but checking back-references instead of simple matches / character classes.
Note: this testcase is similar to the testcase I landed upstream, but not identical. The upstream testcase verifies that the characters in each equivalence class match if the regexp is `/iu`. It turns out that there is a very small set of characters ('\ufb05' and `\ufb06`; '\u0390' and '\u1fd3'; '\u03b0' and '\u1fe3') where both characters have a full (aka multi-character) case-folding to the same value, but don't have a simple case-folding. As the spec is written, these characters should *not* match each other, even with `/iu`.
I opened a V8 bug for this issue: https://bugs.chromium.org/p/v8/issues/detail?id=10591
Depends on D78559
Differential Revision: https://phabricator.services.mozilla.com/D78560
This patch uses the unicode flag to decide which helper function to call for two-byte ignoreCase non-unicode backreferences.
It also fixes the (previously unused) helper to do the right thing. Compare RegExpMacroAssembler::CaseInsensitiveCompareNonUnicode in `irregexp/imported/regexp-macro-assembler.cc`, from the previous patch.
RegExpCaseFolding is only defined when we build with ICU. The differences here only occur in corner cases, so in non-intl builds, CaseInsensitiveCompareNonUnicode can do the same thing as CaseInsensitiveCompareUnicode.
Differential Revision: https://phabricator.services.mozilla.com/D78559
WeakRef targets that are wrappers to DOM objects are preserved when the WeakRef is created. This checks whether the wrapper is still preserved in deref() and if it is found to have been released, the target is cleared.
The patch adds a new DOMJSClass hook to deal with getting the wrapper cache for non-nsISupports objects.
Differential Revision: https://phabricator.services.mozilla.com/D78061
Also add `JS::WasmModule::createObjectForAsmJS` which is similar to
`createObject` but does not set the WasmModule prototype. Also mark these
methods as const so they work with the `SharedModule` definition.
Differential Revision: https://phabricator.services.mozilla.com/D78088
Use InitialFunctionFlags to compute flags consistently. That requires
plumbing FunctionSyntaxKind in for the standalone-function case. Preserve the
existing expression-vs-statement decisions. We move the InitialFunctionFlags
definition earlier in file but it is unchanged.
Stop allocating a function before parsing and rely on the frontend to do that
for us. This gives more consistent behaviour with asm.js and inner functions.
We need to explicitly call initEnvironment function now since the Stencil
instantiation code does not do it for us, while NewScriptedFunction did.
Differential Revision: https://phabricator.services.mozilla.com/D78087
A couple of notes:
1. In the previous patch in this stack, I significantly reduced the default size of handleArena and uniquePtrArena (from 4K each down to 128 bytes). We are using SegmentedVector because we need to grow without moving the contents, not because we expect to grow frequently.
2. I'm reporting the owned memory of the RegExpStack if it has any, but the owned memory is pretty transient. RegExp execution is wrapped in a RegExpStackScope, which should free the owned memory when we're done executing. (That might not always be the case when executing RegExps directly from jitcode, though.)
Differential Revision: https://phabricator.services.mozilla.com/D78521
By default, SegmentedVector allocated in segments of 4096 bytes. That's incredible overkill for the arenas in Isolate that store roots and pseudo-roots, because the only place in irregexp where we allocate more than a small constant number of roots is named captures, where we allocate one string per name. Shrinking these down to 128 bytes instead of 4096 still leaves room for 20+ names without allocating another segment.
While testing this change, I noticed that we had a memory leak. When we allocate named capture information in the parser, we don't have a HandleScope on the stack, so we root the handles in the implicit global handlescope. That scope isn't cleared out during the lifetime of the Isolate. I moved the HandleScope in CompilePattern up to enclose the parser, and added assertions in DestroyIsolate to verify that there aren't any other leaks.
Differential Revision: https://phabricator.services.mozilla.com/D78520
The lack of specificity for script intro type has lead the debugger to need
to make use of 'source.introductionType' and 'source.element' in order to
determine whether a given script was injected, or inline or fetched, which
is entirely unnecessary of the loader itself clearly tells us what type
of script we are working with. It also allows us to cleanly handle the case
of XUL, which previously was "scriptElement" but has no ".element" passed
in, so we were unable to know whether a given source was inline or not.
Differential Revision: https://phabricator.services.mozilla.com/D78435
The fickle, ever-changing whims of unified builds shuffled code around enough that the place where we are printing this value inlined this function and complained about the unique_ptr being null. We continue to not care about this output, so instead of messing around with copying the characters we just return an empty string.
Differential Revision: https://phabricator.services.mozilla.com/D78548
RegExpNativeMacroAssembler.cpp has a list of `using js::jit::X` statements to keep the code readable. Depending on the config options and the whims of the unified build, `using js::jit::Address` can appear in imported V8 files where we actually want `v8::Address`.
The easy fix is to build RegExpNativeMacroAssembler separately.
Differential Revision: https://phabricator.services.mozilla.com/D78519
RegExpNativeMacroAssembler.cpp has a list of `using js::jit::X` statements to keep the code readable. Depending on the config options and the whims of the unified build, `using js::jit::Address` can appear in imported V8 files where we actually want `v8::Address`.
The easy fix is to build RegExpNativeMacroAssembler separately.
Differential Revision: https://phabricator.services.mozilla.com/D78519
The previous code was using a fixed result register, because bug 774364 was
using an OOL-path for `Math.random`, which was later removed in bug 322529.
Differential Revision: https://phabricator.services.mozilla.com/D77836
WarpOracle was aborting on the JSOp::Exception. It's hard to (efficiently) skip
catch-blocks in WarpOracle too so this patch just adds it to the supported ops
and crashes in WarpBuilder since it's unreachable there.
This uncovered a few more test failures where we relied on specific exception messages.
Differential Revision: https://phabricator.services.mozilla.com/D78259
Doesn't rename the MToId instruction because the next patch will make changes to
that anyway.
The comment in Interpreter.cpp was removed because this op is already (and better)
documented in vm/Opcodes.h
Differential Revision: https://phabricator.services.mozilla.com/D78039
This patch generalizes the x64 code that was moved into x86-shared
code in the previous patch, and makes it all work for x86.
Generally the changes are pedestrian. The most interesting bit is
that signed right shift i64x2 is now scalarized in the compilers, not
in the macroassemblers, as this simplifies code everywhere. This
gives rise to a new kind of porting API that reveals information about
what the macroassembler supports on the platform, in the form of the
MustScalarize/MustMaskShiftCount predicates in MacroAssembler.h.
Multiply i64x2, which is scalarized in the macroassemblers now, could
have been subjected to the same treatment, but I did not do so (yet)
because this op presented fewer problems than the right shift. (Discuss.)
Differential Revision: https://phabricator.services.mozilla.com/D74935
This patch only moves code from x64 to x86-shared.
There are no functional or indeed any other adjustments. This patch
does not lead to code that will compile, it only makes review of the
substantive changes easier. It must be landed together with the next
patch.
Differential Revision: https://phabricator.services.mozilla.com/D77237
I've been thinking about doing this for a while, and finally got around to doing it.
This patch moves the files that are directly imported from V8 into their own subdirectory of `irregexp`, to make it more obvious which code is part of V8 and which code is part of the shim. I also took the opportunity to rename the shim files to follow our naming conventions (FileName.cpp) instead of V8's (file-name.cc).
Most of this code is mechanical. The mildly interesting parts are:
1. In `import-irregexp.py`, when figuring out where the regexp shim include should go, we no longer have to work quite as hard to alphabetize it, because `irregexp/RegExpShim.h` will always come after `irregexp/imported/*`. Instead, we just keep scanning until we find a newline.
2. Some of the V8 code #includes "regexp-macro-assembler-arch.h". Up until now, that's the name we used for the header file for our RegExpMacroAssembler implementation. Now that the implementation lives in a separate directory from the V8 code, I've renamed the header to `RegExpNativeMacroAssembler.h` (to match the .cpp file), and added a stub `regexp-macro-assembler-arch.h` header in `imported` that #includes the real thing.
In the next patch, we take advantage of the new directory structure to get more precise with clang-format-ignore.
Depends on D77730
Differential Revision: https://phabricator.services.mozilla.com/D77731
This is the only place where any code outside the `irregexp` directory directly includes a V8 header. Tidying it up makes the next patch easier.
Depends on D77729
Differential Revision: https://phabricator.services.mozilla.com/D77730
It's not `new-` any more.
This patch moves the files, replaces `new-regexp` with `irregexp` throughout the code, re-alphabetizes `#include`s, and adds a few missing `#include`s to `RegExpTypes.h` and `util/vector.h` that were exposed by the reordering.
Depends on D77728
Differential Revision: https://phabricator.services.mozilla.com/D77729
I kept a running list of code that would be dead once we removed the old engine. This is what was on that list.
Note: The regexp_parse tests used a testing function that parsed a regexp and returned an AST to compare against the expected AST. They are being deleted because the tests are fragile in the face of upstream changes, not particularly useful, and a lot of work to convert.
Depends on D77727
Differential Revision: https://phabricator.services.mozilla.com/D77728
I wrote this testcase while trying to figure out the spec for named captures, and discovered that V8 was not handling it properly. Our implementation does the right thing here, so I'm landing this testcase to make sure it stays that way.
Depends on D77725
Differential Revision: https://phabricator.services.mozilla.com/D77726
I wrote this testcase while fixing an issue with upstream V8's handling of non-unicode ignoreCase RegExps. (See here: 3fab9d05cf)
I'm finally getting around to landing it.
(There will be another patch in the future to fix an equivalent issue with back-references, but it's waiting on upstream review.)
Differential Revision: https://phabricator.services.mozilla.com/D77725
Drive-by performance improvement. convertUInt64ToDouble is slower because it has
a different code path for negative inputs but that can't happen here.
Differential Revision: https://phabricator.services.mozilla.com/D77803
Note that the math-random.js jit-test is a good correctness test for this. It
overrides the RNG's seed, generates a few thousand numbers, and then checks some
of them. I verified this test fails if I add a bug to the Math.random JIT code.
Differential Revision: https://phabricator.services.mozilla.com/D77801
Remove the specialization_ field and the powerType use. Use the return type instead.
For now we only use the Double specialization, although this already adds the
TypePolicy code for Int32 specialization.
Differential Revision: https://phabricator.services.mozilla.com/D77777
Currently, MOZ_ALIGNED_DECL uses the order (_type, _align) for its
parameters. However, this order makes the code less readable when
_type is a larger object like a struct because the value for _align
would be at the end of the struct definition. By swapping the order
of _type and _align, the alignment value will always be next to
the type name, regardless how far the definition of _type extends.
Differential Revision: https://phabricator.services.mozilla.com/D77288
This is strictly a quality of life improvement when cross-compiling to
Windows targets. A common scenario is mounting an object directory
into a Windows VM, which requires additional VM configuration to
handle (absolute) symlinks. With this patch, `export NSDISTMODE=copy`
in a mozconfig sidesteps any such symlink issues.
Differential Revision: https://phabricator.services.mozilla.com/D77118
André Bargull
Matthew Gaudet
Tooru Fujisawa
Tom Schuster
Mihai Alexandru Michis
Jon Coppeard
Adam Vandolder
Jan de Mooij
Lars T Hansen
Jeff Walden
Zhao Jiazhong
Noemi Erli
yulia
Razvan Maries
Andrew McCreight
Ted Campbell
Dmitry Bezhetskov
Iain Ireland
Bogdan Tara
Masatoshi Kimura
Logan Smyth
caroline
Yoshi Cheng-Hao Huang
Narcis Beleuzu
Kannan Vijayan
Steve Fink
John Paul Adrian Glaubitz
Coroiu Cristina
Nick Alexander