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}
