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}
... by only depending on "relevant" results for predicates.
Bug: v8:7790, v8:12173
Change-Id: I60b33a3a05197ca7e6d6a36e85c63fd7a48ee931
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3143994
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76686}
... as the main thread might change its contents.
Bug: v8:12174, v8:7790
Change-Id: I66b2cafc7ddc9b387223693595a9d810b272d7b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3141586
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76685}
In order to deprecate different default flags, this sets the flag
passed on the standard runner now also on numfuzz.
No-Try: true
Bug: v8:12177
Change-Id: I3fb6872643f5bfad71362f22a804d22907641c84
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3143992
Reviewed-by: Almothana Athamneh <almuthanna@chromium.org>
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76679}
We need to check whether ephemeron key is fully constructed to sync the
mark bit before checking it.
Bug: chromium:1246730
Change-Id: I3ba69898202c1df94833a0bc7442b2be0e61694e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3143993
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76678}
Remove the BaselineData intermediate structure for baseline code, and
write the baseline Code object into the SharedFunctionInfo directly. We
still need a pointer to the BytecodeArray/InterpreterData, so re-use the
Code object's deoptimization data slot for this (baseline code doesn't
have deoptimization data).
A consequence of this is that the BytecodeArray pointer becomes
immutable when there is baseline code. This means that we cannot install
a debug BytecodeArray while baseline code is active (we have to flush it
first), and we can't tier-up code with debug BytecodeArray to baseline.
Change-Id: I53b93ec4d4c64b833603d7992f246982fcd97596
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3118548
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76675}
Adds a USE(...) around a std::accumulate which appears to have nodiscard
on it in MSVC builds. Probably only manifests with debug flags on as
otherwise code is not compiled.
Change-Id: I78f4f2c07161598336fedcdd4a204379c4deb81b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3141579
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76671}
It works like --stress-concurrent-inlining but instead of throwing
away the produced code it attaches it to the function as usual. This
mode will be used for fuzzing.
Bug: v8:7790
Change-Id: I010cbb7ab7ec29fccfa561eaff72e66c7444239f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3140602
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76669}
.. another MakeRef vs. MakeRefAssumeMemoryFence spot.
Bug: v8:7790,chromium:1246465
Change-Id: I587538f5756896036aad5db4939a462c01d4cc2f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3141580
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76668}
The test should be enabled once reentrancy is supported.
Bug: v8:11382
Change-Id: Ifb90d8a6fd8bf9f05e9ca2405d4e04e013ce7ee3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3138201
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76667}
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}
HeapBase::Terminate must consider newly created CrossThreadPersistent
when evaluating whether to conitnue the loop. This allows for catching
one off creations in destructors but will still crash for
>kMaxTerminationGCs chains.
Bug: chromium:1245519
Change-Id: I264f1b8f0de9f0bfeb66ca6b14c41faf15e4340c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3140606
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76659}
Before this patch, both key and value of an ephemeron pair was always
considered to be GarbageCollected objects.
This patch adjusts the snapshotting mechanism to accomodate that
values may not be GarbageCollected objects and must thus be eagerly
traced for visibility and edge creation.
In practice this only shows up in Blink when associating an existing
wrappable with a wrapper in a non-main world, e.g., through an
extension. In this case, DOMWrapperMap keeps the wrapper value through
a TracedReference in the ephemeron map with the existing wrappable as
key. The semantics are intended to be general ephemeron semantics,
i.e., value needs to be kept alive when the key is alive. This is
visualized in DevTools as the main wrapper/wrappable pair (which is
merged into a single node for the snapshot) retaining the non-main
world wrapper.
Bug: chromium:1245894
Change-Id: Ibfa6722f20c76f94c310f9a040f0d3d4b9083bbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3140601
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76658}
PretenureAllocationSite didn't check whether the given object is in new
space or not. Once given an object in old space, PretenureAllocationSite
tried to find a memento for it which didn't exist and crashed.
This CL adds a bailout for objects not in new space as there is no
memento and nothing to be done.
Bug: chromium:1244333
Change-Id: Ic26a6f5994ef9942decda69bb8a23fb730bf945c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3140604
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76656}
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}
.. since it is now enabled by default.
Bug: v8:7790,v8:12142
Change-Id: Ia13e5ef9c1224b02dfe635c5fcd91e7a0346f5ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3138196
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76653}
Rolling v8/build: 1dfc04f..5c32531
Rolling v8/buildtools: 9e8b0c9..7ea3a87
Rolling v8/buildtools/third_party/libc++abi/trunk: 9f0517e..7de86cb
Rolling v8/buildtools/third_party/libunwind/trunk: 6474ba4..edf77b2
Rolling v8/third_party/aemu-linux-x64: LrM1UivUqag71JX4WdAnr5pc_zp92frKvtN6GhDs2zEC..zV70YxspSldB66kzaPKeo6zR_1yozZLp4bpWWR8dWRQC
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/d9a9ebb..2331f08
Rolling v8/third_party/depot_tools: ae44ef1..8d07f5a
Rolling v8/third_party/instrumented_libraries: ea83816..47226fa
Rolling v8/tools/luci-go: git_revision:e08764bfcf2e87425a025e3a1d196c5740385da2..git_revision:7f42370cb3b75398bdb9ae0aabe215a70d40cd31
Rolling v8/tools/luci-go: git_revision:e08764bfcf2e87425a025e3a1d196c5740385da2..git_revision:7f42370cb3b75398bdb9ae0aabe215a70d40cd31
Rolling v8/tools/luci-go: git_revision:e08764bfcf2e87425a025e3a1d196c5740385da2..git_revision:7f42370cb3b75398bdb9ae0aabe215a70d40cd31
TBR=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: Ic35c01b8f299bcb8b0a53b99d08aba7fe161d2a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3138531
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#76649}
This CL takes advantage of the z15 `load byte reverse element`
instruction to optimize Simd LoadLane opcodes.
On the simulator we only run `load element` as reversing is
not required.
Change-Id: I038535f7e038bed7972844806644f50519d4919c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3138212
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#76648}
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}
