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}
