Use the FatalProcessOutOfMemory function such that tooling recognizes
these crashes as OOM's.
Drive-by: Skip one more test that leads to such stack overflows.
Fixed: v8:12555, chromium:1288456
Bug: v8:12472
Change-Id: Ib9203a4aa0487744f7cea9a212aeeffda579ae23
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401861
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78692}
super.property accesses in heritage positions like `class C extends
super.property` should resolve super in the current scope, not C's
class scope.
Bug: chromium:1282096
Change-Id: I7ef815bc02cfff35a2898ef9f39b133d1114046c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3400150
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78687}
Apply case-insensitive comparisons not only for the initial character,
but for the entire prefix. This avoids degenerate behavior for patterns
like /aaaa|AAAA|AAAA/i (i.e. generate a single 4-char prefix instead of
four 1-char prefixes).
Bug: v8:12472
Change-Id: Ib2b49fe73ca846a1b7ec90056cc64bdf5cf33026
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3398114
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78668}
Recursive ToNode node generation may overflow the stack for large
graphs. As a quick fix, insert periodic stack overflow checks in
selected ToNode methods.
As a more permanent fix, in the future we could abort gracefully
(instead of crashing on a CHECK), and/or refactor into iterative node
generation.
Bug: v8:12472
Change-Id: Ie5fbe838c5f6a5192d7d9b44bfe6f6c76a8d26e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3398112
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78667}
This reverts commit bd72152e7d.
Reason for revert: TSAN reports a data race, please see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/18124/overview
Original change's description:
> [fastcall] Add Wasm entry for Fast API calls
>
> Allow Wasm to generate calls directly to Fast API C functions.
> This massively reduces the overhead of these calls (~300%).
> Currently options parameter is not supported.
>
> This is a rebase of the work originally done by devsnek in:
> https://chromium-review.googlesource.com/c/v8/v8/+/2718666.
>
> Bug: chromium:1052746
> Change-Id: I1bb1de68b440044cc8a4e528adf9d8e0e6692a07
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364356
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#78664}
Bug: chromium:1052746
Change-Id: I957708cf1cff6ee8f90678ee48428f5c12f75a53
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3398121
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Owners-Override: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#78665}
Allow Wasm to generate calls directly to Fast API C functions.
This massively reduces the overhead of these calls (~300%).
Currently options parameter is not supported.
This is a rebase of the work originally done by devsnek in:
https://chromium-review.googlesource.com/c/v8/v8/+/2718666.
Bug: chromium:1052746
Change-Id: I1bb1de68b440044cc8a4e528adf9d8e0e6692a07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364356
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#78664}
Previously, StoreOwnIC incorrectly reuses the [[Set]] semantics
when initializing public literal class fields and object literals in
certain cases (e.g. when there's no feedback).
This was less of an issue for object literals, but with public class
fields it's possible to define property attributes while the
instance is still being initialized, or to encounter existing static
"name" or "length" properties that should be readonly. This patch
fixes it by
1) Emitting code that calls into the slow stub when
handling StoreOwnIC with existing read-only properties.
2) Adding extra steps in StoreIC::Store to handle such stores
properly with [[DefineOwnProperty]] semantics.
Bug: v8:12421, v8:9888
Change-Id: I6547320a1caba58c66ee1043cd3183a2de7cefef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300092
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#78659}
Now that concurrent inlining is shipping on stable, remove support
--no-concurrent-inlining.
Note that it's still possible to run Turbofan exclusively on the
main thread by passing --no-concurrent-recompilation.
Bug: v8:7790, v8:12142, chromium:1240585
Change-Id: I1943bbbcad7dea7e3a3c337c239f14f7d96c23cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3308798
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78644}
The fast path has an early return if the two inputs are the same
object. However, this was missing the check that the receiver
is not undefined required by the spec.
This fixes it by first checking that the receiver is a string and
only afterwards checking for reference equality.
Bug: v8:12495
Change-Id: I4c5fc80e09060b013c94b05bbc9da504ddbb5206
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386602
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78637}
Shell::FetchModuleTree assumes that the module at file_name wasn't
already fetched. Shell::ExecuteModule is calling into
FetchModuleTree without checking if the module is already in the module
map, violating this assumption.
This change fixes this by having Shell::ExecuteModule check for the
existence of the module before calling into Shell::ExecuteModule, the
same way that Shell::DoHostImportModuleDynamically does.
Bug: v8:12530
Change-Id: Ia038cbd1715e85c9c92c4554fd486c657ef952e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3388130
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78636}
Similar to the case of fixed registers, we need to consider both cases:
A SIMD register might collide with either the low or high FP register,
or the FP register might collide with a previously allocated SIMD
register. We did only consider the first case so far.
R=thibaudm@chromium.org
Bug: chromium:1286253, v8:12330
Change-Id: Id4c995586cc8b97a2e131ee9d3417525e409bcef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380597
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78633}
When FLAG_shared_string_table is true, postMessaging strings will share
instead of copy.
Note that not all operations on shared strings are supported, and shared
strings may be slower than non-shared strings for some operations.
Bug: v8:12007
Change-Id: I3462128e15410d2568868143571571b3025722c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277250
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78614}
It is possible for KeyedDefineOwnICKind to go into
ElementsTransitionAndStoreIC_Miss when a computed field key
is a valid index and the lazy feedback allocation is disabled.
Bug: chromium:1277863
Change-Id: If8a81384257647426607495b6e3d8f235913e8f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322634
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#78573}
We introduce a type arrayref, which is a supertype of all array types
and a subtype of dataref. We change array.len to accept values of type
(ref null array).
Drive-by: Fix kEq/kData case in TypecheckJSObject.
Bug: v8:7748
Change-Id: I47c6a4487ddf5e7280c1427f43abe87a97c896bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3368105
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78565}
The original CL introduced a test that does not work when it is executed
concurrently on multiple isolates. This CL skips this test
configuration.
Original change's description:
> [wasm] Lazy compilation after deserialization
>
> The serialization format contains one boolean flag per function which
> specifies whether the function code exists in the serialized module or
> not. With this CL, this boolean flag is extended to a three-value flag
> which indicates whether the function exists, and if not, whether the
> function was executed before serialization. This information can then be
> used upon deserialization to compile only those functions that were
> executed before serialization.
>
> Design doc: https://docs.google.com/document/d/1U3uqq4njqLqFhr1G2sU_bmpQxY-3bvfG55udSb-DvA4/edit?usp=sharing
>
> Bug: v8:12281
Change-Id: I36ce90b37736172aa01c47ab04e154ec8ea2d8aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380590
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78564}
- Add Suspender.suspendOnReturnedPromise method
- Extend the WasmApiFunctionRef data with the suspender
- Detect wrapped WasmJSFunctions when we resolve the import
For now the generated wrapper is still a regular wasm-to-js wrapper, but
this sets the ground for generating specific wrappers for functions
wrapped by suspendOnReturnedPromise, and to access the suspender from
the wrapper code.
R=ahaas@chromium.org
CC=fgm@chromium.org
Bug: v8:12191
Change-Id: I81cbec6b023507e47e6e1463b5f9b912f807da6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3345000
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78560}
This reverts commit fbcdb28178.
Reason for revert: New test fails for multiple (concurrent) isolates: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux/45152/overview
Original change's description:
> [wasm] Lazy compilation after deserialization
>
> The serialization format contains one boolean flag per function which
> specifies whether the function code exists in the serialized module or
> not. With this CL, this boolean flag is extended to a three-value flag
> which indicates whether the function exists, and if not, whether the
> function was executed before serialization. This information can then be
> used upon deserialization to compile only those functions that were
> executed before serialization.
>
> Design doc: https://docs.google.com/document/d/1U3uqq4njqLqFhr1G2sU_bmpQxY-3bvfG55udSb-DvA4/edit?usp=sharing
>
> Bug: v8:12281
> Change-Id: I465e31e5422fa45163256be0e6594045865f0174
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364089
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78545}
Bug: v8:12281
Change-Id: If0e327d02e8257a4d1cfcf8b82381af11f28e91c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3377126
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#78546}
The serialization format contains one boolean flag per function which
specifies whether the function code exists in the serialized module or
not. With this CL, this boolean flag is extended to a three-value flag
which indicates whether the function exists, and if not, whether the
function was executed before serialization. This information can then be
used upon deserialization to compile only those functions that were
executed before serialization.
Design doc: https://docs.google.com/document/d/1U3uqq4njqLqFhr1G2sU_bmpQxY-3bvfG55udSb-DvA4/edit?usp=sharing
Bug: v8:12281
Change-Id: I465e31e5422fa45163256be0e6594045865f0174
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364089
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78545}
We should only check the "SIMD sibling" register if we are handling a
SIMD register. This avoids unneeded spills, and in this particular case
ran into a DCHECK because there are only 29 registers, but we tried
checking #29.
R=thibaudm@chromium.org
Bug: v8:12330, v8:1285007
Change-Id: Ife8b295ac958990611ca8816bbfbfb5124a4297d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372916
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78532}
The test was added in https://crrev.com/c/3372910, but needs to be
skipped on non-SIMD hardware because it contains SIMD instructions.
R=thibaudm@chromium.org
Bug: v8:12330, chromium:1284980
Change-Id: Ifaede466b24aea4f9ef6b062414a31698bcca864
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372917
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78517}
Spilling was already fixed if a fixed SIMD register overlaps with an
allocated FP register, but the other way around was missing: If an odd
FP register (in this case d1) is used as a fixed output register, but
this register is in use as the upper half of a SIMD register (in this
case q0), we did not detect this and would just use overwrite the SIMD
half.
This CL also fixes this case.
R=thibaudm@chromium.org
Bug: v8:12330, chromium:1284980
Change-Id: Id3f98b7accd77e38ab4cd5ff8910aaf5ad96a1ed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3372910
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78514}
We implement loop peeling for wasm, currently available behind a flag.
Loops are peeled regardless of size.
Bug: v8:11510
Change-Id: Ia4c883abdee83df632b2611584d608c44e3295c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3367615
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78496}
If a fixed register is defined for an input, we did only spill the
sibling SIMD register if the other sibling was allocated. This is not
correct. If only the sibling is in use (e.g. s1 colliding with q0) we
also have to spill that sibling.
R=mslekova@chromium.org
Bug: chromium:1283042, v8:12330
Change-Id: I6a22eaf461774a0b4603ec3ff17062134a528161
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3359615
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78483}
The mid-tier register allocator did not handle block merges correctly
where a SIMD register was partially overlapping with a non-SIMD
register. This CL fixes that, and reorders the code to allow for early
exits.
R=mslekova@chromium.org
Bug: chromium:1282224, v8:12330
Change-Id: I2e9275d5c1aaa764ecb63fbf8fa197b68d6b6c3c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3358294
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78482}
We unify the implementation of element segment expression entries with
other initializer expressions: we represent them with a {WireBytesRef}
and decode them with {InitExprInterface}. Except for reducing code
duplication, this also fixes a bug where {global.get} entries in element
segments could reference invalid globals.
Changes:
- Change {WasmElemSegment::Entry} to a union of a {WireBytesRef}
initializer expression and a {uint32_t} function index.
- In module-decoder, change parsing of expression entries to use
{consume_init_expr}. Add type checking to
{consume_element_func_index}, to complement type checking happening in
{consume_init_expr}.
- In module-instantiate.cc:
- Move instantiation of indirect tables before loading of element
segments. This way, when we call {UpdateDispatchTables} in
{SetTableEntry}, the indirect table for the current table will also
be updated.
- Consolidate table entry instantiation into {SetTableEntry}, which
handles lazily instantiated functions, or dispatches to
{WasmTableObject::Set}.
- Rename {InitializeIndirectFunctionTables} to
{InitializeNonDefaultableTables}.
- Change {InitializeNonDefaultableTables} and {LoadElemSegmentImpl}
to use {EvaluateInitExpression}.
- Add a test to exclude mutable/non-imported globals from the element
section.
- Update tests as needed.
- Update .js module emission in wasm-fuzzer-common.
Change-Id: I29c541bbca8531e8d0312ed95869c8e78a5a0c57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364082
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78476}
This CL splits the TF type for JSFunction into CallableFunction and
ClassConstructor. This differentiation allows us to lower calls to the
CallFunction Builtin only for functions that we can actually call.
Class Constructors are special, as they are callable but should raise
an exception if called.
By not lowering class constructors to calls to CallFunction (but the
more generall Call) builtin, we can remove the checks for class
constructors from CallFunction (in a follow-up CL).
Bug: chromium:1262750
Change-Id: I399967eb03b2f20d2dcb67aef2243b32c9d3174e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3350457
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78445}
Private method loads are compiled to a named load of a private brand,
which always loads a BlockContext. This BlockContext holds the private
methods common to all instances of a class. TurboFan currently considers
JSLoadNamed to be of Type::NonInternal(). Private methods break this
assumption, since BlockContext is of Type::OtherInternal().
This CL changes the typing of JSLoadNamed of private brands to be
Type::OtherInternal().
Bug: v8:12500
Change-Id: I91f39747bf9422bd419d299f44152f567d8be8db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3351167
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78431}
Without simple FP aliasing, a SIMD register will overlap with two
floating-point registers. If we spill an FP register to use it for a
SIMD operation, we need to make sure to also spill the "sibling" FP
register.
R=leszeks@chromium.org
Bug: v8:12330, chromium:1271244
Change-Id: I7fdc6cb8da35d66b4862a8a913ba4ff906cf05aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3347576
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78414}
The mid-tier register allocator could not handle the case that the same
virtual register was used for
- the input corresponding to the 'same-as-input' output, and
- another 'unique register' input.
In this case, it cannot choose the already assigned register for the
'unique' register. Instead, it needs to allocate a new register and
introduce a gap move to duplicate the input value in two different
registers.
FYI, the instruction where the current logic failed was:
(v5(0), v6(R)) = IA32AddPair v7(R) v7(*) v8(R) v7(R)
(where the last input was marked 'unique').
R=leszeks@chromium.orgCC=thibaudm@chromium.org
Bug: v8:12330, chromium:1272204
Change-Id: Ie4843aa9f5e027afe503e0481a4acdfa325dfe0e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3347821
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78411}
A SIMD register can "block" more than one FP register. In that case, no
virtual register will be assigned for one of the FP registers. This is
fine, we just need to detect and handle that case correctly.
R=thibaudm@chromium.org
CC=leszeks@chromium.org
Bug: chromium:1271538, v8:12330
Change-Id: I7ec19229445c5ace0782f63945acb89322816540
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293082
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78400}
We switch the order of inlining and loop unrolling optimizations. This
gives small improvements to wasm-gc benchmarks.
Changes:
- Change the loop analysis algorithm to accept loops directly connected
to the graph's end. This is required because some nodes in an inlined
function, such as tail calls, might be directly connected to the outer
function's end without an intervening LoopExit node.
- Based on the above, skip emitting loop exits for some Throw nodes in
WasmGraphBuildingInterface.
- Introduce WasmInliningPhase, add it before loop unrolling. Remove
inlining from WasmOptimizationPhase.
- Handle graph terminators in loop unrolling.
- Add loops in the inlined function to the callers loop_infos.
Drive-by:
- Allow more wasm builtins in unrolled loops.
- Reduce inlining parameters to reflect that functions are now slightly
smaller during inlining, as no unrolling has taken place yet.
Bug: v8:12166
Change-Id: Iadd6b2f75170aa153ca1efb47fbb0d185c2b8371
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3329783
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78394}
This CL renames a number of things related to the V8 sandbox.
Mainly, what used to be under V8_HEAP_SANDBOX is now under
V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage
is now simply the V8 Sandbox:
V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX
V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS
V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS
V8VirtualMemoryCage => Sandbox
CagedPointer => SandboxedPointer
fake cage => partially reserved sandbox
src/security => src/sandbox
This naming scheme should simplify things: the sandbox is now the large
region of virtual address space inside which V8 mainly operates and
which should be considered untrusted. Mechanisms like sandboxed pointers
are then used to attempt to prevent escapes from the sandbox (i.e.
corruption of memory outside of it). Furthermore, the new naming scheme
avoids the confusion with the various other "cages" in V8, in
particular, the VirtualMemoryCage class, by dropping that name entirely.
Future sandbox features are developed under their own V8_SANDBOX_X flag,
and will, once final, be merged into V8_SANDBOX. Current future features
are sandboxed external pointers (using the external pointer table), and
sandboxed pointers (pointers guaranteed to point into the sandbox, e.g.
because they are encoded as offsets). This CL then also introduces a new
build flag, v8_enable_sandbox_future, which enables all future features.
Bug: v8:10391
Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78384}
An asm-js module has all wasm feature flags disabled, despite the global
flag configuration. Therefore, in WasmExportedFunction::New, we should
retrieve the enabled features from the NativeModule instead of the
flags.
Bug: chromium:1279151
Change-Id: Ic44fe535baa7cb851644457cce533c24d4c9824e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3338256
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78368}
Use build_flags_ with @if/@ifnot in torque for the following flags:
- V8_ENABLE_JAVASCRIPT_PROMISE_HOOKS
- V8_ENABLE_SWISS_NAME_DICTIONARY
- Make sure Torque and CSA code actually respect
V8_ENABLE_JAVASCRIPT_PROMISE_HOOKS.
- Rename V8_ALLOW_JAVASCRIPT_IN_PROMISE_HOOKS to
V8_ENABLE_JAVASCRIPT_PROMISE_HOOKS
- Rename gn/bazel arg v8_allow_javascript_in_promise_hooks to
v8_enable_javascript_promise_hooks
- Unship context promise hooks in chrome and enable them only in d8
for testing purposes
- Make sure d8 and the API throw when using promise hooks without
the compile time feature enabled
Bug: chromium:1265186, v8:11025
Change-Id: I69834d44d683a36d0d7be3c3d68888321be0fd7f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3301474
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78362}
Since the reftypes proposal has shipped, we remove the respective flag
and the code that handled its absence. We maintain a WasmFeature for
reftypes for feature detection purposes. We remove the flag declaration
from tests, and adapt some tests that make no sense without the flag.
Bug: v8:7581
Change-Id: Icf2f8d0feae8f30ec68d5560f1e7ee5959481483
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3329781
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78351}
This is a reland of 863bc2b88a
Diff to original:
- Don't eliminate GC observable stores that were temporarily
unobservable during traversal.
- Skip the previously added test for single-generation
- Add new test
Original change's description:
> [turbofan] Improve StoreStoreElimination
>
> Previously, StoreStoreElimination handled allocations as
> "can observe anything". This is pretty conservative and prohibits
> elimination of repeated double stores to the same field.
> With this CL allocations are changed to "observes initializing or
> transitioning stores".
> This way it is guaranteed that initializing stores to a freshly created
> object or stores that are part of a map transition are not eliminated
> before allocations (that can trigger GC), but allows elimination of
> non-initializing, non-transitioning, unobservable stores in the
> presence of allocations.
>
> Bug: v8:12200
> Change-Id: Ie1419696b9c8cb7c39aecf38d9f08102177b2c0f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295449
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78230}
Bug: v8:12200, chromium:1276923, v8:12477
Change-Id: Ied45ee28ac12b370f7b232d2d338f93e10fea6b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320460
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78349}
With a recent addition to the type reflection proposal, 'anyfunc' gets
renamed to 'funcref'. For backwards compatibility, 'anyfunc' becomes an
alias for 'funcref'. With this CL, the string 'funcref' can be used to
create a funcref table or a funcref global. Additionally, 'funcref' is
returned as the type of imported and exported functions as well as
globals and tables.
R=manoskouk@chromium.org
Change-Id: If3ed4d507de862ebfcabd4eb967bbfaae1c6ccba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300135
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78341}
Design doc: bit.ly/36MfD6Y
We introduce simplified operators LoadImmutableFromObject and
InitializeImmutableInObject. These are lowered to Loads and Stores like
LoadFromObject and StoreToObject.
We split CsaLoadElimination::AbstractState in two HalfStates,
which represent the mutable and immutable component of the state.
Immutable operators in the effect chain modify the immutable half-state,
and plain operators modify the mutable half-state. The immutable part is
maintained through write effects and loop headers. Immutable
initializations do not lookup and kill previous overlapping stores,
assuming each offset cannot be initialized more than once.
Bug: v8:11510
Change-Id: I0f5feca3354fdd3bdc1f511cc5214ec51e1407ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268728
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78325}
This reverts commit 91f08378bc.
Reason for revert: It's a fairly big change, and the clusterfuzz
found some bugs. Will reland with the fix after M98 branch point.
Original change's description:
> [class] implement reparsing of class instance member initializers
>
> Previously, since the source code for the synthetic class instance
> member initializer function was recorded as the span from the first
> initializer to the last initializer, there was no way to reparse the
> class and recompile the initializer function. It was working for
> most use cases because the code for the initializer function was
> generated eagarly and it was usually alive as long as the class was
> alive, so the initializer wouldn't normally be lazily parsed. This
> didn't work, however, when the class was snapshotted with
> v8::SnapshotCreator::FunctionCodeHandling::kClear,
> becuase then we needed to recompile the initializer when the class
> was instantiated. This patch implements the reparsing so that
> these classes can work with FunctionCodeHandling::kClear.
>
> This patch refactors ParserBase::ParseClassLiteral() so that we can
> reuse it for both parsing the class body normally and reparsing it
> to collect initializers. When reparsing the synthetic initializer
> function, we rewind the scanner to the beginning of the class, and
> parse the class body to collect the initializers. During the
> reparsing, field initializers are parsed with the full parser while
> methods of the class are pre-parsed.
>
> A few notable changes:
>
> - Extended the source range of the initializer function to cover the
> entire class so that we can rewind the scanner to parse the class
> body to collect initializers (previously, it starts from the first
> field initializer and ends at the last initializer). This resulted
> some expectation changes in the debugger tests, though the
> initializers remain debuggable.
> - A temporary ClassScope is created during reparsing. After the class
> is reparsed, we use the information from the ScopeInfo to update
> the allocated indices of the variables in the ClassScope.
>
> Bug: v8:10704
> Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Cr-Commit-Position: refs/heads/main@{#78299}
Bug: v8:10704
Change-Id: I039cb728ebf0ada438a8f26c7d2c2547dbe3bf2d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325328
Auto-Submit: Joyee Cheung <joyee@igalia.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78315}
Previously, since the source code for the synthetic class instance
member initializer function was recorded as the span from the first
initializer to the last initializer, there was no way to reparse the
class and recompile the initializer function. It was working for
most use cases because the code for the initializer function was
generated eagarly and it was usually alive as long as the class was
alive, so the initializer wouldn't normally be lazily parsed. This
didn't work, however, when the class was snapshotted with
v8::SnapshotCreator::FunctionCodeHandling::kClear,
becuase then we needed to recompile the initializer when the class
was instantiated. This patch implements the reparsing so that
these classes can work with FunctionCodeHandling::kClear.
This patch refactors ParserBase::ParseClassLiteral() so that we can
reuse it for both parsing the class body normally and reparsing it
to collect initializers. When reparsing the synthetic initializer
function, we rewind the scanner to the beginning of the class, and
parse the class body to collect the initializers. During the
reparsing, field initializers are parsed with the full parser while
methods of the class are pre-parsed.
A few notable changes:
- Extended the source range of the initializer function to cover the
entire class so that we can rewind the scanner to parse the class
body to collect initializers (previously, it starts from the first
field initializer and ends at the last initializer). This resulted
some expectation changes in the debugger tests, though the
initializers remain debuggable.
- A temporary ClassScope is created during reparsing. After the class
is reparsed, we use the information from the ScopeInfo to update
the allocated indices of the variables in the ClassScope.
Bug: v8:10704
Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#78299}
Treat all stack pointers as roots:
- Maintain a global linked-list of StackMemories
- Update StackFrameIterator to process inactive stacks
- Visit roots in all inactive stacks (including root marking and root
pointer updating).
Drive-by:
- Fix some issues uncovered by the test
- Refactor the builtin constants
R=mlippautz@chromium.org,ahaas@chromium.org
Bug: v8:12191
Change-Id: I5b6381f9818166e2eabf80dd59135673dddb2afc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310932
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78291}
This reverts commit 863bc2b88a.
Reason for revert: https://crbug.com/1276923
Original change's description:
> [turbofan] Improve StoreStoreElimination
>
> Previously, StoreStoreElimination handled allocations as
> "can observe anything". This is pretty conservative and prohibits
> elimination of repeated double stores to the same field.
> With this CL allocations are changed to "observes initializing or
> transitioning stores".
> This way it is guaranteed that initializing stores to a freshly created
> object or stores that are part of a map transition are not eliminated
> before allocations (that can trigger GC), but allows elimination of
> non-initializing, non-transitioning, unobservable stores in the
> presence of allocations.
>
> Bug: v8:12200
> Change-Id: Ie1419696b9c8cb7c39aecf38d9f08102177b2c0f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295449
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78230}
Bug: chromium:1276923
Change-Id: I43dc3572ce1ef1fda42b7551ce8210d9f03e36ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318666
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78277}
This CL adds the following specific cases, to make sure they are
correctly handled by the slow path:
- the backing store of a TypedArray gets detached after optimisation
- passing null instead of a TA doesn't lead to a deopt
Bug: v8:11739, chromium:1052746
Change-Id: I7dfd3da9f535831901998ca6fad854af6e93e9f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320425
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78274}
This is a reland of 3ee4804f83.
The CL was originally reverted for blink test failures. Since the
revert, the blink top-level await flag has been removed.
Original change's description:
> [top-level-await] Remove --harmony-top-level-await
>
> TLA has been shipped since v8.9.
>
> Bug: v8:9344, chromium:1271114
> Change-Id: Ibebf21da8bacb1f0d212390133847495ad8553e5
> Reviewed-on:
https://chromium-review.googlesource.com/c/v8/v8/+/3307103
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78169}
Bug: v8:9344, chromium:1271114
Change-Id: I96a9641967a23a12ba2467a69e5859ad8647f3e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318717
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78261}
Previously, StoreStoreElimination handled allocations as
"can observe anything". This is pretty conservative and prohibits
elimination of repeated double stores to the same field.
With this CL allocations are changed to "observes initializing or
transitioning stores".
This way it is guaranteed that initializing stores to a freshly created
object or stores that are part of a map transition are not eliminated
before allocations (that can trigger GC), but allows elimination of
non-initializing, non-transitioning, unobservable stores in the
presence of allocations.
Bug: v8:12200
Change-Id: Ie1419696b9c8cb7c39aecf38d9f08102177b2c0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295449
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78230}
If multiple isolates are running concurrently and one of them calls
`quit`, we should not delete the counters map, because another isolate
might still access it.
R=mlippautz@chromium.orgCC=nikolaos@chromium.org
Bug: v8:12453
Change-Id: I6d41478f188f0043b7d6055b0872574c28fd3039
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310807
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78226}
This fixes data races when lazily creating counters (and populating the
{counter_map_}, and when concurrently adding samples to the counters.
It also ensures that the Wasm engine is stopped (via {V8::Dispose})
before printing and deleting counters, as background threads might still
try to update the counters otherwise.
R=mlippautz@chromium.org
CC=nikolaos@chromium.org
Bug: v8:12453, chromium:1275117
Change-Id: Ie6beea6cc74eea52143d12f9921597da4a250f2a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3308710
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78191}
When emitting code, character ranges must only specify ranges which
the actual subject string (one- or two-byte) may contain.
This was not always the case, specifically for ranges with
`from <= kMaxUint8` and `to > kMaxUint8`.
The reason this is so tricky: 1. not all parts of the pipeline know
whether we are compiling for one- or two-byte subjects; 2. for
case-insensitive regexps, an out-of-bounds CharacterRange may have an
in-bounds case equivalent (e.g. /[Ÿ]/i also matches 'ÿ' == \u{ff}),
which only gets added somewhere in the middle of the pipeline.
Our current solution is to clamp immediately before code emission. We
also keep the existing handling/dchecks of the 0x10ffff marker value
which may occur in the two-byte subject case.
Bug: v8:11069
Change-Id: Ic7b34a13a900ea2aa3df032daac9236bf5682a42
Fixed: chromium:1275096
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306569
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78186}
Add suppose for compiling non-eager, non-top-level inner functions in
parallel, using the compiler dispatcher. This behaviour can be enabled
with --parallel-compile-tasks-for-lazy.
There are a couple of consequences:
* To support this we need support for off-thread ScopeInfo
deserialization, so this adds that too.
* The previous --parallel-compile-tasks flag is renamed to the more
descriptive --parallel-compile-tasks-for-eager-toplevel.
* Both parallel-compile-tasks flags are moved onto
UnoptimizedCompileFlags so that they can be enabled/disabled on a
per-compile basis (e.g. enabled for streaming, disabled for
re-parsing).
* asm.js compilations can now happen without an active Context (in
the compiler dispatcher's idle finalization) so we can't get a
ContextId for metric reporting; we'd need to somehow fix this if we
wanted asm.js UKM but for now it's probably fine.
* Took the opportunity to clean up some of the "can preparse" logic in
the parser.
Change-Id: I20b1ec6a6bacfe268808edc8d812b92370c5840d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3281924
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78183}
Try blocks (whether catch or finally) will unconditionally create
handler tables and start a new basic block for the exception handler.
This can accidentally resurrect a dead block when the entire try block
is dead (and hence can never enter the exception handler in the first
place).
Add a deadness check to BuildTryCatch/Finally to fix this.
Bug: chromium:1273677
Change-Id: Icda9deb1459e47de5cb83e7b636299e24c3ebe77
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306555
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78179}
Currently, JSFinalizationRegistry has a BodyDescriptor that iterates
next_dirty as a custom weak field, and it has a WeakListVisitor that
cleans up any items from the list that should be removed. However, none
of that code is used, because JSFinalizationRegistry objects are created
with visitor ID kVisitJSObjectFast. This change gives them a custom
visitor ID so that next_dirty can be treated as weak.
Bug: v8:12430
Change-Id: I31c1935257ad508b13a3e684662d2ca406d8ed19
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3307096
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78167}
--experimental-wasm-mv has been removed, and --wasm-loop-unrolling is on
by default.
Change-Id: I094870765031ef46fcec95e9071333e4e80f407b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3302805
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78140}
{WasmInternalFunction::external} might return a function that is not
a WasmExportedFunction, at which point the code in ProcessTypeFeedback
fails.
See crrev.com/c/3277878 for context.
Bug: v8:12436, v8:12166
Change-Id: I09ef96df3fc051586044dd9c2ce88d6aeeb34b9f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306391
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78139}
To trigger speculative inlining, a function needs to run a few times on
Liftoff-tier, and then tier-up to Turbofan. We make sure this happens
by enabling --wasm-dynamic-tiering with a small budget, and running
the critical functions until {%IsLiftoffFunction} is false.
We also add an additional test.
Bug: v8:12166
Change-Id: I6c5e0d3f1e3ba0df8510ae6850d8e9af1d01c179
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306372
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78123}
See crrev.com/c/3277878 for context.
We should only transform extenral to internal function references when
passing a function value to a function-typed global or table. For their
externref counterparts, we should preserve the reference unchanged.
Bug: v8:11510, chromium:1273705
Change-Id: Ic1719c4d31e175f3a37ced6e4e4dfcd61a19ae57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3302790
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78108}
Design doc: bit.ly/3jEVgzz
We separate the internal representation of function references in Wasm
from their JSFunction-based (external) representation. This improves
performance of call_ref by requiring less indirections to load the
context and call target from a function reference. In the boundary
between wasm and JS/the C API, we add transformations between the two
representations.
Detailed changes:
- Introduce WasmInternalFunction, containing fields required by
call_ref, as well as a reference to the corresponding
WasmExternalFunction. Add a reference to the WasmInternalFunction in
WasmFunctionData. The {WasmInternalFunction::FromExternal} helper
extracts the internal out of an external function.
- Change {WasmInstanceObject::external_functions()} to internal
functions.
- Change wasm function tables to contain internal functions.
- Change the following code to use internal functions:
- call_ref in liftoff and Turbofan
- function type checks in liftoff and Turbofan
- CallRefIC and GenericJSToWasmWrapper builtins
- {InitExprInterface::RefFunc}
- module-compiler.cc in {ProcessTypeFeedback}
- In module-instantiate.cc, in function-rtt creation.
- Add transformations between internal and external functions in:
- WasmWrapperGraphBuilder::{ToJS, BuildUnpackObjectWrapper, FromJS,
BuildJSToJSWrapper}.
- debug-wasm-objects.cc in {FunctionProxy::Get},
{WasmValueObject::New} and {AddWasmTableObjectInternalProperties}.
- runtime-wasm.cc in ReplaceWrapper
- the C and JS APIs
- module-instantiate.cc, in import and export processing, as well as
{InitializeIndirectFunctionTables}
- WasmTableObject::{IsValidElement, SetFunctionTableEntry}
- {WasmGlobalObject::SetFuncRef}
- Simplify body descriptors of WasmExternalFunction variants.
- Adjust tests.
Bug: v8:11510
Change-Id: I8377f46f55c3771391ae1c5c8201a83854ee7878
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277878
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78068}
In the final version, we might parse the parameters when deserializing
instead, but this approach is more suitable for prototyping.
Bug: v8:11525
Change-Id: I000869877b03fd1909acf602ab5190951b1939e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295456
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78065}
Private methods use a property with symbol name that stores a context.
This is then loaded to perform the brand check. Since this uses
JSLoadProperty in Turbofan, we should not type JSLoadProperty as
NonInternal.
Bug: chromium:1269063, v8:12359
Change-Id: I920ccf46e939ab0477ff2fdb3cda6d7d94bab0af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293089
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78042}
It is possible to inline a JSToWasm wrapper that directly calls a
WasmToJS wrapper. In this case we need to make sure that the instance
we pass is a WasmApiFunctionRef, not a WasmInstanceObject.
Bug: chromium:1271456
Change-Id: I684a769922895860a43c73ba43c2598c9bda4b64
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293423
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78031}
We prevent unrolling of loops with indirect calls. We expand the set of
permitted wasm builtins in unrolled loops.
Bug: v8:11298
Change-Id: I70b8ff3b16d9b0d3a4ea2d103f8ffb74083fd2a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3289152
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77965}
On 32-bit architectures, we need to run Int64Lowering on the inlinee
code to make it compatible with the caller code.
Since Int64Lowering now runs while a GraphReducer is active, only one of
them can use node marks to store node states. Therefore, we move the
Int64Lowering node states to an internal map.
Bug: v8:12166
Change-Id: I53b85442d503e71fa533e06568f4b9db572a4401
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3283072
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77941}
The stored value might be an allocation that can be removed once the
Store node is removed. We need to revisit this node manually because
inputs in a node removed with ReplaceWithValue are not revisited
automatically.
Bug: v8:11510
Change-Id: I57cb8955a3e2f7143474ad7ced9d946e6d1cc18e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277880
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77899}
In each wasm CallDescriptor, we store the signature of the call based on
the real parameters passed to the call. This signature is more precise
than the formal function signature. We use this signature in inlining
to enable more optimizations.
Changes:
- Add wasm_sig_ field to CallDescriptor.
- Construct the real signature in {DoCall} and {DoReturnCall} in
graph-builder-interface, and pass it to all call-related functions in
WasmGraphBuilder.
- Update {ReplaceTypeInCallDescriptorWith} to use ValueType over
MachineType. Construct the updated function signature.
- In wasm-inlining, kill the Call node after inlining.
- Add two tests.
Bug: v8:11510
Change-Id: Ica711b6b4d83945ecb7201be26577eab7db3c060
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270539
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77889}
FLAG_wasm_dynamic_tiering is still off by default. When enabled,
it now uses the technique previously behind --new-wasm-dynamic-tiering.
Bug: v8:12281
Change-Id: I365c2c066e62418cd6abc7830f95d1fe0f950e33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275570
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77883}
Similar to previous bug v8:11771, this test needs deterministic GC
behavior so it is incompatible with concurrent inlining.
Bug: v8:12374, v8:4578
Change-Id: Ib3667744d1032524a0c2e697a970876dfc1677ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3272882
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77851}
Loop headers in the interpreter would start a new basic block, which
among other things would reset the liveness of that block. This meant
that a loop created after dead code, without a check for whether the
code is currently dead or not, would "resurrect" that block's liveness,
making the inside of the loop live even though the loop itself is
unreachable.
This works fine, since the loop is still unreachable, but can breaks
DCHECKs in bytecode liveness analysis for cases where a register is
supposed to be initialised before the loop, in the dead code, and is
then used inside the loop, in the resurrected code.
Normally this wouldn't be a problem, since blocks are normally killed on
the statement level and we check for deadness during statement
iteration, but `foo() = x` introduces an expression-level block killer
(being re-written to `foo[throw ReferenceError] = x`) and we don't check
for deadness after assignment Lhs preparation.
This does mean that we have to fix the InterpreterJumps test, to not try
to jump into the middle of a loop (since this could revive the loop).
This can only happen when manually creating bytecode, bytecode generated
from JavaScript is always reducible.
Bug: chromium:1230597
Change-Id: I8403ccdeae7e5450adf629026e2ca8a134c81877
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275557
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77846}
Changes:
- Enable allocation folding for wasm-gc graphs.
- Improve structure of wasm escape analysis code. Kill dead nodes.
- Revisit object node after eliminating a load or a store to that node.
- Add a couple of tests, rename one test file.
Bug: v8:11510
Change-Id: I8b3c5186cd0a8827744a05eba366ff79bc7bc975
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3264215
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77840}
The GC already treats some embedded object pointers in Code as weak,
based on Code::IsWeakObject. If one of those embedded objects ends up
unmarked during a full mark-collect GC, then the Code is marked for lazy
deoptimization and the embedded objects are cleared. However, many of
those same objects are often held strongly by the deoptimization literal
array for the Code, which causes memory leaks. This change updates the
deoptimization literals array to store those objects weakly. Any Code
currently executing on the stack might need those deoptimization
literals in order to deoptimize, so the deoptimization literal array is
marked strongly in that case.
Design document:
https://docs.google.com/document/d/1gFRBYCeqz9Mysx8CVYQkldBbk3AZLo8UX0DMLZV_7qw/edit?usp=sharing
Bug: v8:4578
Change-Id: I02e86683c59371e9f88ecf523750c9c6afebdb39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160299
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#77805}
In assignments the lhs should be evaluated first and shouldn't be
re-evaluated when the value of the rhs is available. Fix it by
saving the receiver and the key registers into AssignmentLhsData
before building the assignment and use them later, instead of visiting
the AST again to retrieve the receiver.
In addition, now that we save the receiver register, use it to
perform the brand check even when we know for sure that it's
going to fail later because it's a write to a private
method or accessing the accessor in the wrong way (v8:11364),
so that the brand check error always appears first if it is present,
as specified in
https://tc39.es/proposal-private-methods/#sec-privatefieldget
Drive-by: unify the brand check error messages, and replace "Object"
with "Receiver" in the messages for clarity. The instance private
brand check now throws "Receiver must be an instance of class <name>"
and the static private brand check now throws "Receiver must be
class <name>". Also always set the expression position to the
property load position, because the brand check failure comes from
the load operation.
Bug: v8:12352, v8:11364
Change-Id: I61a8979b2e02b561dd5b2b35f9e0b6691fe07599
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3266964
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77797}
In order to construct the optimal source code combination for functions
(and especially the positions inside the optimal source code for each
function), we need to know all functions upfront.
Rewrite the d8-based snapshotter so that it discovers all objects first
(+ assigns ids), then does the actual snapshotting.
Bug: v8:11525
Change-Id: I4f4e5589575ee9738e8a83aa6cda2c8164803b4c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268915
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77794}
Capture group names were extended in
https://github.com/tc39/ecma262/pull/1869/fileshttps://github.com/tc39/ecma262/pull/1932/files
RegExpIdentifierName now explicitly enables unicode (+U) for
unicode escape sequences; likewise, surrogate pairs are now allowed
unconditionally.
The implementation simply switches on unicode temporarily while
parsing a capture group name.
Good news everyone, /(?<𝒜>.)/ is now a legal pattern.
Bug: v8:10384
Change-Id: Ida805998eb91ed717b2e05d81d52c1ed61104e3f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3233234
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77722}
This is a reland of 0446ab7ce1
Additional fix:
Manually set the host-defined options on deserialised scripts in d8.
Original change's description:
> [d8] Verify host-defined options
>
> d8 never checked what the actual value of the host-defined options are.
> We now properly very that the host-defined options is a specific object
> so we we don't end up accidentally ignoring a wrong options object.
>
> Drive-by-fix:
> - Convert %AbortJS argument to string
>
> Bug: chromium:1244145
> Change-Id: If0ed128d215682bcf066592418420548b06eb6a1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259655
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77699}
Bug: chromium:1244145
Change-Id: I8ddfdba27d84c36862323ab9e1aba14b2ff932a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259539
Auto-Submit: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77716}
The wasm serialization format only contains TurboFan code. All other
functions are only represented by placeholders. With this CL
serialization fails if the serialized module does not contain any
TurboFan functions and would therefore consist only of placeholders.
This is a defense in depth approach, because ideally serialization
only gets triggered when TurboFan code is available. However, in some
scenarios like debugging it can happen that modules without TurboFan
code get serialized.
Bug: v8:12281
Change-Id: Ib05430ff89eb2317da80fc0d086ce1d7ab0e919d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3212510
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77715}
The old "gc-safe" implementation to get the off-heap type information
wasn't quite as gc-safe as it needs to be.
Due to parallel compaction, we shouldn't check for forwarding pointers;
instead we should rely on the old location of the Foreign, but make sure
not to look at its Map (which might be a forwarding pointer).
Bug: v8:12185
Change-Id: I4570b00a5300a0d7ed8c042fa21d355373e0e691
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3260513
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77707}
This reverts commit 0446ab7ce1.
Reason for revert: Lots of failures https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20debug/37355/overview
Original change's description:
> [d8] Verify host-defined options
>
> d8 never checked what the actual value of the host-defined options are.
> We now properly very that the host-defined options is a specific object
> so we we don't end up accidentally ignoring a wrong options object.
>
> Drive-by-fix:
> - Convert %AbortJS argument to string
>
> Bug: chromium:1244145
> Change-Id: If0ed128d215682bcf066592418420548b06eb6a1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259655
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77699}
Bug: chromium:1244145
Change-Id: I267f4bdbd8afce81934f4e813dbe1ec09ebdc1ae
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259538
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#77705}
This runtime function behaves like StoreDataPropertyInLiteral, except it
can throw, since it's also used for defining public class fields. Unlike
the literal use case, class field can end up throwing due to field
initializers doing things like freezing the instance.
Bug: chromium:1264828
Change-Id: I3ea4d15ad9b906c26763f022c8e22b757fa80b6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3252558
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77704}
d8 never checked what the actual value of the host-defined options are.
We now properly very that the host-defined options is a specific object
so we we don't end up accidentally ignoring a wrong options object.
Drive-by-fix:
- Convert %AbortJS argument to string
Bug: chromium:1244145
Change-Id: If0ed128d215682bcf066592418420548b06eb6a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259655
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77699}
If index > JSObject::kMaxElementIndex, we have to perform a prototype
chain lookup for a named property. The corresponding check was missing
for string receivers.
Fixed: chromium:1265043
Change-Id: Ibccd058a4bd108eeee235762bea0bc4163aaa0b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3257704
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77683}
Unfortunately, CharacterRanges may use 0x10ffff as a marker value
signifying 'highest possible code unit' irrespective of whether the
regexp instance has the unicode flag or not. This value makes it
through RegExpCharacterClass::ToNode unmodified (since no surrogate
desugaring takes place without /u). Correctly mask out the 0xffff
value for purposes of building our uint16_t range array.
Note: It'd be better to never introduce 0x10ffff in the first place,
but given the irregexp pipeline's lack of hackability I hesitate to
change this - we are sure to rely on it implicitly in other spots.
Drive-by: Refactors.
Fixed: chromium:1264508
Bug: v8:11069
Change-Id: Ib3c5780e91f682f1a6d15f26eb4cf03636d93c25
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256549
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77673}
When a Promise-Reject handler throws an unhandled exception, we should
use that promise's context for reporting the exception to the runtime.
This avoids a null-pointer deref.
Fixed: chromium:1263994
Change-Id: I3792a1884af4a83991249d612caf15588ea77dad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3250912
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77652}
In stress runs a GC may kick in before assertOptimized() is called
on the optimized function, causing it to deoptimize and the test
would fail even if the function is optimized as expected.
Adding --no-stress-flush-code --no-flush-bytecode fixes the timing
issue.
Bug: v8:12332
Change-Id: If43c2a06e84c0e3b5e21f7bde160340a0fc742f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3237326
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#77645}
Drive-by:
* don't create proto handlers for DefineOwnIC and StoreOwnIC,
* make sure that none of the DefineOwnIC and StoreOwnIC handlers are
leaked into StoreIC's megamorphic stub cache.
Bug: v8:9888, chromium:1259950
Change-Id: I9db538e6ed14bc578aa80df037ffebd9e8c3c649
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3250641
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77632}
There is a bit of a contradictory register requirement in the
instruction selector for i64x2.mul. We want dst == lhs (when AVX not
supported), but we also want lhs and rhs to be unique (to ensure that
that they don't alias the temp).
We remove the requirement for dst == lhs, since the code gen can handle
both cases (dst == lhs, dst != lhs), at the expense of 1 movaps.
Bug: chromium:1264462
Change-Id: Ia48572412b1f6e0da3551880d8b68a03f42fe2a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3253661
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77625}
This is a reland of 45227ffdb4
Differences:
- Handle one more flags conflict in variants.py.
- Disallow %VerifyType without --concurrent-recompilation.
Original change's description:
> [turbofan] extend type asserts to cover all JS types
>
> Extend type assertions to all types covering JavaScript values.
> This is achieved by allocating type representations on the heap using
> newly defined HeapObject subclasses. To allocate these in the compiler,
> we disable concurrent compilation for the --assert-types flag for now.
>
> Fix two type errors that came up with the existing tests:
> 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
> OtherObject.
> 2. OperationTyper::NumberToString(Type) can type the result as the
> HeapConstant Factory::zero_string(). However, NumberToString does
> not always produce this string. To avoid regressions, the CL keeps
> the HeapConstant type and changes the runtime and builtin code to
> always produce the canonical "0" string.
>
> A few tests were failing because they check for truncations to work
> and prevent deoptimization. However, AssertType nodes destroy all
> truncations (which is by design), so these tests are incompatible
> and now disabled for the assert_types variant.
>
> Drive-by fix: a few minor Torque issues that came up.
>
> Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77565}
Change-Id: I5b3c6745c6ad349ff8c2b199d9afdf0a9b5a7392
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247035
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77596}
The stack-switching test is not expected to pass yet if a GC happens
in the runtime call or in the wasm call.
R=ahaas@chromium.org
Bug: v8:12191, v8:12344
Change-Id: Iba66be58c1abd2ffbb22bbd7d34f8df0246a2a92
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3250900
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77594}
A "store own" slow runtime was missing, and the slow handler on the
StoreOwnIC was using the non-own slow runtime function, incorrectly
causing setters to be called.
For baseline, [1] invalidates the invariant that StoreOwnIC is only used
for storing properties already in the literal boilerplate, since it's
also used when the new literal is cloned from an object spread.
[1] https://chromium-review.googlesource.com/c/v8/v8/+/3224666
Bug: chromium:1263389, v8:11429
Change-Id: I0284396f306f937d1b8ff96adda6cc133c19726a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3244308
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77591}
Bug: v8:12329
Change-Id: I51c38d70537889b7534fb7e6b4066e6ab440234a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3248163
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77582}
This reverts commit 45227ffdb4.
Reason for revert: Breaks on gc_stress mode, see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/35988/overview
Original change's description:
> [turbofan] extend type asserts to cover all JS types
>
> Extend type assertions to all types covering JavaScript values.
> This is achieved by allocating type representations on the heap using
> newly defined HeapObject subclasses. To allocate these in the compiler,
> we disable concurrent compilation for the --assert-types flag for now.
>
> Fix two type errors that came up with the existing tests:
> 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
> OtherObject.
> 2. OperationTyper::NumberToString(Type) can type the result as the
> HeapConstant Factory::zero_string(). However, NumberToString does
> not always produce this string. To avoid regressions, the CL keeps
> the HeapConstant type and changes the runtime and builtin code to
> always produce the canonical "0" string.
>
> A few tests were failing because they check for truncations to work
> and prevent deoptimization. However, AssertType nodes destroy all
> truncations (which is by design), so these tests are incompatible
> and now disabled for the assert_types variant.
>
> Drive-by fix: a few minor Torque issues that came up.
>
> Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77565}
Change-Id: Ia779a11fc811846194c7a8d1e40b372b265e7ea4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247034
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Owners-Override: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#77566}
Extend type assertions to all types covering JavaScript values.
This is achieved by allocating type representations on the heap using
newly defined HeapObject subclasses. To allocate these in the compiler,
we disable concurrent compilation for the --assert-types flag for now.
Fix two type errors that came up with the existing tests:
1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
OtherObject.
2. OperationTyper::NumberToString(Type) can type the result as the
HeapConstant Factory::zero_string(). However, NumberToString does
not always produce this string. To avoid regressions, the CL keeps
the HeapConstant type and changes the runtime and builtin code to
always produce the canonical "0" string.
A few tests were failing because they check for truncations to work
and prevent deoptimization. However, AssertType nodes destroy all
truncations (which is by design), so these tests are incompatible
and now disabled for the assert_types variant.
Drive-by fix: a few minor Torque issues that came up.
Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77565}
Recompute the spill offsets for values in the merge region, instead of
reusing the offsets of the source. This ensures that spill slots stay
contiguous (modulo alignment).
This also solves a correctness issue where the spill offsets in the
merge region could move up, thereby overwriting the source of another
move.
With this change, the spill offsets always move down (to fill the gap)
or stay the same, such that processing them from bottom to top
can only overwrite sources of already-processed moves.
Since we do not reuse the current state's offsets, this might generate
extra stack moves and regress generated code performance a bit.
Drive-by: print spill offsets in the Liftoff trace
R=clemensb@chromium.org
Bug: v8:12270
Change-Id: I8d20df8fc1e80dd36b6f651de457686e9935a628
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3245115
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77556}
According to the spec, the three parameters (stdlib, foreign, and heap)
must be mutually distinct. We did not check this yet, which led to
observable differences between asm validation and standard JavaScript
semantics.
R=thibaudm@chromium.org
Bug: chromium:1068355
Change-Id: I451f63d10ea50474aeb6e8a547918b5af769343b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3244408
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77554}
We used to apply an invalid optimization which skips `length` writes
if the JSArray is 'fast' and the old value equals the new value. This
optimization is not valid if e.g. `length` is non-writable.
Fixed: chromium:1262478
Change-Id: I49ef50de293dae5c3a62c64b303ec34b9c0f6cbc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3236720
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77552}
This CL fixes an issue in EffectControlLinearizer, where the primitive
type of the argument of a fast C call was used to compute its
MachineType even when the argument was actually a TypedArray, which
should always be treated as a Tagged type. This resulted in Float32/64
typed arrays being passed in FP registers, leading to a crash in the
register allocator.
Drive-by fix: Fixed output from --trace-turbo-alloc so that all of its
sub-parts are printed with PrintF, avoiding interleaved log lines.
Bug: chromium:1260954
Change-Id: I249c8629daae3af437fb52f53f45211f3a214222
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3231341
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77521}
Character class handling in the irregexp pipeline is quite complex;
codepoints outside the BMP (basic multilingual plane) are only
translated into surrogate pairs when needed, e.g. when the subject
string is two-byte. If not needed, the codepoints simply stay part of
the list of CharacterRanges.
In EmitCharClass, we determine the valid subset of ranges through
ranges_length; until this CL, we forgot to pass that information on to
MakeRangeArray. Do that now by truncating the list of CharacterRanges.
Fixed: chromium:1262423
Change-Id: I5bb5b839e9935890ca2d10908ad66d72c3217178
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3240782
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77514}
To get more details about the failure when it flakes.
Bug: v8:12332
Change-Id: I1bf5188efe13a75e34dd9832e6275fd985ee8dbd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3233974
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77498}
If an output operand has "same as input" policy, we cannot assume that
it's input 0. Instead we should look at the {input_index}.
The bug manifests on Wasm select instructions, where the input index is
actually 2 and not 0.
In order to test this better, we introduce the a new
--turbo-force-mid-tier-regalloc flag, which always uses the mid-tier
register allocator. Otherwise the bug would only manifest on huge
functions.
R=mslekova@chromium.org
CC=thibaudm@chromium.org
Bug: v8:12330
Change-Id: I6a005a48bbd2aba354dc99fed587bffce24c8839
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234722
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77495}
Calling class constructors without new is a spec violation and should
raise an exception.
In [1] calling class constructors with spread (without new) was handled
by reducing the node to a call to runtime to raise the exception.
However, arguments of the call have to be evaluated first ([2]).
This CL changes the reduction of JSCallWithSpread/JSCallWithArrayLike to
a no-op in JSCallReducer if the target is a class constructor, delaying
raising of the exception to the call builtin.
[1] https://crrev.com/c/3229369
[2] https://tc39.es/ecma262/#sec-evaluatecall
Bug: chromium:1262007
Change-Id: I2ef504d4ce6e51d582b5951beb6debb983cefba6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3236348
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77492}
--no-stress-flush-bytecode doesn't exist and should be
--no-stress-flush-code. Not supressing it means a tester could pass
--stress-flush-code and --no-flush-bytecode, which are contradictory and
will assert.
Bug: v8:12331
Cq-Include-Trybots: luci.v8.try:v8_numfuzz_dbg_ng,v8_numfuzz_ng
Change-Id: I6490271bcb11f5ea925eb8b65fbe0455c2dafeaf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3233952
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77483}
Handling of class constructors was moved from CallFunction to Call
in [1].
When reducing calls with spread we forward varargs directly to
CallFunction, if we are spreading to inlined arguments or arguments of
the outermost function.
In that case we didn't check for class constructors and therefore didn't
raise an exception.
This CL adds checks for class constructors to all JSCall* nodes in
JSCallReducer that missed them before.
[1] https://crrev.com/c/3186434
Bug: chromium:1260623
Change-Id: Id39cdfd09ff5aae804ae30d96909518e408c9613
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229369
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77472}
These two tests rely on the functions being immediately compiled with SP.
Concurrent SP might add a delay and fail the test.
Bug: v8:12054
Change-Id: I52dbdfeb5c49c23f2d20a43bb8a87aba1f16358e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3233233
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77471}
mjsunit/regress/regress-crbug-9161 had two spinlocks on an atomic:
1. WaitUntil(lock == kStageRunning)
2. WaitUntil(lock == kStageDone)
But, in theory the worker updating the "lock" could progress all the way
to kStageDone before the first loop manages to check the lock value
again.
We can make this more robust by checking:
1. WaitUntil(lock != kStageInit)
2. WaitUntil(lock == kStageDone)
That way both loops check for _any_ state past the state they want to
progress past.
Bug: v8:11437
Change-Id: I5220e61070a305301c678928edb0925c04dae970
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3231339
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77460}
This CL adds support for BigInt.asIntN, the necessary operations and
extensions of the compiler's type system to allow lowering of BigInts
to word64 representations that are interpreted as signed 64 bit BigInts.
Bug: v8:9407
Change-Id: Id4f1f45437c1caf94e01c7b4e063c2ae2386c88a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3198070
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77458}
This is a reland of dca83ff7e7
Relanding without changes, looks like the bot that failed succeeded
again before the revert landed (https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN/38915/overview)
Original change's description:
> [snapshot] Fix two stress_snapshot failures
>
> 1. Stress snapshot discards code on SFIs, which breaks flushing
> invariants. Add --stress-snapshot to those invariants.
> 2. Another test failing on IsScript, added it to the disabled list.
>
> Change-Id: Ic415923a9cc96d34b74f7450b29be99c1b53d077
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229375
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77430}
Change-Id: I18fd290c3794d90addc2a94765d57a3ee3ceab86
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229563
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77447}
[1] fixes the behavior of StaNamedOwnProperty to no longer do prototype
lookups. This lets us revert [2] and go back to using the fast path in
the clone spread object literal bytecode.
The test case from [2] is kept.
[1] https://chromium-review.googlesource.com/c/v8/v8/+/2795831
[2] https://chromium-review.googlesource.com/c/v8/v8/+/3178969
Bug: v8:9888, chromium:1251366
Change-Id: I9d2cb69b803c403f63365f55d27c4de20ff7dafb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3224666
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77444}
1. Stress snapshot discards code on SFIs, which breaks flushing
invariants. Add --stress-snapshot to those invariants.
2. Another test failing on IsScript, added it to the disabled list.
Change-Id: Ic415923a9cc96d34b74f7450b29be99c1b53d077
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229375
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77430}
This CL improves wasm inlining heuristics in Turbofan, for an average
8,5% performance improvement in selected benchmarks.
Changes:
- In WasmInliner::Reduce(), only collect inlining candidates into a
priority queue, according to WasmInliner::LexicographicOrdering.
Move actual inlining to Finalize().
- Remove the InlineFirstFew heuristic. Add two limits to inlining:
Maximum relative size increase (reversely proportional to the function
size), and absolute size increase.
- Pass information about call frequency from liftoff-collected feedback
to the WasmInliner though the wasm module.
- Run wasm inlining along other optimizations in the pipeline.
- Split inlining and speculative inlining tests.
Bug: v8:7748, v8:12166
Change-Id: Iccee22093db765981889a24451fb458dfce1f1a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3222764
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77428}
Since we introduced `array.init` as a way to create fully initialized
arrays, immutable arrays are no longer useless, and they enable certain
static optimizations, so this patch allows them.
Bug: v8:7748
Change-Id: I404aab60099826f4bd83cf54e5e1acbc38a3ca9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3221151
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77397}
We need to check if the index is less than zero and miss to the runtime
if this is so.
Bug: chromium:1257519
Change-Id: I7d22f2765232815120b8baf7b8b83d5b00024375
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218975
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77380}
Introduces several new runtime mechanics for defining private fields,
including:
- Bytecode StaKeyedPropertyAsDefine
- Builtins StoreOwnIC{Trampoline|Baseline|_NoFeedback}
- Builtins KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic}
- TurboFan IR opcode JSDefineProperty
These new operations can reduce a runtime call per class field into a
more traditional Store equivalent. In the microbenchmarks, this
results in a substantial win over the status quo (~8x benchmark score
for single fields with the changes, ~20x with multiple fields).
The TurboFan JSDefineProperty op is lowered in
JSNativeContextSpecialization, however this required some hacks.
Because private fields are defined as DONT_ENUM when added to the
object, we can't find a suitable transition using the typical data
property (NONE) flags. I've added a mechanism to specify the required
PropertyAttributes for the transition we want to look up.
Details:
New bytecodes:
- StaKeyedPropertyAsDefine, which is essentially StaKeyedProperty
but with a different IC builtin (KeyedDefineOwnIC). This is a
bytecode rather than a flag for the existing StaKeyedProperty in
order to avoid impacting typical keyed stores in any way due to
additional branching and testing.
New builtins:
- StoreOwnIC{TTrampoline|Baseline|_NoFeedback} is now used for
StaNamedOwnProperty. Unlike the regular StoreIC, this variant will
no longer look up the property name in the prototype.
In adddition, this CL changes an assumption that
StoreNamedOwnProperty can't result in a map transition, as we
can't rely on the property already being present in the Map due
to an object literal boilerplate.
In the context of class features, this replaces the runtime
function %CreateDataProperty().
- KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic} is used by the
new StaKeyedPropertyAsDefine bytecode. This is similar to an
ordinary KeyedStoreIC, but will not check the prototype for
setters, and for private fields, will take the slow path if the
field already exists.
In the context of class features, this replaces the runtime
function %AddPrivateField().
TurboFan IR:
- JSDefineProperty is introduced to represent a situation where we
need to use "Define" semantics, in particular, it codifies that we
do not consult the prototype chain, and the semantics relating to
private fields are implied as well.
R=leszeks@chromium.org, syg@chromium.org, rmcilroy@chromium.org
Bug: v8:9888
Change-Id: Idcc947585c0e612f9e8533aa4e2e0f8f0df8875d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2795831
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#77377}
Land some of the tests for Temporal.PlainDateTime
All marked as FAIL at this stage.
Bug: v8:11544
Change-Id: I09bf681e61f19d96607c848ddcb6bee06580aff1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3085625
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77332}
Compiling Sparkplug on the heap saved 10% of the CompileBaseline
RCS metric, but that came with too much code complexity.
Since in the end that corresponds to < 1% of the entire compilation
time, we decided to revert this project.
This reverts:
commit e29b2ae48a
commit d1f2a83b7d
commit 4666e18206
commit a1147408e4
commit e0d4254f97
commit 9ab8422da7
commit a3b24ecc51
commit 1eb8770691
commit fe5c9dfd90
commit 7ac3b55a20
commit 7e95f30ec9
commit 323b596212
commit 6bf0b70490
commit e82b368b67
commit 5020d83e05
commit 642a467338
commit ec7b99d5c6
commit fb4f89aede
commit 208854bb14
commit 63be6dde31
Bug: v8:12158
Change-Id: I9f2539be6c7d80c6e243c9ab173e3c5bb0dff97d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3136453
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77319}
This is a reland of 0adc1410b1
1. Fork out test/mjsunit/temporal/function-exist.js test
to test/mjsunit/temporal/function-exist-no-i18n.js and mark
function-exist FAIL in no_i18n build.
Original change's description:
> [Temporal] Part 1 - Skeleton
>
> 1. Expose all the functions to empty buildins.
> 2. Wire up basic structure of classes and internal slots.
>
> Design Doc: https://docs.google.com/document/d/1Huu2OUlmveBh4wjgx0D7ouC9O9vSdiZWaRK3OwkQZU0/
>
> This is just a CL to establish a skeleton for Temporal.
> The Temporal is very big. The prototype CL is in
> https://chromium-review.googlesource.com/c/v8/v8/+/2967755
> but too big to be reviewed so I break up the basic structure here first.
>
> Cq-Include-Trybots: luci.v8.try:v8_linux64_bazel
> Bug: v8:11544
> Change-Id: I10d09e3c2530e5b1a6ba60014a2294e138879ff3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3092561
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76819}
Bug: v8:11544
Change-Id: I60eaface94ba9b3408cb235cd1ae425151a36732
Cq-Include-Trybots: luci.v8.try:v8_linux64_bazel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160324
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77303}
The expected assertion is specific to irregexp codegen.
Bug: chromium:1255368
Change-Id: I14d033285014727de2e63582ed798fc82570497d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3207892
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77254}
When aborting code generation, we need to call {AbortedCodeGeneration}
on the {MacroAssembler} contained in the {RegExpMacroAssemblerARM}.
R=jgruber@chromium.org
Bug: chromium:1255368
Change-Id: If37351e8f5715e23affd21ad2de8a8eaad3ea094
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3204965
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77250}
The error showed when printing the resulting code object, because the
tier was neither TurboFan nor Liftoff, even though the code was
registered as a standard wasm function (instead of an import wrapper).
R=jkummerow@chromium.org
Bug: chromium:1254674
Change-Id: I26482fd88d72403393428979abf08e9f60cd8c4c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3202001
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77238}
This reenables a test which is passing, independent of missing
accounting for shared memory. This is because we repeatedly trigger a GC
explicitly in all workers.
R=dinfuehr@chromium.org
Bug: v8:12278
Change-Id: I73d1513d809787284af0be4956018806719acd50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3201995
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77219}
Trying to optimize in such case breaks down the optimization, as we
end up with potentially non-eliminatable nodes that depend on the dead
IfTrue/IfFalse node.
Drive-by: Clean up dead nodes with {Kill()}.
Bug: v8:11510, chromium:1255354
Change-Id: Ia89fe6c243974c3c2abac6ad80bd4677a935f637
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3200073
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77211}
When scanning for capture groups, we have to consider the case that the
current state is inside a character class. In that case skip everything
until the end of the current character class. Otherwise we would wrongly
count open brackets inside the character class as start of a capture
group.
Bug: chromium:1254704
Change-Id: I91d2177c464f7e507413d96216fe570253f17676
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199871
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77204}
Loop exits are only used during loop unrolling and are then removed, as
they cannot be handled by later optimization stages. Since unrolling
comes before inlining in the compilation pipeline, we should not emit
loop exits in inlined functions.
Bug: v8:12166
Change-Id: I28b3ebaf67c9e15b127eeb1a63906c4ecfd77480
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3195871
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77175}
The test allocates a lot of wasm memories. This got a low slower after
https://crrev.com/c/3190476, because we can now allocate more than 102
memories, and do not explicitly trigger a GC any more to get rid of
unused memories.
We should figure out how to tell the GC about the external memory such
that the memories get collected earlier.
R=ahaas@chromium.org
Bug: v8:12076, v8:12278
Change-Id: I9b8795a9999a806380d86f22e751de2727942648
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3196131
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77164}
The address space limit puts an arbitrary cap on the total reservation
size, thus limiting the total number of Wasm memories to around 100 on
64-bit systems.
Since the usable address space on 64 bit is much larger than the
1TB+4GB limit, this makes us reject code that we could otherwise just
execute.
This CL thus removes that limit completely.
See the linked issue for more discussion, including security
considerations.
R=jkummerow@chromium.org, rsesek@chromium.org
Bug: v8:12076
Change-Id: I1f61511d68efdab1f8cef4e09c0a39fc1d6fed60
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3190476
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77161}
It's confusing that we have CSA_CHECK and CSA_ASSERT and it's not
clear from the names that the former works in release mode and the
latter only in debug mode.
Renaming CSA_ASSERT to CSA_DCHECK makes it clear what it does. So now
we have CSA_CHECK and CSA_DCHECK and they're not confusing.
This also renames assert() in Torque to dcheck().
Bug: v8:12244
Change-Id: I6f25d431ebc6eec7ebe326b6b8ad3a0ac5e9a108
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3190104
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77160}
This fixes a long-standing TODO to disallow importing receivers that
have "toString" or "valueOf" patched. Calling those methods could have
observable side effects, so allowing that would require bigger
refactorings to ensure that we only call each such function exactly once
per import, and in the right order.
Since this use case is rare, we just forbid importing such receivers.
R=jkummerow@chromium.org
Bug: chromium:1248677
Change-Id: I99bbd7db950ec3c7ac9cc1f59e8c476688e7d7b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3190475
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77149}
This is a reland of 7d849870ff
Original change's description:
> [regexp] Reorganize and deduplicate in the regexp parser
>
> The parser is organized in a somewhat tricky way s.t. it can be
> hard to map the implementation back to the specified grammar.
>
> In particular, the logic for CharacterClassEscape, ClassEscape,
> and CharacterEscape was implemented twice - once inside a character
> class, once outside.
>
> This CL refactors related logic to have only a single implementation.
>
> As a drive-by, fix one related inconsistency related to \k inside
> a character class.
>
> Fixed: v8:10602
> Change-Id: I5858840159694fa6f8d1aa857027db80754e3dfd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3178966
> Reviewed-by: Mathias Bynens <mathias@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77114}
Fixed: v8:10602,chromium:1253976
Change-Id: I9e7cc6a34d3be06e1a68895775aa50b0eee78c57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3193531
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77135}
This reverts commit 7d849870ff.
Reason for revert: Will block roll. Broke error message tests upstream:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Blink%20Win/6635/overview
Original change's description:
> [regexp] Reorganize and deduplicate in the regexp parser
>
> The parser is organized in a somewhat tricky way s.t. it can be
> hard to map the implementation back to the specified grammar.
>
> In particular, the logic for CharacterClassEscape, ClassEscape,
> and CharacterEscape was implemented twice - once inside a character
> class, once outside.
>
> This CL refactors related logic to have only a single implementation.
>
> As a drive-by, fix one related inconsistency related to \k inside
> a character class.
>
> Fixed: v8:10602
> Change-Id: I5858840159694fa6f8d1aa857027db80754e3dfd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3178966
> Reviewed-by: Mathias Bynens <mathias@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77114}
Change-Id: Ic7404d6c9f0e6ea51e8cd8f1ab672856dca0c637
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3190692
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#77125}
The parser is organized in a somewhat tricky way s.t. it can be
hard to map the implementation back to the specified grammar.
In particular, the logic for CharacterClassEscape, ClassEscape,
and CharacterEscape was implemented twice - once inside a character
class, once outside.
This CL refactors related logic to have only a single implementation.
As a drive-by, fix one related inconsistency related to \k inside
a character class.
Fixed: v8:10602
Change-Id: I5858840159694fa6f8d1aa857027db80754e3dfd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3178966
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77114}
After the parameter processing, the arraybuffer may have been detached.
TypedArray copyWithin/fill should throw in that condition. TypedArray
includes should return false if the search element is not undefined.
Change-Id: If507d0efa1dafbe3dcefcd368e5ea27406bb3df8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3144315
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77103}
When cloning objects using spread and update properties (e.g.
obj = {...o, x: 0}), we wrongly used the setter for the update argument
if one was set.
This CL changes the behaviour such that all arguments following the
spread are treated as dynamic arguments.
Bug: chromium:1251366
Change-Id: I76a6d02606dca0faa0a256f465834d85d3df4f6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3178969
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77079}
In Liftoff, the result of table.grow was smi-untagged and sign-extended
to a ptr-sized value. However the result is typed as i32, so the upper
32 bits should be cleared on 64 bit platforms. In particular this is
observable when the value is used as an index for a memory operand,
which leads to the repro in the attached issue.
Match the TF behavior by untagging the value as a 32-bit int.
R=clemensb@chromium.orgCC=ahaas@chromium.org
Bug: chromium:1251465
Change-Id: Ia57fd8a69ecb2787b42bbf8217e448976aa1dbd9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3173680
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77044}
Because these instructions can trap, we don't want them to be reordered
as freely as unprotected accesses.
As part of this, make explicit which opcodes support a MemoryAccessMode.
Bug: v8:12018
Change-Id: I9db3053d7d62ffce6d3c95d62adce71ae40dae62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3172770
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77031}
The tests won't be very interesting, but we should still have basic
smoke tests.
Bug: v8:11111
Change-Id: I57eadfc090883bc9b84e5b2fb5984b5ed588a69b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3177223
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77029}
Change-Id: Iba7d3f528262b3979d3bfe83784c3cfe050cd6e6
No-Try: true
No-Presubmit: true
No-Tree-Checks: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3180241
Auto-Submit: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77025}
'#x in expr' currently parses incorrectly and associates #x as an
operand of an existing binary expression continuation if the previous
operator was of higher precedence. For example, 0 << #x in foo gets
incorrectly parsed as (0 << #x) in foo.
Bug: v8:12259, v8:12086
Change-Id: Ie37ff49ff6e63b3ea91fd0fba6bc73ec839c580b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3176506
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77020}
The proposal has changed and we'll start on the new implementation
from scratch.
Bug: v8:11935, v8:7467
Change-Id: I29e39a414027d80fd91764ce02a05d7c032a41f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3178964
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77016}
This fast path check protects the IsRegExp() path (which checks
RegExp.prototype[Symbol.match]) and thus we must use the appropriate
ForMatch check instead of the default check.
Fixed: chromium:1238033
Change-Id: I0b7ce280f1fa9bfacf20381d80c84f9513f45163
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3177222
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77004}
Liftoff is fully supported on all officially supported platforms, thus
remove a TODO to implement it on more platforms.
R=thibaudm@chromium.org
Bug: v8:11879
Change-Id: I00a559286d67e7e377a36b68803ee30e8fa2f34e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3168341
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76987}
The function index encoded into the serialized module is already offset
by num_imported_functions. For lazy compilation, however, we added the
number of imported functions another time, which was incorrect.
R=clemensb@chromium.org
Change-Id: I56380e21e74b4d1935ebdbab6ef8cc388de49f2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3172761
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76965}
The fix is released now, so we can add the tests to the public repo.
R=ahaas@chromium.org
Bug: chromium:1239116
Change-Id: Ie1489f6bcd934f84222b4631921475c389f778dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3172752
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76957}
This CL sets the prototype for the other WebAssembly API objects,
Module, Instance, Table, and Memory.
For Instance, the WebAssemblyInstanceImpl function got inlined, as
there was only one caller, and it made setting the prototype
complicated.
R=jkummerow@chromium.org
Bug: v8:12227
Change-Id: I93b459d69b917b099b27f957fb0e04b7e021bd59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3168282
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76954}
This is a reland of 5dde281c87,
after also fixing the ic-migrated-... test, in which an object died
too early.
Original change's description:
> [compiler] Fix a few test flakes and reenable the tests
>
> Bug: v8:12173
> Change-Id: I2983be9133f8ff4d1740e8eba05a3c29d603dfc3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3168270
> Auto-Submit: Georg Neis <neis@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76939}
Bug: v8:12173
Change-Id: If385e5c826b8470ef67f12705c5171f330f6cd57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3171353
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76946}
This fixes the first part of a failing spec test, the other WebAssembly
objects will follow in other CLs.
R=jkummerow@chromium.org
Bug: v8:12227
Change-Id: I7b57b0c518671f0614a88f0477b64e2507435aba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3168272
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76907}
The default value for table entries in WebAssembly tables is null when
the table gets allocated from WebAssembly, but when the table gets
allocated from JavaScript, the default value is undefined when the
table type is externref. With this CL V8 handles the JavaScript case
spec-compliant.
R=manoskouk@chromium.org
Bug: v8:12227
Change-Id: Ic8a1361629d8e5dfb59e2ee22a5e0ae0f6de936d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162045
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76892}
Behind the --wasm-inlining flag, we introduce speculative direct calls
as an alternative to invoking functions through references.
In pseudocode, call_ref(func_ref, args...) reduces to
if (func_ref == function_reference_at(expected_index)) {
call_direct(expected_index, args...)
} else call_ref(func_ref, args...)
The introduced direct call can later get inlined in WasmInliningPhase.
Currently, we always speculate that the reference is the function at
index 0. Proper heuristics, based on liftoff runtime feedback, will come
later.
Bug: v8:12166, v8:7748
Change-Id: Icd1319d3091b436e71906717fd8a2662bfbb8481
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162602
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76884}
JavascriptBuiltinContinuationFrame and BuiltinFrame didn't correctly
handle the receiver when it was included in the argument count.
Bug: v8:11112, chromium:1249941
Change-Id: I4d79bd152ea7e992fa3b87a4de2a509b79fcb37c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3165058
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76881}
... by adding atomic (relaxed) accessor's for a map's
constructor_or_backpointer field, and using them in the two functions.
Bug: chromium:1250216, v8:7790
Change-Id: I3416799cca73792ff5f8963685274ad9afdc6229
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162129
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76876}
Reason for revert: There was an out-dated wpt test in blink that
failed after this CL. I adjusted the test expectations in https://chromium-review.googlesource.com/c/chromium/src/+/3162980 so that I can land this CL.
Original change's description:
> Revert "[wasm][externref] Support default value for the table.set"
>
> This reverts commit 6b57898062.
>
> Reason for revert: Fails layout tests: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Blink%20Linux/13751/overview
>
> Original change's description:
> > [wasm][externref] Support default value for the table.set
> >
> > WebAssembly.Table.set allows a default value instead of the second
> > parameter, which was not supported by V8 so far.
> >
> > R=thibaudm@chromium.org
> >
> > Bug: v8:7581
> > Change-Id: I417790722b1cb4f854cd0056ecb8377c330c45fa
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3141574
> > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> > Commit-Queue: Andreas Haas <ahaas@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#76846}
>
> Bug: v8:7581
> Change-Id: I83d9be59c66ece3184b5708e5b8a3b401e4938ed
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3163257
> Auto-Submit: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Cr-Commit-Position: refs/heads/main@{#76852}
Bug: v8:7581
Change-Id: I248f836ba4de2a4e3f3d80c00e6f1ac0b46a38d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162608
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76873}
This reverts commit 6b57898062.
Reason for revert: Fails layout tests: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Blink%20Linux/13751/overview
Original change's description:
> [wasm][externref] Support default value for the table.set
>
> WebAssembly.Table.set allows a default value instead of the second
> parameter, which was not supported by V8 so far.
>
> R=thibaudm@chromium.org
>
> Bug: v8:7581
> Change-Id: I417790722b1cb4f854cd0056ecb8377c330c45fa
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3141574
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76846}
Bug: v8:7581
Change-Id: I83d9be59c66ece3184b5708e5b8a3b401e4938ed
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3163257
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#76852}
WebAssembly.Table.set allows a default value instead of the second
parameter, which was not supported by V8 so far.
R=thibaudm@chromium.org
Bug: v8:7581
Change-Id: I417790722b1cb4f854cd0056ecb8377c330c45fa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3141574
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76846}
Per https://github.com/WebAssembly/gc/issues/234, this implements
"nominal" type definitions with explicit supertypes, and statically
typed RTT-less instructions for allocation and testing/casting.
This should be fully backwards compatible with existing Wasm modules.
Spec: https://bit.ly/3cWcm6Q ("version 4")
Bug: v8:7748
Change-Id: Id5a1399b368fdfad22036cfd66f1bef593e640f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3144916
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76844}
This reverts commit 0adc1410b1.
Reason for revert: Reverting due to fail on V8 Linux - noi18n - debug https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8836095186331011153/+/u/Check_-_default/function-exist
Original change's description:
> [Temporal] Part 1 - Skeleton
>
> 1. Expose all the functions to empty buildins.
> 2. Wire up basic structure of classes and internal slots.
>
> Design Doc: https://docs.google.com/document/d/1Huu2OUlmveBh4wjgx0D7ouC9O9vSdiZWaRK3OwkQZU0/
>
> This is just a CL to establish a skeleton for Temporal.
> The Temporal is very big. The prototype CL is in
> https://chromium-review.googlesource.com/c/v8/v8/+/2967755
> but too big to be reviewed so I break up the basic structure here first.
>
> Cq-Include-Trybots: luci.v8.try:v8_linux64_bazel
> Bug: v8:11544
> Change-Id: I10d09e3c2530e5b1a6ba60014a2294e138879ff3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3092561
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76819}
Bug: v8:11544
Change-Id: I358f671452a986c8e87d1f831ab5eb1550a38441
Cq-Include-Trybots: luci.v8.try:v8_linux64_bazel
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160467
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Auto-Submit: Deepti Gandluri <gdeepti@chromium.org>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76821}
1. Expose all the functions to empty buildins.
2. Wire up basic structure of classes and internal slots.
Design Doc: https://docs.google.com/document/d/1Huu2OUlmveBh4wjgx0D7ouC9O9vSdiZWaRK3OwkQZU0/
This is just a CL to establish a skeleton for Temporal.
The Temporal is very big. The prototype CL is in
https://chromium-review.googlesource.com/c/v8/v8/+/2967755
but too big to be reviewed so I break up the basic structure here first.
Cq-Include-Trybots: luci.v8.try:v8_linux64_bazel
Bug: v8:11544
Change-Id: I10d09e3c2530e5b1a6ba60014a2294e138879ff3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3092561
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76819}
DataView constructor, DataView.prototype.byteLength
and DataView.prototype.byteOffset should throw
TypeError when the buffer was detached.
Both SpiderMonkey and JSC passed the test262 suites.
Bug: v8:12162
Change-Id: I126d24213c00e4d26540519bce9b5388862eb32c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3140015
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76818}
The bug was introduced in
https://chromium-review.googlesource.com/c/v8/v8/+/3147910 : We only
want the fast path when "start" is either missing or the number 0, not
when it's something which converts to 0.
Bug: chromium:1248704
Change-Id: I72bb8fa8a9b90a13aae216c6a8e16e7be54285fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3157948
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76789}
StackCheck needs to be implemented on liftoff.
Change-Id: I29624d65b82cbba3ef640ab7ea0cc78c2d5f2c4f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3152745
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#76766}
In the case that {dst}, {lhs} and {rhs} all point to the same register,
we would emit wrong code (negating the register and adding it to
itself). This CL fixes this by checking if {lhs == rhs}, and just
clearing the {dst} register in that case.
R=thibaudm@chromium.org
Bug: chromium:1247659
Change-Id: I7913617850adb34a5ad812369f16a7422358454d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3151955
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76765}
With statically in-bounds memory accesses (implemented in
https://crrev.com/c/2919827) we would only have an offset but no index
register for {TraceMemoryOperation}. This CL fixes that situation.
R=thibaudm@chromium.org
Bug: chromium:1248024
Change-Id: I856b263a560cb71791c61e446e78dd99c9664190
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3149464
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76763}
They need to agree about when to delegate to CloneFastJSArray, since it
produces arrays which are potentially COW. If they don't agree, TF
generates code which produces a COW array and then expects it to be
non-COW -> immediate deopt.
This CL gets rid of the discrepancy in the case when there's exactly
one argument and it's the number 0.
Some corner cases remain, e.g., 1st argument not a number but ToInteger
returns 0. These should be extremely rare in the real world.
Bug: v8:12194
Change-Id: I10230245c97f8997da4d79702f29ebff11297229
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3147910
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76745}
We add an option to BuildTFGraph to not emit stack checks and call
tracing and use it in inlined functions.
Also, we add tests for zero/multiple return values, as well as infinite
loops in the inlined function.
Bug: v8:12166
Change-Id: I5f34c57d9870592085804853ff23ba94897cc8d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3141589
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76718}
Simply putting all features behind --experimental-wasm-gc.
The intent is to simplify command lines.
Bug: v8:7748
Change-Id: Ibfaa4dc720087a490b177a2b95841620a4d25d89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3141583
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76703}
This is a reland of 1786f8d770. It turned
out that also x64 is broken, and only for TurboFan. Both is fixed now.
Original change's description:
> [arm64][liftoff] Fix trap handling on load lane
>
> This fixes the registered {protected_load_pc} to (always) point to the
> actual load instruction. If {dst != src} we would emit a register move
> before the load, and the trap handler would then not recognize the PC
> where the signal occurs, leading to a segfault.
>
> R=thibaudm@chromium.org
>
> Bug: chromium:1242300, v8:12018
> Change-Id: I3ed2a8307e353fd85a7ddedf6ecb73e90a112d32
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3136454
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76642}
Bug: chromium:1242300, v8:12018
Change-Id: I79284ab9815f5363f759569d98c8c4b52d48e738
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3140609
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76698}
We introduce basic wasm inlining infrastructure behind a flag. The
implementation is currently incomplete. Additionally, we always inline
the function at index 0; proper inlining heuristics will be added later.
Changes:
- Rename WasmInliningPhase -> JSWasmInliningPhase
- Introduce WasmInliningPhase and WasmInliner.
- Pass additional parameters as needed to GenerateCodeForWasmFunction.
- Remove EnsureEnd in WasmGraphAssembler. Create end node at the start
of compilation.
- Add a simple test.
Bug: v8:12166
Change-Id: Ifd7006ba378e9f74cd248b71e16869fbbb8a82be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3141575
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76689}
We use BuildCCall over CallBuiltin. This improves the performance of
array.copy by up to 2x for small arrays.
Bug: v8:7748
Change-Id: Ibbd6a69267edb229beda1f6de4ff1c48eb38b729
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3135580
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76661}
The WebAssembly.Table constructor supports a second parameter that was
not supported by V8 so far.
R=thibaudm@chromium.org
Bug: v8:7581
Change-Id: Id74c53a6b1bde7f49a4edea8397d1cab253e1a0e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3141571
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76660}
After concurrent inlining is true by default we keep testing the
negated version on the main linux bots and drop testing the
variant on FYI, which is a no-op now.
Bug: v8:7790
Change-Id: I604838a45f3de242db82b42b93afdb56804152b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3140599
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76655}
ParserBase::ParseClassLiteral and BaseConsumedPreparseData::RestoreDataForScope
both declare the class variable, but the logic is so complex
that they sometimes ended up both declaring it.
This is further complicated by some of the variable values (esp.
inner_scope_calls_eval_) potentially changing in between, so we can't
just redo the same logic any more.
Forcefully make it work by making RestoreDataForScope declare the variable
iff ParseClassLiteral didn't.
Bug: chromium:1245870
Change-Id: I777fd9d78145240448fc25709d2b118977d91056
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3140596
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76654}
Fixed issue were using the `arguments` object as a shorthand for a class
field initializer was not producing an early error.
Bug: chromium:1216261
Change-Id: I7d8f5a85c6881f7ca12a0e8450954de15bdd6033
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3095017
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Luis Fernando Pardo Sixtos <lpardosixtos@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#76646}
This reverts commit 1786f8d770.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64/44442/overview
Original change's description:
> [arm64][liftoff] Fix trap handling on load lane
>
> This fixes the registered {protected_load_pc} to (always) point to the
> actual load instruction. If {dst != src} we would emit a register move
> before the load, and the trap handler would then not recognize the PC
> where the signal occurs, leading to a segfault.
>
> R=thibaudm@chromium.org
>
> Bug: chromium:1242300, v8:12018
> Change-Id: I3ed2a8307e353fd85a7ddedf6ecb73e90a112d32
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3136454
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76642}
Bug: chromium:1242300, v8:12018
Change-Id: I7bc9d00a4fba3101e7ee68695961d1b543268c4e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3138202
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76644}
This fixes the registered {protected_load_pc} to (always) point to the
actual load instruction. If {dst != src} we would emit a register move
before the load, and the trap handler would then not recognize the PC
where the signal occurs, leading to a segfault.
R=thibaudm@chromium.org
Bug: chromium:1242300, v8:12018
Change-Id: I3ed2a8307e353fd85a7ddedf6ecb73e90a112d32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3136454
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76642}
Removes outdated type-error throwing on TypedArray.prototype.set
when the first argument is a number.
Bug: v8:11294
Change-Id: Ida3a46dec154b645620e2b064ded7a18de238649
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3136773
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76631}
When an attempt to parse a huge string to a BigInt fails, then
including the entire string in it makes the exception's message
unwieldy, so this patch puts only the first 1000 characters of
such invalid strings into the exception message.
Bug: chromium:1245239
Change-Id: I2c62f0d34256653ba67da9666e8c5a1a4bbe0599
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3133142
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76619}
- Disable automatic module file extensions for the test
- Use uncommon name suffix to prevent accidental loading of an
existing file
Change-Id: I26c1092a1e559cbbebce442a8d5ff3fb6dd5aa84
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3122145
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76616}
%TypedArray.prototype% methods that receive a user callback
fn should not break in the mid-way of the iteration when the
backing array buffer was been detached. Instead, the iteration
should continue with the value set to undefined.
Notably, %TypedArray.prototype%.filter was throwing when the
backing buffer was detached during iteration. This should not
throw now.
Refs: https://github.com/tc39/ecma262/pull/2164
Bug: v8:4895
Change-Id: Ia7fab63264c8148a11f8f123b43c7b3ee0893300
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3066941
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76611}
Bug: v8:7790,v8:12149
Change-Id: I0c23b2c1126b2a950efe848973618407f64afeb7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3132268
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76601}
Bug: chromium:1209444
Change-Id: I4ec16a718061063dc01ec0d7c4a397c220e684c0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3127718
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76585}
The log test checks for log positions, which may change when background
serialization / background compilation are enabled.
Fixed: v8:12117
Change-Id: I193c9c23e016fad1e3f06a9f377bb53db84a6988
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3129421
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76573}
If a stack overflow occurs inside the regexp parser, propagate that
information to the parser.
Bug: v8:896,chromium:1243989
Change-Id: I5ced27ff968ad97764e156643e1980b3a722af1a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3127717
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76568}
Land some of the tests for Temporal.PlainDate
All marked as FAIL at this stage.
Bug: v8:11544
Change-Id: I004b7cb34effe1de1735b61c7ac749ae3c8e9bf7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3085624
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76551}
Land some of the tests for Temporal.Instant
All marked as FAIL at this stage.
Bug: v8:11544
Change-Id: I79d14df47248c708e5d73a0e00e3f7973c521d16
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3086903
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76550}
Port 732f394c5d
Original Commit Message:
StaGlobal didn't write the accumulator, but the baseline implementation
assumed that it could preserve the accumulator by taking the return
value of the StoreGlobalIC. This almost always worked, except for
setters on the global object.
Fix this by marking StaGlobal as clobbering the accumulator, same as
StaNamedProperty (StaNamedProperty needs to do this anyway to avoid
inlined setters from needing to create accumulator-preserving frames;
StaGlobal would have needed the same thing if we'd ever inlined setters
for it).
Also, add a new debug scope, EnsureAccumulatorPreservedScope, to the
baseline compiler, which checks if the accumulator value is preserved
across non-accumulator-writing bytecodes. This found a (benign) bug with
ForInPrepare, so fix that too.
R=leszeks@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: Id8ada05abeb1a9c7e8a16936c35be9d652c4e8b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3124529
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#76537}
Optimisation affects both reachability and tier-up, so disable it for
the flushing tests.
This should de-flake the Numfuzz bots.
Change-Id: I87c479f216eae2d801e7a0dc665e7325bd1b6bd8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3123415
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76526}
StaGlobal didn't write the accumulator, but the baseline implementation
assumed that it could preserve the accumulator by taking the return
value of the StoreGlobalIC. This almost always worked, except for
setters on the global object.
Fix this by marking StaGlobal as clobbering the accumulator, same as
StaNamedProperty (StaNamedProperty needs to do this anyway to avoid
inlined setters from needing to create accumulator-preserving frames;
StaGlobal would have needed the same thing if we'd ever inlined setters
for it).
Also, add a new debug scope, EnsureAccumulatorPreservedScope, to the
baseline compiler, which checks if the accumulator value is preserved
across non-accumulator-writing bytecodes. This found a (benign) bug with
ForInPrepare, so fix that too.
Fixed: chromium:1242306
Change-Id: I220b5b1c41010c16ac9f944cbd55d2705c299434
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3122325
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76525}
Land some of the tests for Temporal.Duration
All marked as FAIL at this stage.
Bug: v8:11544
Change-Id: I4696edee7a2345133ed13c25aa720febe1f8fc69
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3087363
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76524}
This CL introduces a d8-only flag --expose-fast-api which enables the
test FastCAPI object if the --turbo-fast-api-calls flag is enabled. It
also disables --stress-snapshot, which is incompatible with fast calls.
Bug: v8:12137
Change-Id: I01e8321726b78be660fd6554225999bfc94006c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3117485
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76505}
This CL implements early SyntaxErrors for regular expressions. Early
errors are thrown when a malformed pattern is parsed, rather than when
the code first runs.
We do this by having the JS parser call into the regexp parser when
a regexp pattern is found. Regexps are expected to be relatively
rare, small, and cheap to parse - that's why we currently accept that
the regexp parser does unnecessary work (e.g. creating the AST
structures).
If needed, we can optimize in the future. Ideas:
- Split up the regexp parser to avoid useless work for syntax validation.
- Preserve parser results to avoid reparsing later.
Bug: v8:896
Change-Id: I3d1ec18c980ba94439576ac3764138552418b85d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3106647
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76502}
In a follow-up CL, the backing stores will, when the sandbox is enabled,
be referenced from V8 objects through offsets rather than raw pointers.
For that to work, all backing stores must be located inside the virtual
memory cage. This CL prepares for that.
Bug: chromium:1218005
Change-Id: Ibb989626ed7094bd4f02ca15464539f4e2bda90f
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3114136
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76486}
stress-concurrent-inlining has a negative implication for
lazy-feedback-allocation. So add lazy-feedback-allocation as
incompatible flag with stress-concurrent-inlining.
Bug: v8:12088, v8:11947
Change-Id: Ia8ff66c595f6c6288b44f7a066729ace0d7ad9d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113630
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76483}
We were overwriting the shift Register, instead, we should be using the
tmp_shift register.
Bug: chromium:1242689
Change-Id: I732c9c1f8a43401ce003b22893db9e39dfac3817
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3116115
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76466}
The fast_call_count getter in d8 was not properly initialised as
throwing when called as a constructor. As a result, it was possible
to pass a new object as its `this` and then attempt to "unwrap" it,
resulting in reading OOB in the new object. This CL also strenghtens
slow_call_count and reset_counts and adds a regression test.
Bug: chromium:1241464
Change-Id: I9b6e9a4e38a974dc111a53b911c73514c30de9df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3110369
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76426}
The skipped tests have been flaking on the last
ten runs on V8 NumFuzz - debug.
Bug: v8:11826
Change-Id: I925c8e581b34c1b08fb295856278e506b8d62f26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3103305
Auto-Submit: Almothana Athamneh <almuthanna@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76403}
Operator::kEliminatable has the unfortunate consequence that depending
on surrounding code, the allocating builtin call could get scheduled
before the max length check, causing a crash instead of a trap.
Fixed: chromium:1239954
Change-Id: Ice2e3e4f67e8fce44a886c0079e0e31f124c02b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3103315
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76385}
This fix consists of 2 parts:
a) Fix async hooks:
- Allow initialising the promise hook properties
- Do not call async hooks if we're overflowing the stack
b) Avoid some more recursion when reporting the stack trace
Bug: chromium:1240723
Change-Id: Icedfc8b48655bacc3f79591944e3869b85f1c4de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3103321
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76383}
The NumFuzz fuzzers need to make use of this flag to ignore
Mjsunit exceptions and other exceptions. The flag ignores
the exit code 1.
R=clemensb@chromium.org
R=cbruni@chromium.org
Bug: v8:11826
Change-Id: Ic0878078edec7292e43cdb18dd6fb32f7bbad12c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3103310
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76376}
After building V8 using Clang (./out/x64.release/v8_build_config.json
says that "is_clang" is true), I could reproduce the referenced bug
report locally. Replacing the getMinutes() calls with getUTCMinutes()
calls fixed the test failure.
Signed-off-by: Darshan Sen <raisinten@gmail.com>
Bug: v8:11200
Change-Id: Ia36be481f2c8728380d550ead856ef8e51b1069c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3093362
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76367}
Don't create DataField and FastDataConstant access infos with a kNone
field representation. Instead return Invalid.
Bug: chromium:1239601
Change-Id: I4df7aa298974f9dcd650ead50aaa349c84feb487
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097463
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76343}
The validation was too strong in the case where the incrementation
produces type None.
Bug: chromium:1236716
Change-Id: I948b370594fa7dad1ba6e5b951f473855bf1346b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097865
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76338}
This is a reland of a3b2c4ec81
The fix is in PS3, for UBSan. We use WriteUnalignedValue for
potentially unaligned memory writes.
Original change's description:
> [wasm][diagnostics] Support WasmCode in gdb JIT integration
>
> - Add new enum WASM_CODE to JitCodeEvent::CodeType
> - Use AddressRegion instead of AddressRange (remove the latter)
> - Change CodeDescription constructor to take an AddressRegion,
> both JIT_CODE and WASM_CODE use this
> - Add a simple mjsunit test that sets --gdbjit to check that
> we don't crash.
> - Add a api test for adding WASM_CODE
>
> Bug: v8:11908
> Change-Id: I6e87fadc2df67978144d78caf9800c3982bc3705
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067754
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#76271}
Bug: v8:11908
Change-Id: I5ded6d01cff40803b2f70525163f760edcf97165
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3093506
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76327}
The {CodeSpaceWriteScope} in {InstanceBuilder::Build} was kept open
while processing imports, which could compile another wasm module via
{compiler::ResolveWasmImportCall} and
{WasmEngine::SyncCompileTranslatedAsmJs}. This leads to errors since
{CodeSpaceWriteScope}s for different modules cannot be held open at the
same time.
This CL fixes that by only opening the {CodeSpaceWriteScope} for the
actual compilation of import wrappers.
Drive-by: Only call {ProcessImports} if there are imports to be
processed, to avoid some of the overhead of {ProcessImports} and
{CompileImportWrappers}.
R=jkummerow@chromium.org
Bug: chromium:1239522
Change-Id: Ifbaf64a4be92088ae4a3fd7e9700a33397b2a967
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097283
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76311}
Bug: v8:12008
Change-Id: I2e1d918a1370dae1e15919fbf02d69cbe48f63bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3089095
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76308}
The static limit didn't account for possible S128 elements.
This patch makes the limit element type specific.
Fixed: chromium:1237024
Change-Id: Ic1e37656e2882c0eb7ea6400c83e4094eb747e88
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097269
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76303}
- Remove flag --block-concurrent-recompilation and its implementation,
including %UnblockConcurrentCompilation.
- Rewrite tests that used it in terms of the primitives introduced in
my previous CL:
https://chromium-review.googlesource.com/c/v8/v8/+/3071400/
- Remove "sync"/"no sync" arguments from %GetOptimizationStatus,
assertOptimized, etc. These are now always "no sync": they don't
do any magic.
- Remove "if %IsConcurrentRecompilationSupported then quit" from some
tests in favor of --concurrent-recompilation in their Flags line.
Bug: v8:12041, v8:7790
Change-Id: I966aae4fec85e6f9e7aeed2ba2c12e9198a3991f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3077149
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76298}
This reverts commit a3b2c4ec81.
Reason for revert: UBSan https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8839060153390139249/+/u/Check/gdbjit
Original change's description:
> [wasm][diagnostics] Support WasmCode in gdb JIT integration
>
> - Add new enum WASM_CODE to JitCodeEvent::CodeType
> - Use AddressRegion instead of AddressRange (remove the latter)
> - Change CodeDescription constructor to take an AddressRegion,
> both JIT_CODE and WASM_CODE use this
> - Add a simple mjsunit test that sets --gdbjit to check that
> we don't crash.
> - Add a api test for adding WASM_CODE
>
> Bug: v8:11908
> Change-Id: I6e87fadc2df67978144d78caf9800c3982bc3705
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067754
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#76271}
Bug: v8:11908
Change-Id: Ic1a74a9239e8ef6107efd36f61c089ae6bfc5b6c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3093365
Auto-Submit: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#76274}
- Add new enum WASM_CODE to JitCodeEvent::CodeType
- Use AddressRegion instead of AddressRange (remove the latter)
- Change CodeDescription constructor to take an AddressRegion,
both JIT_CODE and WASM_CODE use this
- Add a simple mjsunit test that sets --gdbjit to check that
we don't crash.
- Add a api test for adding WASM_CODE
Bug: v8:11908
Change-Id: I6e87fadc2df67978144d78caf9800c3982bc3705
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067754
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76271}
d8 throws on unhandled rejected Promises since
https://crrev.com/c/2238569 so no special handling beyond throwing in
the async hooks themselves is needed.
Drive-by-fix: Use v8::Isolate* as local variable.
Bug: chromium:1238467
Change-Id: I271720cd9cfd1d30b58b5407c700b0f730910968
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3090333
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76255}
We now have %FinalizeOptimization() to block until all concurrent
compile jobs are done.
Bug: v8:7790,v8:12004
Change-Id: Ibb9955be06957b3f395b680e9be570c7c3ec0dcb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3086478
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76231}
One of the subtests relies on that.
R=jgruber@chromium.org
Bug: v8:12069
Change-Id: I648a766baf4d977f4df607754f666bd9e9102168
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3086473
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76218}
... which didn't properly handle negative Smi indices with
JSTypedArray receivers.
The logic was broken by the spec violation fix
https://chromium-review.googlesource.com/c/v8/v8/+/2972727
Bug: chromium:1227476, chromium:1209405
Change-Id: I9bfa57d56bebccad00ed29666489f2003694e0a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3086472
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76217}
Re-enable the creation of elements transition groups in
JSHeapBroker::ProcessFeedbackMapsForElementAccess. This turned out to be
quite important for performance.
Bug: v8:7790,v8:12031
Change-Id: I4d24837a668a5f7e78a5078212a7dc34b767d703
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3085262
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76215}
All marked as FAIL at this stage.
Bug: v8:11544
Change-Id: I6e4346a57aa3df054d2ef5bd353544fba7fd855b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3044350
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76211}
This CL adds back the 8-byte element types and extends the fast API
by hiding the unaligned memory reads performed for them.
Bug: chromium:1052746
Change-Id: Ide49ce6bd2c77b9d2d544ca2df47b5f95c93eaa9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056988
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76207}
This test depends on the profiler which runs in a separate thread and
there is not incentive to control exact timing here to get the same
predictable results on every run.
Bug: v8:12066
Change-Id: I2da8eac97f3e8bf5f2158063f14063a0e321e891
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3084371
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76192}
Some tests want to invalidate part of the VM state after an optimization
has consumed the old state but before the code is installed.
The existing mechanism for this is --block-concurrent-recompilation
and %UnblockConcurrentRecompilation(). The former suspends optimization
right after PrepareJob, before the background ExecuteJob phase. The
intrinsic can then be used to unblock it again.
This was good enough so far because the main "consume" work used to
happen on the main thread. With concurrent inlining this is no longer
true and we need something else.
This CL introduces three intrinsics:
%DisableOptimizationFinalization turns off automatic finalization of
background optimizations.
%FinalizeOptimization() can then be called at an appropriate time to
manually finalize (and thus install) the code and reenable automatic
finalization.
In case one wants to perform some action on the main thread after the
concurrent optimization has finished but before it is finalized, one can
do so with the help of %WaitForBackgroundOptimization() (see tests).
In a followup CL I'm removing the old mechanism since it now seems
redundant.
Bug: v8:12041, v8:7790
Change-Id: Ib7195789105922eb7e4bff86dc5bc11e96a4f97b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071400
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76190}
Since array.new_with_rtt implicitly introduces a loop, we should mark
any loop including this instruction as non-innermost.
Bug: chromium:1236958
Change-Id: I2d92b5fdba748df0e4ac1d6cbc524428b1042578
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3080574
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76178}
We currently print reference type indices as unsigned LEB. This will not
work properly for large indices (>=64), as they will be interpreted as
negative indices when read back. They may also alias with builtin types.
In this CL, we fix this by defining builtin types as negative numbers.
We add positive byte constants that can be used in function bodies.
We adapt wasm-module-builder and tests to the above changes.
Bug: v8:7748
Change-Id: I4dfaa65d4cbf77a6731ca2283148bd842ea5c56b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3080569
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76176}
Check that the tag argument matches the exception's own tag, and throw a
type error if not.
R=jkummerow@chromium.org
Bug: chromium:1237751, v8:11992
Change-Id: Ia404b83c202a247791583f0252833c36801e9ac4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3081523
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76175}
This is a partial fix to mitigate immediate issues. The code needs some
overhaul to match the recent spec changes.
Drive-by-fix: Partially update comments to match spec
Bug: v8:11949
Change-Id: I6b03d38c758176e29e8951af21c43d030bbb684d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3075360
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76172}
Excluded keys should not be performed with GetOwnPropertyDescriptor on
source object in CopyDataProperties.
The key values fetch in CopyDataProperties might be arbitrary kind. It
may be smi, string, and symbol. Yet the proxy keys collected by
KeyAccumulator are not expected types for numeric keys. Those keys
should be converted to expected types.
Also updates a typo in comments of
BytecodeGenerator::BuildDestructuringObjectAssignment. The elements in
rest_runtime_callargs should be [value, ...excluded_properties].
Refs: https://tc39.es/ecma262/#sec-copydataproperties
Bug: v8:11532
Change-Id: If71bfedf8272ce8405e8566a016fae66b3007dd9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060275
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76171}
Design doc: https://bit.ly/36MfD6Y, section "Improving Computational
Complexity of CSALoadElimination".
We optimize CsaLoadElimination::AbstractState::KillField() by
fine-graining AbstractState. We now represent it with 6 maps
corresponding to (object kind, offset kind) pairs. This makes it
possible for KillField() to manipulate the state faster. For more
information consult the above design doc.
Bug: v8:11510
Change-Id: I7d991cd47f946edb20e746bc7e6792ae3c70004f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3038521
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76165}
Adds a minimum estimated size.
Data suggests that estimated instruction size (+ relocation info size)
is linear to bytecode array length. This CL adds a constant for this
equation. The ratio remains the same.
This is important, because we want to increase success rate of
estimation when compiling on-heap.
When off-heap, we round up the assembler buffer to 4kB, so this CL
will only impact JS functions with more than 585 bytecodes, i.e, the
new added constant will be negligible.
Note: Relocation info (for Sparkplug) is usually so small that it is
not useful to have a separate zone for this.
Bug: v8:11872
Change-Id: I789e72f80b970d1f541965e7ae808b61c8174326
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069155
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76144}
C++ frames can get quite big in sanitizer builds. In the linked bug it
was an ASan debug build, which overflowed the stack by more than 8kB
just from C++ frames (when entering the runtime, there was no overflow
yet).
Hence increase the allowed stack overflow a bit for sanitizer builds,
from 8kB to 32kB.
R=jkummerow@chromium.org
Bug: chromium:1236560
Change-Id: I119fdb859f7ab5e6a0a4174cf79f0a16baa39432
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3078359
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76142}
So that it is possible to differentiate modules in the stack trace even
when they are anonymous.
R=kimanh@chromium.org
Bug: v8:11808
Change-Id: I12a1f07accdf62c404052f32624e9914381a7451
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3074472
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76141}
Firstly, the fast path checking for applicability of the equality
"A/B = 0 with remainder A" must use the condition "A<B", not "A<=B".
Secondly, *all* early return paths must ensure that enough padding
'0' characters are written.
Fixed: chromium:1236694
Bug: v8:11515
Change-Id: I3fa7e17f5f3969ddbb5417b53abf3bff3fc1355b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3075365
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76139}
This patch makes V8 accept the binary format produced by Binaryen
after https://github.com/WebAssembly/binaryen/pull/3933 when the
--experimental-wasm-gc-experiments flag is present. The explicit
inheritance information is not used for anything. Validation is
performed only insofar as explicit supertypes must be valid types.
Bug: v8:7748
Change-Id: Id5b5050aa03591281632e3a2a161aa93422e10bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071406
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76135}
This was handled in JS but not in C++.
Bug: chromium:236703, v8:11025
Change-Id: Ic9adc4ceb4d2af2614427fec459c3e950654572f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3074460
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76125}
Maximum frame size (in bytes) is used to check for stack overflows
in the prologue.
The maximum number of call arguments is pre-calculated and included
in this check. However the count was added to the frame size wihout
converting the count to bytes, resulting in inaccurate stack overflow
checks.
Bug: chromium:1235182
Change-Id: I21bca4e183fccfd055f2f1d5a40b71651c14b911
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071399
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76090}
These should be reenabled when the underlying issue is fixed.
Bug: v8:7790,v8:12031
Change-Id: Id950cceaa10209b17c2857d61183a2394638d6fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3068951
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76078}
Add support to flush only baseline code. FLAG_flush_baseline_code
controls if baseline code is flushed or not and FLAG_flush_bytecode
controls if bytecode is flushed or not. With this CL it is possible
to control if we want to flush only bytecode / only baseline code / both.
This also lets us have different heuristics for bytecode and baseline
code flushing.
Bug: v8:11947
Change-Id: Ibdfb9d8be7e7d54196db7890541fa0b5d84f037e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060481
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76075}
Invalid ref construction (should assume a memory fence), and invalid
unconditional use of an optional ref.
Bug: v8:7790,chromium:1236303,chromium:1236307
Change-Id: Id0a12222d3d29a0728290ad5269da0946647a5ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3070698
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76074}
Also introduce a separate error type for WebAssembly.Exception,
since the properties should not be added to RuntimeError.
R=jkummerow@chromium.org
Bug: v8:11992
Change-Id: I8f4ae0da9a95184366e07dc43e58a5a9ff4382ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3055304
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76061}
Based on a CL by mvstanton@.
Bug: v8:7790,v8:12030,v8:12031,v8:12041
Change-Id: I58b75bd96c724a99133bec7d3bd6cf4e0c9be6d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059683
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76055}
stress_flush_bytecode controls stress flushing of both bytecode and
baseline code. So rename the flag to better reflect its functionality
Bug: v8:11947
Change-Id: Ie6c124a476c3a7c6eabd1d75de030ee15fe78e32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3062567
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76043}
Previously, when the Load IC saw a deprecated map, it would migrate to
the new map but not update the feedback vector. This would lead to a
deopt the next time the same object was seen.
With this CL, the feedback vector will be updated to the target of the
deprecated map. In order to do this, we need to mark the IC for
recomputation. Without that call, the map and handler would look the
same to IC::UpdatePolymorphicIC amd would decline to update, causing
the IC to go megamorphic instead.
Bug: v8:10816
Change-Id: I0dcf97fb278bc0b167df6ce24d5db179f599f535
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3032983
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Kevin Babbitt <kbabbitt@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#76042}
Regressed in crrev.com/152ecad8cd4d170e4091a79eaa8d70d10d94734d.
Fixed: chromium:1234931
Change-Id: I8f2b603a914fccaeaeb3dcffa63070cf8fb6f0e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3064604
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76033}
