If a method happens on the main thread and only on the main thread
(i.e. it will never be run on the background), it is safer to use
non-atomic accessors as TSAN will give warnings if we use them
improperly.
As a drive-by, pass the isolate as a parameter where it was readily
available as it saves us from getting the isolate from the object later
on.
Bug: v8:7790
Change-Id: Id9bdd69254edc60b0331a32fccf1479a95b7d286
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2732669
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73251}
The recent change crrev.com/c/2712755 got a bounds check wrong,
causing an invalid use of the lookup iterator.
Bug: v8:1185072
Change-Id: I3138d266cb4b2482dcb5078fb025bbfc43dd2940
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742196
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73250}
- Renames StackParameterCount to ParameterSlotCount, to avoid
confusion between slots and parameters, which are not in general
equivalent.
- Similarly, renames StackReturnCount to ReturnSlotCount.
- Adjusts the result of GetFirstUnusedStackSlot to return one more
than the last slot of the argument area, not including padding.
- Renames GetFirstUnusedStackSlot to GetOffsetToFirstUnusedStackSlot
to reflect that the result is an offset from callee to caller
frames.
- GetReturnsOffset is a little clearer, with adjustment for the
different semantics of GetFirstUnusedStackSlot.
- Renames 'optional_padding_slot' and 'first_unused_stack_slot'
variables in Tailcall codegen to reflect that these are offsets.
Bug: v8:9198
Change-Id: Ib73c52710dc1f3ead640d488a6fdeb605b7b665e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2700099
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73242}
This is a (manual) reland of ba87518e071a75fb951b490d3f75a87ca715cc23
It is unchanged, except to rebase around a merge conflict.
TBR=neis@chromium.org, jgruber@chromium.org
Bug: v8:9198
> [codegen][frames] Generalize argument padding slot code
>
> - Removes kPadArguments boolean.
> - Changes ShouldPadArguments to ArgumentPaddingSlots to reflect
> that on some architectures more than 1 padding slot may be needed.
> - Adds AddArgumentPaddingSlots and ShouldPadArguments convenience
> functions.
>
> Bug: v8:9198
>
> Change-Id: Iba87518e071a75fb951b490d3f75a87ca715cc23
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679109
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72605}
Change-Id: I2a9022964d3bafe68c5c1e7de0ae7e837dd5c2e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2740457
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73241}
This is a reland of 352b9ecbdb
The test/fix CL has been merged in, as the fixes to return slot
accounting are needed to fix Arm64 issues turned up by the fuzzers:
https://chromium-review.googlesource.com/c/v8/v8/+/2644139
The reverted fix for Wasm return slot allocation is added in
patchset #2, to avoid fuzzer issues that it fixed:
https://chromium-review.googlesource.com/c/v8/v8/+/2683024TBR=neis@chromium.org
Original change's description:
> Reland "Reland "[compiler][wasm] Align Frame slots to value size""
>
> This is a reland of 1694925c72
>
> Minor fix to linkage for constexpr.
>
> TBR=ahaas@chromium.org,neis@chromium.org
>
> Original change's description:
> > Reland "[compiler][wasm] Align Frame slots to value size"
> >
> > This is a reland of cddaf66c37
> >
> > Original change's description:
> > > [compiler][wasm] Align Frame slots to value size
> > >
> > > - Adds an AlignedSlotAllocator class and tests, to unify slot
> > > allocation. This attempts to use alignment holes for smaller
> > > values.
> > > - Reworks Frame to use the new allocator for stack slots.
> > > - Reworks LinkageAllocator to use the new allocator for stack
> > > slots and for ARMv7 FP register aliasing.
> > > - Fixes the RegisterAllocator to align spill slots.
> > > - Fixes InstructionSelector to align spill slots.
> > >
> > > Bug: v8:9198
> > >
> > > Change-Id: Ida148db428be89ef95de748ec5fc0e7b0358f523
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2512840
> > > Commit-Queue: Bill Budge <bbudge@chromium.org>
> > > Reviewed-by: Georg Neis <neis@chromium.org>
> > > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#71644}
> >
> > Bug: v8:9198
> > Change-Id: Ib91fa6746370c38496706341e12d05c7bf999389
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2633390
> > Commit-Queue: Bill Budge <bbudge@chromium.org>
> > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#72195}
>
> Bug: v8:9198
> Change-Id: I91e02b823af8ec925dacf075388fb22e3eeb3384
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2640890
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72209}
Bug: v8:9198
Change-Id: Ia5cf63af4e5991bc7cf42da9972ffd044fc829f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2733177
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73238}
Bump wasm-spec-tests version since the opcodes have also changed.
Also add missing opcodes to wasm-module-builder.js.
Bug: v8:6020
Change-Id: I60dcf1b300a5278aab5e1814c9ebf4ee85c60053
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2728432
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73233}
0x7b is the encoding for SIMD v128 types, so it will become valid when
we turn SIMD on by default. Use kWasmStmt (0x40) instead, it is not a
valid in the function signature position (which requires a value type).
Bug: v8:11511
Change-Id: Ife152e81d831a059a0122f9255897d97b5dc4fc9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739054
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73232}
This CL is part of a series that makes SwissNameDictionary available
as a new property backing store. Currently, the flag
v8_dict_mode_prototypes allows selecting between NameDictionary and
OrderedNameDictionary as the backing store used for all dictionary
mode objects. This series of CLs changes this such that enabling the
flag causes SwissNameDictionary being used instead of
OrderedNameDictionary. The behavior for when the flag is not set
remains unchanged (= use NameDictionary).
This particular CL just collects many small changes.
Note that the changes this CL makes to literal-objects.cc do not
fix the problems with the enumeration order of computed property
names in classes that currently exist when using OrderedNameDictionary.
This will be fixed separately.
Bug: v8:11388
Change-Id: I6b98f61c395b4f2788407d6a34363ef8863cce9a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2735834
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73224}
... to different attributes or different property kind.
Bug: chromium:1161847, v8:9233
Change-Id: I5a6e1e012c6afcf09ed9da6bbf9f33c1007c3d99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727272
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73220}
This adds the possibility to define non-nullable function tables of heap
types kFunc and user-defined functions. When such table is defined, it
is obligatory to provide an initializer expression after its limits.
Currently, this can only be a function reference.
Changes:
- Change WasmTableObject::raw_type to encode the whole entry type.
- Restructure call_indirect to load the signature only if needed, and
do null checks only if needed.
- Add the requirement to provide an initializer expression for
non-nullable tables in module-decoder.
- Rename "global initializer" -> "initializer expression" everywhere.
- Add table initialization in module-instantiate.
- Edit both the C++ and JS WasmModuleBuilder.
- Add and slightly improve tests.
- Format wasm-module-builder.js.
Bug: v8:9495
Change-Id: I7453ee7d567afd5b5fe48a4f1653513787cfe99a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2732673
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73215}
This adds support for WasmGC objects (structs/arrays) to the
inspector backend. For prettier printing, it also adds support
for reading the "type" and "field" subsections of the "name"
section in Wasm modules.
This patch includes a revert of most of commit
crrev.com/987a7f4ae45ebfc986525075277debdf73001fc2 because
types are more complicated now.
Bug: v8:7748, chromium:1177784
Change-Id: Icec52cbbb32291b0e773b40be6771a678c6ec79b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715193
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73212}
This is a reland of 0c63aa9eee
Fixes the correctness fuzzing BUILD.gn breakage.
Original change's description:
> [ptr-cage] Reserve base registers on x64 (r14) and arm64 (x28)
>
> Also add a V8_COMPRESS_POINTERS_IN_SHARED_CAGE define when pointer
> compression is enabled.
>
> This CL is to get performance numbers for reserving an extra register.
> There is no actual pointer cage yet, and the base register will always
> have the same value as the root register. The pointer decompression code
> is switched to using the base register instead of the root register.
>
> Bug: v8:11460
> Change-Id: I40bae556c2098608fb6fc193a52694e3f54754bd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716075
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73204}
TBR=rmcilroy@chromium.org,jkummerow@chromium.org,leszeks@chromium.org
Bug: v8:11460
Change-Id: Iecf6b783392a384b40ab33e0f4ce13538a8f81ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2737681
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73207}
This reverts commit 0c63aa9eee.
Reason for revert: Breaking clusterfuzz builds
Original change's description:
> [ptr-cage] Reserve base registers on x64 (r14) and arm64 (x28)
>
> Also add a V8_COMPRESS_POINTERS_IN_SHARED_CAGE define when pointer
> compression is enabled.
>
> This CL is to get performance numbers for reserving an extra register.
> There is no actual pointer cage yet, and the base register will always
> have the same value as the root register. The pointer decompression code
> is switched to using the base register instead of the root register.
>
> Bug: v8:11460
> Change-Id: I40bae556c2098608fb6fc193a52694e3f54754bd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716075
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73204}
Bug: v8:11460
Change-Id: Idebf1fc6eeeda880a21d65b6f2c674fa58690bfa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2737812
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/master@{#73205}
Also add a V8_COMPRESS_POINTERS_IN_SHARED_CAGE define when pointer
compression is enabled.
This CL is to get performance numbers for reserving an extra register.
There is no actual pointer cage yet, and the base register will always
have the same value as the root register. The pointer decompression code
is switched to using the base register instead of the root register.
Bug: v8:11460
Change-Id: I40bae556c2098608fb6fc193a52694e3f54754bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716075
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73204}
This is a reland of 77838343d8
No changes in this reland, this wasn't causing the failures, see
https://crbug.com/1163833 for the actual cause.
Original change's description:
> [wasm-simd] Remove add horiz instructions
>
> Bug: v8:6020
> Change-Id: I0605798d03f2e9f9c3c07c49141289889a10a3b0
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727204
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73180}
Bug: v8:6020
Change-Id: I83d59ed800bd73c81cb879b4ba3a5144045c62d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2733663
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73200}
This reverts commit a8b61ef521.
Reason for revert: Looks like it breaks GC stress bot - https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/35880/overview
Original change's description:
> [sparkplug] Change bytecode offset mapping and introduce iterator.
>
> Previously, we recorded pairs of (bytecode offset, sparkplug pc) to
> create a mapping of bytecode offset <-> sparkplug pc.
> These pairs were only recorded after builtin/runtime calls.
> In preparation for deoptimizing to Sparkplug, we need a more precise
> mapping.
> With this CL, we record positions for every bytecode. Instead of storing
> a pair of (bytecode offset, sparkplug pc), we store only the pc,
> calculating the bytecode offset from the index in the mapping table.
> For easier use an iterator to access the mapping is introduced.
>
> Drive-by: Reduce sampling interval in cpu-profiler cctest to get rid of
> flaky failures.
>
> Bug: v8:11420, v8:11429
> Change-Id: I36a9171f43a574eb67880cbca6cf9ff7ab291e60
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720189
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Auto-Submit: Patrick Thier <pthier@chromium.org>
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73186}
Bug: v8:11420
Bug: v8:11429
Change-Id: Ie71e7ce234e7b9ab9a2ec99a983e9900f35baa44
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2735397
Auto-Submit: 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/master@{#73187}
Previously, we recorded pairs of (bytecode offset, sparkplug pc) to
create a mapping of bytecode offset <-> sparkplug pc.
These pairs were only recorded after builtin/runtime calls.
In preparation for deoptimizing to Sparkplug, we need a more precise
mapping.
With this CL, we record positions for every bytecode. Instead of storing
a pair of (bytecode offset, sparkplug pc), we store only the pc,
calculating the bytecode offset from the index in the mapping table.
For easier use an iterator to access the mapping is introduced.
Drive-by: Reduce sampling interval in cpu-profiler cctest to get rid of
flaky failures.
Bug: v8:11420, v8:11429
Change-Id: I36a9171f43a574eb67880cbca6cf9ff7ab291e60
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720189
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Patrick Thier <pthier@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73186}
This is a reland of 6e234e9d76
Fix CFI by adding a BTI instruction at the start of the handler.
Original change's description:
> [wasm][liftoff][eh] Implement catch_all
>
> Inline a catch handler after each potentially throwing call. The handler
> just merges values into the actual catch environment and then jumps to
> the catch body.
>
> This automatically adds support for unwind, which also uses the
> "CatchAll" interface method.
>
> Many tests can be written either with "catch" or with "catch_all".
> Duplicate them to get coverage for both.
>
> R=clemensb@chromium.org
>
> Bug: v8:11453
> Change-Id: I789ad44b8d1e496f026157d5c37a12004a8b37e3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2726497
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73129}
Bug: v8:11453
Change-Id: I84d90877e6227a1966b6347877a9c18e213d9419
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2732023
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73184}
This is similar to the optimization for f32x4 dup + mul in
https://crrev.com/c/2719083. Refactor the pattern-matching code into a
helper function that returns a struct with all the necessary fields to
emit the optimized fmul by element instruction.
Add similar unittests and a negative test as well.
Bug: v8:11257
Change-Id: I79ab0bc783f43397191a54bf6fa736dd4dc8d807
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2728428
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73164}
When retrieving an API accessor function (i.e. either the getter or the
setter) for which the lazy accessor mechanism is used (i.e. where the
actual JSFunction is created lazily and only the FunctionTemplateInfo)
is around, we thus far created a fresh JSFunction every time the
accessor function is requested, but that's observably wrong behavior,
since the accessors are JavaScript objects with identity. We currently
rely on the instantiation cache to guarantee identity, but there's no
reason why we couldn't instead just put the instantiated JSFunction into
the AccessorPair.
Fixing this to only instantiate the lazy accessor pair only once, upon
first time it's requested, coincidentally also simplifies (and fixes)
the API accessor breakpoint machinery. This was previously lacking
support for walking dictionary prototype objects and forcibly
instantiating the lazy accessor pairs with break points. However, all
this magic in the debugger is no longer necessary when we ensure that
the lazy accessor pair component is generally only instantiated once.
Bug: v8:178, v8:7596, chromium:986063, chromium:496666
Change-Id: I41d28378010716c96c8ecf7c3f1247765f8bc669
Fixed: chromium:1163547
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2731527
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73163}
Also add the qualifier `compiler::` to places where it should have been
used in the first place.
Bug: v9:6949
Change-Id: Ib5ca6829cd9d72b1e3047afc92363910c902bbbf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2731529
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73155}
This is a wasm-only test, hence move it to the wasm directory and skip
it in no-wasm builds.
R=ahaas@chromium.org
Bug: v8:11238
Change-Id: I57c9abbb98c3415f4d759372d479e1f61464217f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2731536
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73152}
Fixes gn check error due to include of
test/common/wasm/wasm-macro-gen.h. Also changes common_test_headers dep
from v8_for_testing to v8_internal_headers, since otherwise on windows
the wasm_api_tests binary ends up depending on wee8 and
libv8_for_testing which define many of the same symbols.
Bug: v8:7330
Change-Id: Ib03b860668146f21456729a3d2c5e0d75d8c17d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2729335
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73150}
These simplify production of extra information in stack traces or
dereferencing source maps in processing stack traces. While these
can be managed externally, this can be very complicated in
environments where scripts come from many different sources,
possibly not even under embedder control. Since V8 already has
easy access to this information, it's nice to share it with
embedders.
Bug: v8:11509
Change-Id: Ic5a1685adf4cdf456bdf7191ce815f728cf491e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2724571
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73148}
Wasm SIMD does not have an opcode to multiply a vector by a scalar. In
these cases, Wasm code uses mul(x, shuffle(y, imms)), where the shuffle
is a dup of a single lane in y. Pattern match on this to emit a fmul
(element).
We can do similar pattern match on f64x2 too, that will come in a future
patch.
Bug: v8:11257
Change-Id: I61e8c46b56719a1179c8a6032dbf8a4cc03b40a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2719083
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73141}
Remove sloppy-ness from the CODE_ASSEMBLER_UNARY_OP macros and the
remaining methods.
Bug: v8:6949
Change-Id: I48e2800c6bac558ae4005fa09551a4551c1dbb25
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2725530
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73139}
After deprecation and removal of the old misleading API we re-add
v8::String::IsExternal which returns true for both, external one-byte and
external two-byte strings.
Bug: v8:10641
Change-Id: I4c66d4df891f7180c7a727a45c1fbd254a7f5c02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2726512
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73137}
Tail calls are connected to the end of the graph, so technically they
also constitute loop exits.
Additional Changes:
- In DoReturnCall, change the argument {Node* index_node} into
{Value index_or_caller_value}.
- Rename StackValueVector -> ValueVector.
- Add a test that reveals the bug.
Bug: chromium:1183622, v8:11298
Change-Id: I58f7877f2d03e94f6a281e566829897c3000b890
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727503
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73135}
This reverts commit 6e234e9d76.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20CFI/4795/overview
Original change's description:
> [wasm][liftoff][eh] Implement catch_all
>
> Inline a catch handler after each potentially throwing call. The handler
> just merges values into the actual catch environment and then jumps to
> the catch body.
>
> This automatically adds support for unwind, which also uses the
> "CatchAll" interface method.
>
> Many tests can be written either with "catch" or with "catch_all".
> Duplicate them to get coverage for both.
>
> R=clemensb@chromium.org
>
> Bug: v8:11453
> Change-Id: I789ad44b8d1e496f026157d5c37a12004a8b37e3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2726497
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73129}
Bug: v8:11453
Change-Id: Ica7fa708962d9ae4b9fbf7473963d187062227ca
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727266
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73131}
Inline a catch handler after each potentially throwing call. The handler
just merges values into the actual catch environment and then jumps to
the catch body.
This automatically adds support for unwind, which also uses the
"CatchAll" interface method.
Many tests can be written either with "catch" or with "catch_all".
Duplicate them to get coverage for both.
R=clemensb@chromium.org
Bug: v8:11453
Change-Id: I789ad44b8d1e496f026157d5c37a12004a8b37e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2726497
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73129}
Adds cppgc_headers to v8_internal_headers and fuzzer_support to
lib_wasm_fuzzer_common in BUILD.gn as well as v8_libbase and
v8_libplatform to cctest_headers in test/cctest/BUILD.gn.
Bug: v8:7730
Change-Id: I9759bb0993be779ddfc26668b9e08503ea53bd69
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727501
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73122}
Be explicit about source positions for `Return`s in the
BytecodeGenerator, and only do self-healing explicitly in the
`ReturnStatement` translation, where an end position of
`kNoSourcePosition` is turned into the return position of the
function literal.
This allows us to reason more easily about which `Return`s actually
receive a meaningful source position, and in particular it allows us
to construct the internal `Return`s for `yield` and `yield*` with no
source position attached to them. Previously they'd get the source
position for the implicit (final) return attached to it, which confused
the debugger and led to breakpoints being set in the completely wrong
spot.
Considering the simplified example
```
function* foo(){
var a = 1;
}
```
this would previously generate the following bytecode
```
0 : SwitchOnGeneratorState r0, [0], [1] { 0: @20 }
4 : Mov <closure>, r2
7 : Mov <this>, r3
13 E> 10 : InvokeIntrinsic [_CreateJSGeneratorObject], r2-r3
14 : Star0
13 E> 15 : SuspendGenerator r0, r0-r1, [0]
20 : ResumeGenerator r0, r0-r1
24 : Star2
25 : InvokeIntrinsic [_GeneratorGetResumeMode], r0-r0
29 : SwitchOnSmiNoFeedback [1], [2], [0] { 0: @39, 1: @36 }
33 : Ldar r2
13 E> 35 : Throw
36 : Ldar r2
30 S> 38 : Return <=========================== internal Return
27 S> 39 : LdaSmi [1]
41 : Star1
42 : LdaUndefined
30 S> 43 : Return
```
where everything between offset 4 and 42 corresponds to the implicit
yield at the beginning of every generator function, in particular the
code between 20 and 42 corresponds to that initial yields resumption
logic. Notice how the internal Return at offset 38 gets assigned the
source position of the function literal (the same as the implicit
return at the end). This confuses the debugger quite a bit when trying
to set a breakpoint on the closing brace, since it's going in bytecode
order and will thus discover the `Return` at offset 38 first (matching
the source position 30 it's currently looking for) and setting the
breakpoint there. This `Return` bytecode however is only executed when
the generator is resumed via `GeneratorPrototype.return()`, and it'll
not hit when the developer uses the generator normally, which is not
the desired behavior and extremely confusing (especially since stepping
on the other hand works as expected).
With this patch, we no longer slap a source position (and in particular
not the function literal's return position) onto these internal
`Return`s as you can see from the generated bytecode below:
```
0 : SwitchOnGeneratorState r0, [0], [1] { 0: @20 }
4 : Mov <closure>, r2
7 : Mov <this>, r3
13 E> 10 : InvokeIntrinsic [_CreateJSGeneratorObject], r2-r3
14 : Star0
13 E> 15 : SuspendGenerator r0, r0-r1, [0]
20 : ResumeGenerator r0, r0-r1
24 : Star2
25 : InvokeIntrinsic [_GeneratorGetResumeMode], r0-r0
29 : SwitchOnSmiNoFeedback [1], [2], [0] { 0: @39, 1: @36 }
33 : Ldar r2
13 E> 35 : Throw
36 : Ldar r2
38 : Return
27 S> 39 : LdaSmi [1]
41 : Star1
42 : LdaUndefined
30 S> 43 : Return
```
This also allows us to remove the break position finding hack that was
kept in BreakIterator::BreakIndexFromPosition() for generators and
modules.
Fixed: chromium:901819
Change-Id: If19a6b26e2622d49b6b5e54bf7a162747543f970
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727820
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73119}
Split out all the headers from v8_compiler/v8_compiler_opt and
v8_base_without_compiler into v8_internal_headers since the headers
have inter-dependencies that otherwise make it impossible to satisfy gn
check.
Also adds new v8_header_set torque_runtime_support that exports
src/torque/runtime-support.h separately from the generated headers.
This reduces the number of gn check failures from 169 to 59.
Bug: v8:7330
Change-Id: Ie7ebc894910b7efa02011a74da964e11995c7f4f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712569
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73104}
Add a flag that crashes the process instead of gracefully handling the
abortion of evacuation. The goal of this CL is to check whether we could
get away with simply reporting OOM instead of handling this case.
Change-Id: I6a561ed007c76a111cfb85c454f7f025f07ab9cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2724272
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73097}
For adding stack checks in optimized code, we compute a conservative
estimate of the frame size in the case of a deoptimization. Earlier we
included the size of arguments adaptor frames used when actual arguments
didn't match formal parameter count. Though we don't have an explicit
adaptor frame, we should still include the size of these additional
arguments when computing the frame size.
Bug: chromium:1181240
Change-Id: Ib977c5492bb824762fe62aac5e4ffb1c2c233b86
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2723252
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73094}
This CL sets it so that the actual object size is reported only when
cppgc_enable_object_names is set to true. Otherwise the heap snapshot
merges nodes and the sizes don't make sense.
Also, this will resolve a web test failure for the library.
Bug: chromium:1056170
Change-Id: I32f6552560bdfad4b64c67b21292543978042a81
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2726499
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73092}
Fixes a problem with the inlining of JS-to-Wasm call wrappers into a
surrounding exception handler and re-enables this case.
Bug: v8:11092
Change-Id: I4937838c2b4a199e21f5ac90bee5b8e8de2470be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2678341
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73086}
Add GetOptionsObject/CoerceOptionsToObject for ECMA402 2021
Change Intl.ListFormat / Intl.DisplayNames and Intl.Segmenter
to use GetOptionsObject and keep old API under CoerceOptionsToObject
based on https://github.com/tc39/ecma402/pull/538/files
Test262 tests need to be changed per
https://github.com/tc39/test262/issues/2950
Bug: v8:11466
Change-Id: I5cb9b7aba0556effc76b4005e95c90db1e59d41f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2705696
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73082}
This is a reland of eb4536797e
Original change's description:
> cppgc: Rework testing GC infrastructure
>
> Instead of moving the stand-alone logic to the base heap, allows
> specific heaps to override their stand-alone GC behavior. This allows
> CppHeap to reuse the unified heap bottlenecks and visitors for
> testing. This works as long as any v8 references are empty as there is
> no Isolate attached to the heap in this case.
>
> - Reverts parts of https://crrev.com/c/2716291
> - Relands parts of https://crrev.com/c/2718146
>
> In addition, add tests covering v8::CppHeap and cppgc::Heap.
>
> Bug: chromium:1056170
> Change-Id: I47dc88c7f0e4961a1aadd60da9b05bff4dcfb27a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718612
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73077}
Bug: chromium:1056170
Change-Id: I415c837a7cf275c636172485dc4101c237a7d76b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2723253
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73081}
These were prototyped and not merged into the SIMD proposal.
Bug: v8:10983
Change-Id: I5c30a0e9955ee5602e05d473f0f85be59d124205
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718761
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73080}
This reverts commit eb4536797e.
Reason for revert: Breaks MSAN: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/37053
Original change's description:
> cppgc: Rework testing GC infrastructure
>
> Instead of moving the stand-alone logic to the base heap, allows
> specific heaps to override their stand-alone GC behavior. This allows
> CppHeap to reuse the unified heap bottlenecks and visitors for
> testing. This works as long as any v8 references are empty as there is
> no Isolate attached to the heap in this case.
>
> - Reverts parts of https://crrev.com/c/2716291
> - Relands parts of https://crrev.com/c/2718146
>
> In addition, add tests covering v8::CppHeap and cppgc::Heap.
>
> Bug: chromium:1056170
> Change-Id: I47dc88c7f0e4961a1aadd60da9b05bff4dcfb27a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718612
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73077}
Bug: chromium:1056170
Change-Id: Ieda44c07d08f837a6632f96b8db6d5bec87dd521
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2723216
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73078}
Instead of moving the stand-alone logic to the base heap, allows
specific heaps to override their stand-alone GC behavior. This allows
CppHeap to reuse the unified heap bottlenecks and visitors for
testing. This works as long as any v8 references are empty as there is
no Isolate attached to the heap in this case.
- Reverts parts of https://crrev.com/c/2716291
- Relands parts of https://crrev.com/c/2718146
In addition, add tests covering v8::CppHeap and cppgc::Heap.
Bug: chromium:1056170
Change-Id: I47dc88c7f0e4961a1aadd60da9b05bff4dcfb27a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718612
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73077}
We experimentally globally enable loop unrolling for wasm code. This
might be reverted based on the results of perf bots.
Additional change: Add LoopExitValue to Int64Lowering, plus a small
simplification.
Bug: v8:11298
Change-Id: Iaf2829e80f948d70c5fb6ed7c974db7f59265fa3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718611
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73072}
Wasm tests and wasm fuzzers should not be compiled (and run) if
v8_enable_webassembly=false.
R=machenbach@chromium.org
Bug: v8:11238
Change-Id: I78bbb1d1d98179cac315411b8c2c2ecaee8ede91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2721761
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73071}
This renames more fields holding "ValueKind" or methods operating on
"ValueKind" to contain "kind" instead of "type".
It also renames "is_reference_type" to "is_reference" on both ValueType
and ValueKind, as the "_type" prefix is kind of implicit from the
argument.
R=manoskouk@chromium.org, jgruber@chromium.org
Bug: v8:11477
Change-Id: I7809f1af6e983aebca96e03fe1fbc6ccaa22db72
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718063
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73070}
In https://crrev.com/c/2707170, Liftoff was changed to only store the
ValueKind instead of the ValueType, because we only need to know kind
for code emission. For debugging though, the whole type is useful.
This CL changes the debug sidetable back to store the full type, and
retrieves this information from the decoder.
R=jkummerow@chromium.org
Bug: v8:11477
Change-Id: I08a512d24cdf0955c95f3b9261d68a02a39b9b4e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720302
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73068}
Simd unsupported in simulator and some machines on mips.
Original Commit Message:
As of https://crrev.com/c/2629465, Simd tests cannot pass on
architectures without Simd support. Tests will need to be
re-enabled once Simd support is fully implemented on PPC.
Port: aaacffa1e0
Change-Id: Ic7451211cbe2bfa13952b994ea440189620579cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2717158
Auto-Submit: Liu yu <liuyu@loongson.cn>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#73067}
This was causing DevTools to crush whenever I took a heap snapshot.
Bug: chromium:1056170
Change-Id: Ice7b3039c21a3f902f242299939e92ba0e393c9f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720307
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73065}
This instruction is not in the final SIMD proposal.
Bug: v8:6020
Change-Id: Ifef1b3d58bf660f2d30784f587aed85f327825ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716073
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73058}
VLQ encoding was implemented in TranslationArray and Sparkplug PC <->
bytecode mapping.
This CL introduces new VLQ helper methods used in both.
Bug: v8:11429
Change-Id: I89d9777eab4ad28f08e5957421b63df07e37f9cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704674
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73054}
Change-Id: I86b0d01ed283f97cde2f3d71df68c3a75107c61d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712906
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73051}
Clean-up and slightly unify the CodeEvent tags:
* Remove INTERPRETED_FUNCTION_TAG. It was only used for interpreter
trampoline copies, which are used for
--interpreted-frames-native-stack. However, even actual bytecode
compilation doesn't use INTERPRETED_FUNCTION_TAG, so we can remove
it for simplicity.
* The tag used by the above is now the same as for the bytecode
creation event, i.e. EVAL_TAG, SCRIPT_TAG, FUNCTION_TAG or
LAZY_COMPILE, depending on whether this was a script, and eval, an
eager or a lazy compile (respectively.
* Baseline was also using INTERPRETED_FUNCTION_TAG, so now it does the
same thing as above.
* Existing code is now logged as FUNCTION_TAG rather than
LAZY_COMPILE, because we lost the laziness information.
* The SCRIPT_TAG is set based on the SharedFunctionInfo flags, not
the compilation flags, so that eager inner functions are labelled as
FUNCTION_TAG rather than SCRIPT_TAG.
Bug: v8:11420,v8:11429
Change-Id: I0286002674255ff4ba8f5d865df372a3e2975b16
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2713104
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73047}
Remove most dependencies on v8_wrappers. The remainder all depend on
v8_libbase anyway, so just fold it into that target which removes a gn
check error. Also removes v8_wrappers from the fuzzers where it's not
used.
Bug: v8:7330
Change-Id: I916806b62f8c49cc1d50ef493aa900e30fc623aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716383
Commit-Queue: Dan Elphick <delphick@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73041}
This reverts commit ea818f0733.
Reason for revert: Test failure in Linux64 UBSan https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20UBSan/15251/overview
Original change's description:
> cppgc: Fix testing APIs that enable garbage collection
>
> The APIs require that the CppHeap is moved into a permanently detached
> state that moves the heap out of a no-gc scope.
>
> Bug: chromium:1056170
> Change-Id: I1fc08451b3fdfaa4cfe58e6a1ddbe5dbed7efe5c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718146
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73025}
Bug: chromium:1056170
Change-Id: Id00cb18274cbe7d255e7e95bd9e8e4dbc4b0c6e7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718658
Auto-Submit: Zhi An Ng <zhin@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73029}
The APIs require that the CppHeap is moved into a permanently detached
state that moves the heap out of a no-gc scope.
Bug: chromium:1056170
Change-Id: I1fc08451b3fdfaa4cfe58e6a1ddbe5dbed7efe5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718146
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73025}
- Add a CFunctionBuilder interface to allow adding modifier flags
to argument types. This will be used to support IDL attributes
like [EnforceRange], [Clamp], and [AllowShared]. This CL adds
only the interface, but the actual modifier flags do not exist
yet as they would not be implemented.
- Remove the internals of the old CFunction type inference and
implement it on top of CFunctionBuilder.
Bug: chromium:1052746
Change-Id: I09a7cba07105097517a8426a8eeb891393883ac6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2686686
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Austin Eng <enga@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73024}
This is a partial reland of https://crrev.com/c/v8/v8/+/2601880 .
I think it makes more sense to list ScopeInfos under "(system)" in the
dev tools, like most other V8 internal types.
Change-Id: If85f869e805d7c374fc7584a79155bb4f400e4b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707249
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#73015}
This was staged through a back-merge in v8.9. Also stage it for the
upcoming v9.0 release.
R=ahaas@chromium.org
Bug: v8:8091
Change-Id: Ie9e6d25bbc5d428e5c9128345209f95f2078b733
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715524
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73013}
Design doc: https://docs.google.com/document/d/1AsUCqslMUB6fLdnGq0ZoPk2kn50jIJAWAL77lKXXP5g/
Currently, wasm loop unrolling is disabled by default. We intend to
further investigate its compilation time cost and running time benefits
before enabling it.
Additional changes:
- Introduce LoopFinder::FindUnnestedLoopFromHeader() as a lightweight
loop analysis.
- Move EliminateLoopExit into LoopPeeling and expose it.
- Introduce loop_info_ field into WasmGraphBuildingInterface, fill it
up in Loop().
- Break after encountering the first loop in BuildNestedLoopExits.
- Introduce struct WasmLoopInfo. A WasmLoopInfo vector is instantiated
in ExecuteTurbofanWasmCompilation, passed to BuildGraphForWasmFunction
to be filled up by WasmGraphBuildingInterface, and then passed to
GenerateCodeForWasmFunction to be used in WasmLoopUnrollingPhase.
- Introduce WasmLoopUnrollingPhase and insert it into the wasm
compilation pipeline.
- Fix an issue where exception values were not wrapped in
WasmGraphBuilderInterface.
- Update --wasm-loop-unrolling flag description.
Bug: v8:11298
Change-Id: I4b57cf2ea8520931f60769f843ffd57b3ca6399b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697349
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73009}
This adds a re-compilation of top level functions in
getPossibleBreakpoints if no candidates could be found.
This step is necessary as the GC may remove SharedFunctionInfo about
top-level functions.
Bug: chromium:1137141
Change-Id: I8830438d78751ba318d65f43d790ee98f306a57e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696154
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73008}
It had essentially become a synonym for BytecodeArrayAccessor.
This removes the BytecodeArrayIterator class and renames
BytecodeArrayAccessor to BytecodeArrayIterator.
Change-Id: I79cf8574f3c8804822f90c8f921c17ca7ab85f48
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2715523
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73005}
When calling new WebAssembly.Table, the returned error message refers
accidentally to the WebAssembly.Module() constructor.
There will be a corresponding Chromium CL fixing expected error messages
in WPTs.
R=ahaas@chromium.org
Bug: v8:11356
Change-Id: I57f5e071d5c542615523345283d7c3613fb7a616
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2663155
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72998}
The precise type is only used for validation. For code generation,
knowing the kind is more than enough. Hence, only store and pass the
ValueKind in Liftoff, and not the full ValueType.
R=manoskouk@chromium.org
Bug: v8:11477
Change-Id: Ia42c0fa419f75b508bd2f210c767b631e93d3398
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707170
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72997}
These are headers that are used by the inspector, debugger and other
parts of chrome so they should be in the main v8_headers target.
test-api-interceptors.cc does not use anything from v8-util.h so remove
the include and some other unneeded using declarations.
Bug: v8:7330
Change-Id: Iea1546de3fc2dbc1c41f0dd7109b6c7ef5557045
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716384
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72996}
The arity depends on the exception type now. Take the max over all
exceptions since we only need a conservative estimate.
R=clemensb@chromium.org
Bug: v8:8091
Change-Id: Id5a3e12d89c5d48219e8981e16c2b679d80b67db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2691051
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72976}
The flag should not be set after an exception is thrown in a runtime
function. The unwinder still runs after the destructor, and should take
care of setting the flag depending on the catching frame.
R=ahaas@chromium.org,jkummerow@chromium.org
Bug: chromium:1180690
Change-Id: I0013c90f759a5145309f6e08d61ed36aeecbac63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2713103
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72972}
Follow-up from https://crrev.com/c/2649147/. There are still 2 usages of
_wrapper functions in the interpreter, these are slightly more annoying
to get rid of since the definitions have a ifdef for MSCV/OS_WIN.
Bug: v8:11384
Change-Id: Ic5ca860678f406e1c832c99398b235707da058f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2713166
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72969}
This change adds a new abstract type Lazy<T> which can be used to
interoperate with CSA code that uses LazyNode. This new type has special
code-generation rules because its generated type is not TNode<...> but
std::function<TNode<...>()>. Torque code can do nothing with this type
except pass it around, but passing it to the CSA function RunLazy is an
easy way to execute the std::function and get back a normal value.
Torque code can also create Lazy<T> values using the intrinsic function
%MakeLazy, which takes the name of a macro as its first parameter,
followed by arguments to that macro which will be passed when the
LazyNode is evaluated. We use the macro's name because the language
doesn't support taking references to macros, and implementing such a
feature would be complicated.
Bug: v8:7793
Change-Id: I09120960e3492dd51be0d4c57e14ff3826b99262
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2701752
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72964}
After the runtime call for dynamic tiering, the instance cache is
invalidated. This was assumed to be done in {SpillAllRegisters}, but the
instance is still being accessed after that call, so the instance cache
register might still be set after the runtime call.
R=ahaas@chromium.org
Bug: chromium:1179065
Change-Id: I375e7c388e5a74789050e374db50d21c2efe27e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2714544
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72958}
.. which can return Undefined if reading out of bounds, so the return
type is ObjectRef and not StringRef (if we had torque-like union types
it'd be StringRef|OddballRef). Also change the function name to
GetCharAsStringOrUndefined.
Bug: v8:7790,chromium:1181246
Change-Id: Icf9e8fd03d11c3936e87a509b9117e547972d283
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712965
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72952}
If two call instructions were generated right after each other, the
source position table could get populated with two entries for the same
PC (triggered by the follow-up CL: https://crrev.com/c/2697359).
This CL fixes that by slightly changing the carry-over of source
positions from nodes to instructions.
The call node which has a source position attached generates two
instructions:
18: gap () ([rax|R|tp] = v16(-); [rbx|R|t] = v17(-);)
[rax|R|t] = ArchCallWasmFunction [immediate:4] #-1 [rax|R|tp] [rbx|R|t] [immediate:5]
19: gap () ()
ArchJmp [immediate:6]
Those are then reversed, and the source position is attached to the first
one (the ArchJmp). After reversing it again later, the source position
will be set to the pc *after* the call instruction, which in the example
happened to be just another call instruction which already had a source
position, resulting in this code:
[...]
0x388ee467d426 66 e875feffff call 0x388ee467d2a0 ;; wasm stub: WasmThrow
0x388ee467d42b 6b e850feffff call 0x388ee467d280 ;; wasm stub: WasmStackGuard
[...]
Source positions:
pc offset position
6b 5
6b 0
By attaching the source position to the *last* instruction (after
reversing), we ensure that it will be generated for an instruction
*before* the call, or the call itself if this is the first instruction
emitted for that node.
R=jgruber@chromium.org
Bug: v8:11490, v8:11496
Change-Id: Ie95c87d0d9daea56ca14a811abcd02ac07a4cf84
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697358
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72951}
Also fixes existing tests which were asserting the wrong behavior (that
setting writable=false won't have an effect).
The bug was introduced by https://chromium-review.googlesource.com/c/v8/v8/+/1442640 .
Bug: chromium:1158138
Change-Id: I2d85721848eb4e7d530a980a9ecef7f8693bb9a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2691050
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72948}
The v8_enable_webassembly=false configuration will not be a able to run
any wasm code, hence remove the whole asm to wasm translation from the
binary.
In order to skip specific unit tests in that configuration, we move the
definition of the v8_enable_webassembly gn argument from BUILD.gn to
v8.gni, such that it is available in all gn files.
R=ecmziegler@chromium.org, machenbach@chromium.org
Bug: v8:11238
Change-Id: Id4e290df3e42ffd2f05c377bdd3a368871815daf
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712562
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72945}
This moves all tests that construct a wasm module (and load
wasm-module-builder.js) from test/regress to the test/regress/wasm
directory. This will make it easier to skip them all in the
v8_enable_webassembly=false configuration.
R=ahaas@chromium.org
Bug: v8:11238
Change-Id: Ib22b0fb40a58f213182e68b78b34041651c436d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712243
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72942}
The experimental engine struggles to compile this large pattern.
Change-Id: I0abd5c7ed9f6f62b1c18b5c3dc1cb6a25e130c53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712754
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72941}
Load lanes require that dst == src1 when AVX is not supported, add that
constraint to the instruction selector. For Liftoff, we change the macro
defintions of Movlps and Movhps to do the move if dst != src1.
Bug: v8:10975
Change-Id: Ic4f499845f0728db250ea23b1b053e0a9fbe99b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2708825
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72936}
This reverts commit 0818d13807.
Reason for revert: Rolling back to previous greedy slot allocator.
tbr=ahaas@chromium.org
Original change's description:
> [compiler][wasm] Fix Wasm linkage
>
> - Fixes a problem when constructing Wasm CallDescriptors, where the
> allocation tries to treat parameters and returns as if they are in the
> same frame. This doesn't work when slots may be aligned in their
> frame. Instead, allocate parameters and returns separately and offset
> return slots by the number of parameter slots.
> - Adds argument slot padding in the CallDescriptor lowering case, to
> prepare for when 32 bit targets align stack frames and require
> padding.
> - Adds a regression test.
>
> Bug: chromium:1174500
> Change-Id: I60d96a94b171a0d27ff61cbab35623976b0c6da8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683024
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72588}
Bug: chromium:1174500
Change-Id: I1d1c389acde43bd56e6d2a27e1a3eb8ea4d6073c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2713206
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72934}
This is essentially a revert of 3 commits:
- a1d39bbaed
- 5a0938e593
- 74362ae3e2
with merge conflicts fixed.
These instructions were not merged into the SIMD proposal.
Bug: v8:11297
Change-Id: Ifffe7c61cae10fadc345d0faa1b0ba45ce74e946
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704950
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72933}
This reverts commit 8cf4eec7d8.
Reason for revert: Rolling back to previous greedy slot allocator.
tbr=neis@chromium.org,jgruber@chromium.org
Original change's description:
> [codegen][frames] Generalize argument padding slot code
>
> - Removes kPadArguments boolean.
> - Changes ShouldPadArguments to ArgumentPaddingSlots to reflect
> that on some architectures more than 1 padding slot may be needed.
> - Adds AddArgumentPaddingSlots and ShouldPadArguments convenience
> functions.
>
> Bug: v8:9198
>
> Change-Id: Iba87518e071a75fb951b490d3f75a87ca715cc23
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679109
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72605}
Bug: v8:9198
Change-Id: Ie93d32d4b93c67840e4792acb017f28a826bd030
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2713205
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72931}
Also add v8_config_headers dependency to cctest_headers. This reduces
the number of gn check failures from 194 to 178.
Bug: v8:7330
Change-Id: I6453b9789503c9d8ca3ed6bbe94bce3e2a69653f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712564
Auto-Submit: Dan Elphick <delphick@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72912}
Currently if gn check is enabled (with v8/third_party ignored), there
are many errors due to headers being used without adding the proper
dependency in BUILD.gn (or because it's being used transitively without
a public_deps chain).
This makes the number of errors go from 2114 to 195.
Apart from adding dependencies, it also moves _v8_internal_Node_Print
from objects-printer.cc to node.cc so it can see the Node::Print method
which wouldn't otherwise be possible without a circular dependency. Also
removes the previously deleted compiler/graph-builder-tester.h file.
Bug: v8:7330
Change-Id: Icb34585fbef621588265cf4267cfc88ecbcf0a72
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2702331
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72908}
If webassembly is disabled via a gn arg, we will not be able to enable
it via command-line switch. Hence make this flag read-only in that
configuration.
R=ecmziegler@chromium.org
Bug: v8:11238
Change-Id: Ib93a55f74d4f018477f110b8b52aa9b645e86553
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710426
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72905}
This is a reland of 76a2ab06a1
Changes since the original CL:
- Handle unserialized elements (optional result in getter).
- Merge should_access_heap and --turbo-direct-heap-access paths.
- Slightly update the serialized path in GetOwnCowElement.
- Fix the cctest, add a regression test.
Atomic JSObject::elements/JSArray::length setters are addressed
in this CL: crrev.com/c/2704076.
Original change's description:
> [compiler] Direct heap reads for JSArrayRef
>
> There are two aspects to the non-JSObject parts of JSArrayRef:
>
> - JSArrayRef::length. Relevant only in two spots, 1. when reading
> (immutable) array boilerplates and 2. for GetOwnCowElement.
>
> - JSArrayRef::GetOwnCowElement. May read into a copy-on-write backing
> store. Relies on the invariant that cow backing stores are immutable.
>
> This CL renames the length accessor to length_unsafe to make the
> danger explicit at callsites.
>
> For GetOwnCowElement the refactor is slightly larger, since we now
> need to read into the backing store while keeping full control of
> object reads (e.g. JSArray::length and JSArray::elements_kind). We
> make all reads explicit at the call site by requiring that elements,
> elements kind, and length are passed in as arguments to
> GetOwnCowElement. Inside GetOwnCowElement, consistency between these
> is *not* guaranteed due to concurrency. At runtime, consistency *is*
> guaranteed through the reference-equality check on the elements seen
> during compilation. The actual elements read is implemented in
> ConcurrentLookupIterator::GetOwnCowElement.
>
> Bug: v8:7790
> Change-Id: I9aa169ce4f2b1e2bfe1e9232007669eb7654a995
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695403
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72834}
Bug: v8:7790
Change-Id: I7577ad554992cafff81099a28c34f27db9bd8042
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710431
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72904}
This moves all asm.js tests (tests that use "%IsAsmWasmCode") into a
separate directory. This will make it easier to skip them all in the
v8_enable_webassembly=false configuration.
R=ahaas@chromium.org
Bug: v8:11238
Change-Id: I805f222b7977f5508f7dbee1f1bd61a88ccd34aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710427
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72900}
This CL introduces a test runner flag to detect if webassembly has been
disabled. Since all tests that require wasm are alrady skipped in
lite mode, we introduce a has_webassembly flag for the test runner which
checks for v8_enable_webassembly=true and v8_enable_lite_mode=false.
As a drive-by, we also do not set the V8_ENABLE_WEBASSEMBLY
preprocessor flag if lite mode is enabled.
The status files are updated by splitting wasm tests from the
"lite_mode" section and checking for "not has_webassembly" instead.
Note that the v8_enable_webassembly=false configuration is not tested
on any bot currently, but I will make sure that all tests keep passing
on further changes in this configuration.
R=machenbach@chromium.org
Bug: v8:11238
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Change-Id: I1841eb1f1633cb47e0c079f4a4a4d769ca3a9cbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710425
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72898}
Backends do not care about the concrete type, they only need to know the
"kind" (e.g. "ref" or "i32").
In order to prepare Liftoff to use the value kind instead of the
value type for all stored data, this CL moves the kind out of the
ValueType and makes it a top-level enum.
R=manoskouk@chromium.org
Bug: v8:11477
Change-Id: I489d6c5207e6ff1b66e2afbe78a156d66df27eb3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707169
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72896}
If a StackOverflow is caught, reload the pc and the limit from the
catching frame, not from the target.
R=clemensb@chromium.org
Bug: chromium:1180339
Change-Id: I41bf94e6c7525106e990306913e446f2c4269df1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710436
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72891}
We always built a new Phi node for the delegate merge, which is
incorrect when the target block's exception is already a Phi. Use
CreateOrMergeIntoPhi instead.
R=clemensb@chromium.org
Bug: v8:11472
Change-Id: I8af3ab07d536ddfe247ace04cc844207d32adb99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707167
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72874}
This is the first part of exception handling support in Liftoff. For
now, the only supported instruction is throw, and only with empty
payload or only i32 values.
R=thibaudm@chromium.org
Bug: v8:11453
Change-Id: I9fdf1328ef46655674a05186fb93216518886d03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704659
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72871}
Code objects are exposed through JSFunction and SharedFunctionInfo.
If they are builtins, we don't have to worry about background threads
seeing partially initialized code objects. If they are optimized code
objects, we may. Background threads read the code fields with
AcquireLoad semantics. The fields are set on the main thread with
ReleaseStore semantics when appropriate.
Special care is taken when setting an optimized code object in a closure
in the interpreter entry stub. Since the MacroAssembler doesn't support
ReleaseStore semantics, this CL ensures that the optimized code object
is stored with those semantics in the feedback vector, where the
interpreter entry stub finds it.
Bug: v8:7790
Change-Id: I41ecedfe0e9d1ad5091cbe9a97f66c66ca9e07dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676633
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72869}
We can remove some of the method definitions, as well as the
sloppy-ness from the method.
Bug: v8:6949, v8:11384
Change-Id: I04880daa3fcce097b79009f12bd24128a47c2c80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690591
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72867}
In {MergeFullStackWith}, we were accidentally looking at the cached
instance in the current {cache_state_} instead of the state passed as
{source}. This could lead to missing reload of the instance after a
conditional branch.
R=thibaudm@chromium.org
Bug: chromium:1179182
Change-Id: Ida3c06491f7973a183c43745159abbf6aa8a058b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704081
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72864}
This reverts commit 76a2ab06a1.
Reason for revert: A few issues, e.g.
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8854931126653780144/+/u/Check__flakes_/ArrayWithCowElements
Original change's description:
> [compiler] Direct heap reads for JSArrayRef
>
> There are two aspects to the non-JSObject parts of JSArrayRef:
>
> - JSArrayRef::length. Relevant only in two spots, 1. when reading
> (immutable) array boilerplates and 2. for GetOwnCowElement.
>
> - JSArrayRef::GetOwnCowElement. May read into a copy-on-write backing
> store. Relies on the invariant that cow backing stores are immutable.
>
> This CL renames the length accessor to length_unsafe to make the
> danger explicit at callsites.
>
> For GetOwnCowElement the refactor is slightly larger, since we now
> need to read into the backing store while keeping full control of
> object reads (e.g. JSArray::length and JSArray::elements_kind). We
> make all reads explicit at the call site by requiring that elements,
> elements kind, and length are passed in as arguments to
> GetOwnCowElement. Inside GetOwnCowElement, consistency between these
> is *not* guaranteed due to concurrency. At runtime, consistency *is*
> guaranteed through the reference-equality check on the elements seen
> during compilation. The actual elements read is implemented in
> ConcurrentLookupIterator::GetOwnCowElement.
>
> Bug: v8:7790
> Change-Id: I9aa169ce4f2b1e2bfe1e9232007669eb7654a995
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695403
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72834}
Bug: v8:7790, chromium:1180012
Change-Id: I50e72380c544b2b78e1e3dc87a8249281b710912
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704666
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72860}
This is a reland of
https://chromium-review.googlesource.com/c/v8/v8/+/2688058
This CL is part of a series that adds the C++ implementation of
SwissNameDictionary, a deterministic property backing store based on
Swiss Tables.
This CL adds the initialization code, factory functions and a
canonical SwissNameDictionary plus all helpers required for that.
Bug: v8:11388
Change-Id: I9cf66a3fa755288f7730f55abfb6e6cea82f6b03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2703653
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72857}
This reverts commit f731e13f00.
Reason for revert: perf regressions, chromium:1179757
Original change's description:
> Remove 'length' field from ScopeInfo
>
> ScopeInfo has a vestigial 'length' field from when it used to be a
> FixedArray. This change removes that field, which saves some memory.
>
> More specifically:
>
> - Make ScopeInfo inherit from HeapObject, not FixedArrayBase which
> supplied the 'length' field.
> - Privatize the FixedArray-style functions that provide access to
> ScopeInfo fields by index, and move them from scope-info-inl.h to
> scope-info.cc. Those functions are still used pretty heavily during
> initialization (ScopeInfo::Create, etc.), but at least we can avoid
> presenting them to the rest of the world.
> - Change FactoryBase::NewScopeInfo to allocate the updated object shape.
> It maintains the existing behavior of filling the newly-allocated
> object with undefined, even though that's not a valid ScopeInfo and
> further initialization is required.
> - Move part of AccessorAssembler::ScriptContextTableLookup into a new
> Torque macro, because it used to rely on casting ScopeInfo to
> FixedArrayBase.
> - In V8HeapExplorer::AddEntry, don't claim that ScopeInfo objects are
> arrays. I think it makes more sense to list them under "(system)" in
> the dev tools, like most other V8 internal types.
>
> Bug: v8:8952
> Change-Id: I8278e3a90027d4409f0d268da0fe7080754c6b8c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2601880
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72830}
Bug: v8:8952
Change-Id: I00a69da79e5ac6aaae4436a41ce773ae014cc775
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2706086
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Seth Brenith <seth.brenith@microsoft.com>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72855}
The atomic pause would not report any marked bytes which in turn would
mean that the used bytes counter would stay at 0 for testing GCs that
always use atomic marking.
Bug: chromium:1056170
Change-Id: Ie35d9b3bc88766c4ef56271f05d944f4835ba431
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704662
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72850}
- Remove unused type inference paths which will be replaced
with more explicit structs.
- Removes the tagged pointer from CTypeInfo since the embedder
will perform the type check for API objects.
Bug: chromium:1052746
Change-Id: I47a5f5ae35b06845b01b68cb089c67f76a7fb05e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2686685
Commit-Queue: Austin Eng <enga@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72848}
Modify the cctests for the inlined JS-to-Wasm calls to use the
%ObserveNode intrinsic, to verify that the JSCall node is actually
inlined . This requires a small refactoring of the %ObserveNode
implementation.
Bug: v8:11092
Change-Id: I01727143fec64c6c11c58b1b664f51daae5bfdb6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2677811
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72838}
Eager evaluation in DevTools console relies on the builtins side
effect attribution.
Setters on Date object should be marked as no side effects if called
on the temporary object.
This bug was uncovered after considering screenshot from a tweet [1].
[1] https://twitter.com/shuding_/status/1362132984376160256
Change-Id: Iedc0e29e2bdab719304e2f0a0435845f24eaaadc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2703459
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72835}
There are two aspects to the non-JSObject parts of JSArrayRef:
- JSArrayRef::length. Relevant only in two spots, 1. when reading
(immutable) array boilerplates and 2. for GetOwnCowElement.
- JSArrayRef::GetOwnCowElement. May read into a copy-on-write backing
store. Relies on the invariant that cow backing stores are immutable.
This CL renames the length accessor to length_unsafe to make the
danger explicit at callsites.
For GetOwnCowElement the refactor is slightly larger, since we now
need to read into the backing store while keeping full control of
object reads (e.g. JSArray::length and JSArray::elements_kind). We
make all reads explicit at the call site by requiring that elements,
elements kind, and length are passed in as arguments to
GetOwnCowElement. Inside GetOwnCowElement, consistency between these
is *not* guaranteed due to concurrency. At runtime, consistency *is*
guaranteed through the reference-equality check on the elements seen
during compilation. The actual elements read is implemented in
ConcurrentLookupIterator::GetOwnCowElement.
Bug: v8:7790
Change-Id: I9aa169ce4f2b1e2bfe1e9232007669eb7654a995
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695403
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72834}
Process global accessors for total physical size and used size are
needed for blink. These are implemented via an allocation observer that
atomically updates static counters.
The public api only provides getters for the counters. An internal class
is in charge of updating the counters as needed. A similar split is also
applied to IsAnyIncrementalOrConcurrentMarking().
Drive-by: ProcessHeap is merged into cppgc::internal::WriteBarrier.
Bug: chromium:1056170
Change-Id: Iaedebd1ac9d49238ce6bdd52ffa5d1ef4d28203d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695394
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72832}
ScopeInfo has a vestigial 'length' field from when it used to be a
FixedArray. This change removes that field, which saves some memory.
More specifically:
- Make ScopeInfo inherit from HeapObject, not FixedArrayBase which
supplied the 'length' field.
- Privatize the FixedArray-style functions that provide access to
ScopeInfo fields by index, and move them from scope-info-inl.h to
scope-info.cc. Those functions are still used pretty heavily during
initialization (ScopeInfo::Create, etc.), but at least we can avoid
presenting them to the rest of the world.
- Change FactoryBase::NewScopeInfo to allocate the updated object shape.
It maintains the existing behavior of filling the newly-allocated
object with undefined, even though that's not a valid ScopeInfo and
further initialization is required.
- Move part of AccessorAssembler::ScriptContextTableLookup into a new
Torque macro, because it used to rely on casting ScopeInfo to
FixedArrayBase.
- In V8HeapExplorer::AddEntry, don't claim that ScopeInfo objects are
arrays. I think it makes more sense to list them under "(system)" in
the dev tools, like most other V8 internal types.
Bug: v8:8952
Change-Id: I8278e3a90027d4409f0d268da0fe7080754c6b8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2601880
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72830}
This reverts commit 2f8a7561cb.
Reason for revert: Speculative revert, lots of segfaults on Arm:
https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/17781
Original change's description:
> [dict-proto] C++ implementation of SwissNameDictionary, pt. 3
>
> This CL is part of a series that adds the C++ implementation of
> SwissNameDictionary, a deterministic property backing store based on
> Swiss Tables.
>
> This CL adds the initialization code, factory functions and a
> canonical SwissNameDictionary plus all helpers required for that.
>
> Bug: v8:11388
> Change-Id: I6bb92740afefc7d05433cfa62023e6da5e8213c7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688058
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Frank Emrich <emrich@google.com>
> Cr-Commit-Position: refs/heads/master@{#72824}
Bug: v8:11388
Change-Id: Ia5dae584b0fb452b12c5d64ee63ffa418c83f91b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698758
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72829}
This missing include was undetected because trace_perf.cc is only
built if the checkout_google_benchmark custom gclient variable is
defined.
Bug: none
Change-Id: If2016edad4df382f14903593ea18066f7759c4d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698387
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Chris Mumford <cmumford@google.com>
Cr-Commit-Position: refs/heads/master@{#72825}
This CL is part of a series that adds the C++ implementation of
SwissNameDictionary, a deterministic property backing store based on
Swiss Tables.
This CL adds the initialization code, factory functions and a
canonical SwissNameDictionary plus all helpers required for that.
Bug: v8:11388
Change-Id: I6bb92740afefc7d05433cfa62023e6da5e8213c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688058
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Frank Emrich <emrich@google.com>
Cr-Commit-Position: refs/heads/master@{#72824}
This is a reland of cf93071c91
Original change's description:
> [interpreter] Short Star bytecode
>
> Design doc:
> https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
>
> This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
> that we can use a single byte to represent the common operation of
> storing to a low-numbered register. This generally reduces the quantity
> of bytecode generated on web sites by 8-9%.
>
> In order to not degrade speed, a couple of other changes are required:
>
> The existing lookahead logic to check for Star after certain other
> bytecode handlers is updated to check for these new short Star codes
> instead. Furthermore, that lookahead logic is updated to contain its own
> copy of the dispatch jump rather than merging control flow with the
> lookahead-failed case, to improve branch prediction.
>
> A bunch of constants use bytecode size in bytes as a proxy for the size
> or complexity of a function, and are adjusted downward proportionally to
> the decrease in generated bytecode size.
>
> Other small drive-by fix: update generate-bytecode-expectations to emit
> \n instead of \r\n on Windows.
>
> Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72773}
Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72821}
Move the CompileWithBaseline interface to the Compiler class, as
CompileBaseline, which will do the additional work of pre-compiling
to bytecode, ensuring there is a feedback vector, and setting the
code on the function closure.
As a drive-by, fix v8_enable_trace_unoptimized to have a blank default
value, so that v8_enable_trace_ignition/v8_enable_trace_baseline_exec
can set it.
Bug: v8:11420, v8:11429
Change-Id: If715161de71f7d9300f3fdcbb50cc678b1fcdfdf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697352
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72819}
In case there's no exact match for the breakable location in
SetBreakpoint(), don't try to find the syntactically closest break
location, but rather find the first possible break location in bytecode
order. In particular when trying to set a breakpoint in a line with
for-of or an array destruction, there's no point in going for the
syntactically closest to the beginning of the line, but rather go for
the semantically first, as the intiution for setting a breakpoint on a
line is that the debugger stops before it executes anything on said
line. In the example
```
var [^a, ^b] = ^func();
```
there are three possible break locations, and the correct one is the
last one as the call to func will happen first at runtime.
For generators that's currently broken because of the implicit initial
yield, and same with modules (see crbug.com/901819), so we keep the
previous behavior of finding the closest breakable location, and will
fix that independently in a follow up CL.
Bug: chromium:901819
Fixed: chromium:782461
Also-By: yangguo@chromium.org
Change-Id: Ie724c5cb08e5f4edd90a450d99e001dff06bbe7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696586
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72813}
Pinned registers were not considered correctly when taking a volatile
register. This CL refactors handling of the pinned registers list by
combining the candidates list and the pinned list early. This avoid
additional parameters on some functions and might save some redundant
masking.
As a side effect, it also fixes the DCHECK error on arm.
R=ahaas@chromium.org
Bug: chromium:1179025
Change-Id: Ib9193b209c5741ea97fd1d0dffeeb9e824639439
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2699254
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72812}
During the string reverts a while back
https://chromium-review.googlesource.com/c/v8/v8/+/2633547 I reverted
some tests that were testing the code that was *not* reverted i.e. the
internalization of external strings.
Bug: v8:7790
Change-Id: I84964791cce712d753fd409cc3c641d9fbbb6550
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2699262
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72809}
The csuite.py script does not work correctly on Windows. It runs
correctly in baseline mode, but there are two problems when running in
compare mode:
1. In compare mode the output of benchmark.py is piped to the
compare-baseline.py script, but Windows only execute python files if
python.exe is the default program to open '.py' files, and this is
not the case, by default, when python is installed as part of the
depot_tools.
Fix: explicitly add the 'python' command before compare-baseline.py.
2. By default CSuite prints the results to stdout using escapes codes
that add color highlights. But this does not work on Windows when
compare-baseline.py is launched with a pipe:
python test/benchmarks/csuite/benchmark.py <...> |
python test/benchmarks/csuite/compare-baseline.py <baseline_results>
Fix: Do not use a pipe. Write the benchmark numbers for the
compare-run into a separate file, and pass the path to this file to
compare-baseline.py
Change-Id: Ic22d5bd4b47901f0ba0f35bc2496441346d21c6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2656855
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72807}
The expected exception in this regression test is thrown due to a
limitation in the IrRegExp engine.
The experimental engine is unaffected and won't throw.
Bug: v8:11363
Change-Id: If37d86f5d4494b40c47ecc5e5bc4f86fda30389c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2699251
Auto-Submit: Patrick Thier <pthier@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72806}
samples being discarded
- Passed in as CpuProfilingOptions parameter, client is responsible for
determining if function is still safe to execute. Includes unit tests
- Client (blink) side CR: https://chromium-review.googlesource.com/c/chromium/src/+/2649617,
- Client (blink) side CR requires this to be pushed prior to it being pushed
Change-Id: I3ef4640186115d4e14c1b73f902c889c776e310f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2652206
Commit-Queue: Nicolas Dubus <nicodubus@fb.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72794}
As of https://crrev.com/c/2629465, Simd tests cannot pass on
architectures without Simd support. Tests will need to be re-enabled
once Simd support is fully implemented on PPC.
Change-Id: I963639f1afa0c0ca7be3ca4b2fc06e874235b903
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2693056
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72788}
Implicitly rethrow the exception when we reach the end of a
try..unwind..end. Also make it a validation error to rethrow
an exception caught by an unwind block.
R=clemensb@chromium.org
Bug: v8:8091
Change-Id: Ia149d2e81b1fbfa9209047b35ff0c9fedc1b8895
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696662
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72785}
This reverts commit cf93071c91.
Reason for revert: Speculative revert because of Mac4 GC stress failure: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/16697/overview
Original change's description:
> [interpreter] Short Star bytecode
>
> Design doc:
> https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
>
> This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
> that we can use a single byte to represent the common operation of
> storing to a low-numbered register. This generally reduces the quantity
> of bytecode generated on web sites by 8-9%.
>
> In order to not degrade speed, a couple of other changes are required:
>
> The existing lookahead logic to check for Star after certain other
> bytecode handlers is updated to check for these new short Star codes
> instead. Furthermore, that lookahead logic is updated to contain its own
> copy of the dispatch jump rather than merging control flow with the
> lookahead-failed case, to improve branch prediction.
>
> A bunch of constants use bytecode size in bytes as a proxy for the size
> or complexity of a function, and are adjusted downward proportionally to
> the decrease in generated bytecode size.
>
> Other small drive-by fix: update generate-bytecode-expectations to emit
> \n instead of \r\n on Windows.
>
> Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72773}
TBR=rmcilroy@chromium.org,mythria@chromium.org,seth.brenith@microsoft.com
Change-Id: I0162b9400861b90bacef27cca9aebc8ab9d74c10
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697350
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72777}
Design doc:
https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
that we can use a single byte to represent the common operation of
storing to a low-numbered register. This generally reduces the quantity
of bytecode generated on web sites by 8-9%.
In order to not degrade speed, a couple of other changes are required:
The existing lookahead logic to check for Star after certain other
bytecode handlers is updated to check for these new short Star codes
instead. Furthermore, that lookahead logic is updated to contain its own
copy of the dispatch jump rather than merging control flow with the
lookahead-failed case, to improve branch prediction.
A bunch of constants use bytecode size in bytes as a proxy for the size
or complexity of a function, and are adjusted downward proportionally to
the decrease in generated bytecode size.
Other small drive-by fix: update generate-bytecode-expectations to emit
\n instead of \r\n on Windows.
Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72773}
The current API returns a Handle<NativeContext> which can be
optionally null and all the users of this API never actually
checked for this null value.
Previously, this wasn't a problem as all the possible JSObjects
that were user visible would return a valid NativeContext but now
there are wasm objects that don't have a valid constructor so don't
have a NativeContext.
Bug: v8:11451, chromium:1166077
Change-Id: I4fd5edf8f1a750e6f0abb931fd41358e5ae4dfcf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692695
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72769}
When there are multiple nested catch blocks, the rethrow immediate
disambiguates which catch block to take the exception from. We
add a FixedArray to keep track of exceptions that are currently
in scope, and compute the mappings between rethrow/catch instructions
and the index to fetch/store the exception from/to in the FixedArray
during pre-processing.
R=clemensb@chromium.org
Bug: v8:8091
Change-Id: If55242c551f42262c790b5bf3f1543a003280623
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695388
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72768}
The origin trial for WebAssembly Threads is over for quite some time,
WebAssembly Threads are enabled by default. The API can therefore be
removed now.
Bug: v8:11384
Change-Id: I3dd65ff63c1ed31d39a76e5aea08b950ef420f54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690598
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72766}
Changes:
- In graph-builder-interface.cc, move loop exit utilities in the private
section.
- In the same functions, remove SsaEnv argument. Always use ssa_env_
instead.
- Introduce TerminateThrow, which introduces loop exits before inserting
a throw node.
- Introduce loop exits in the exception handling opcodes.
- Introduce control_depth_of_current_catch() helper.
- Drive-by: Add an optional missing 'break' in DoReturnCall.
- Add some tests, improve test flags in loop-unrolling.js test file.
Bug: v8:11298
Change-Id: I613352023e3e1c72a83cd389d98574758655abee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692820
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72765}
Pass an explicit Isolate* argument to Compiler::Compile*, rather
than grabbing the Isolate from the function
Change-Id: I37a38103c67305077225ea3951d36007cf07beea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696655
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72762}
Add a new StackFrame class for unoptimized frames (which are either
interpreted or baseline). BaselineFrame becomes a subclass of this
rather than InterpretedFrame, and the various frame constants helpers
are similarly amended.
Bug: v8:11420, v8:11429
Change-Id: I87e9368aef48ef06a39476bf826f379ce1441528
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692208
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72743}
This adds a call to re-compile top level functions in case
no shared function info could be found. We ran into a bug
where it was not possible to set a breakpoint on the
top-level function since it was already removed by the GC.
Bug: chromium:1137141
Change-Id: I5bb6984825eee8ebcb44619e15b3acf3d118b9bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2672181
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72738}
Also block sending "type" as part of the ObjectPreview, but only send
the "value" property. The front-end will be updated to display
WasmValueObject's similar to what we do for wrapper objects (i.e.
StringWrapper and the like). The matching front-end change is still
pending.
Also refactor the WasmValueObject to have dedicated constructors for
the individual types (i32, i64, f32, f64, externref and v128). This
way we can just reuse the existing logic in descriptionForObject()
and we also don't need to store the "type" on the object itself (not
really performance sensitive, but fewer moving parts / things that
can go wrong).
This also addresses the crash in https://crbug.com/1166077#c16 since
the WasmValueObject instances now have a proper JSFunction in their
maps' constructor_or_backpointer slot and are thus able to locate
their creation context. Note that this doesn't generally address
https://crbug.com/1166077 itself, but only the WasmValueObject case.
Screenshot: https://imgur.com/kbd3bix.png
Bug: chromium:1170282, chromium:1071432
Bug: chromium:1159402, chromium:1166077
Change-Id: Iae649cad155efd774cfb1f4eea8cf406e413c03a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692574
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72736}
- Baseline is to be consider non-optimized code, so for consistency we rename these functions to DiscardBaselineCode.
- Move to debug/, since discarding baseline code is only used by the debugger.
- %DeoptimizeNow and %DeoptimizeFunction are not to be used to tier down from Sparkplug to Ignition
Change-Id: I050607d4d6978907c589e54c57e940979b0a9a15
Bug: v8:11429
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692699
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72732}
Same code sequence as x64.
Bug: v8:11416
Change-Id: Ibbd4cbf75e10b0ce876d42809d909868fdb86b87
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2686309
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72724}
Previously it was possible for a slot operand to be allocated a
constant operand which is not valid. This CL adds support to the
mid-tier register allocator to keep track of whether spilled operands
can support constant operands, and if not to instead move the constant
to a spill slot at it's definition point, and use that spill slot
instead.
In the process of doing this, we can cleanup the hack that
required constants to always be allocated to a register for
REGISTER_OR_SLOT operator policies.
BUG=chromium:10772,v8:10772,v8:9684
Change-Id: I975ea2c481b45fc0855e175bc6dc2bd0a83f509a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692569
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72722}
This is a reland of a16add806d.
The fixes are adding disassembly for pcmpgtq and vpcmpgtq.
While fixing also noticed a mistake in assembler for pcmpgtq,
which flipped dst and src.
Also realized that we don't detect SSE4.2, so adding that in.
PS2 contains these changes.
Original change's description:
> [wasm-simd][ia32] Implement i64x2 signed compares
>
> The code sequence is exactly the same as x64.
>
> Bug: v8:11415
> Change-Id: I53ed2723eda29c0a250cff514372a3d45b203476
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683495
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72637}
Bug: v8:11415
Change-Id: If6a18af2d7de20ac8ad38f94b6d0220769397194
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688119
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72721}
As outlined in the design document linked below, we're removing the
support for the non-standard Function.displayName property for the
purpose of Error.stack and DevTools Inspector stack traces. The
motivation here is that the negative lookup is costly, and we have
Function.name as a standard alternative (configurable since ES6 for
exactly this reason).
I dediced to go with JSFunction::GetDebugName(), since
JSFunction::GetName() was confusing in that it'd only get the "name"
property's value if it's a data property, but not with accessors.
JSFunction::GetDebugName() makes it clear that this is really a debug
helper function and might not give you the "name" property value.
Doc: https://bit.ly/devtools-function-displayName-removal
Bug: v8:8742, chromium:1177685, chromium:1077657, chromium:17356
Change-Id: I7717585cbace626174b2f2ed2a4f68f75429eca1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692189
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72715}
Ephemerons are based around WeakMember which may just be null at the
time the pair is considered for liveness. Bail out of marking for null
keys, as they write barrier would anyways make the value strong when
marking the key.
Bug: chromium:1056170
Change-Id: If8775a370824b88fc67fa479a0c0893985fbf5f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692571
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72714}
If the exception tag does not match any of the catch blocks and there is
no catch_all block, it should be rethrown.
R=clemensb@chromium.org
Bug: v8:8091
Change-Id: I8df80f51340fc6265f5ef4308ee3b0f892ee3a90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690599
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72713}
This CL adds support for instrumentation breakpoints in wasm. The
request for "break on entry" is set on the script, and we need to keep
it stored there because there might not be any instances of that wasm
module yet. Once instances get created, the flag value is transferred to
all instances. The flag stored there is then checked in the function
prologue in Liftoff debugging code. This ensures that we will stop at
the first valid break position in any function within that module.
Hitting that instrumentation breakpoint will then clear the flag from
the script and from all other live instances (in the same isolate).
A first basic test is contained in this CL. More tests will be added
later.
R=thibaudm@chromium.org, bmeurer@chromium.org
Bug: chromium:1151211
Change-Id: I5442d4044934988269becececc03699b850d51d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690588
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72701}
Add a .status file variable for the "v8_control_flow_integrity" gn arg,
and disable baseline tests for now in that configuration.
No-Tree-Checks: true
No-Try: true
Bug: v8:11439
Change-Id: I7274a168893cfd6619ce98fdd14a692217fd56c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692206
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72698}
This reverts commit 87df0b7ecc (thus
relands 42cd9eb78d), with fixes for
the discovered issues.
Original change's description:
> Revert "[compiler] Directly read PropertyCells"
>
> This reverts commit 42cd9eb78d.
>
> Reason for revert: Clusterfuzz issues, e.g.
> https://bugs.chromium.org/p/chromium/issues/detail?id=1176318
>
> Original change's description:
> > [compiler] Directly read PropertyCells
> >
> > Main changes:
> >
> > - Introduce a new broker data kind kBackgroundSerialized for objects
> > that can be serialized in the background (when direct reads are on).
> > (I'm planning to remove kPossiblyBackgroundSerialized in a followup,
> > in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
> > - Make PropertyCell use that new kind.
> > - Introduce a bottleneck in runtime code for changes to PropertyCells
> > and make sure that a certain protocol is followed that allows
> > concurrent reads from the background thread.
> > - Improve interface of PropertyCell in various ways.
> >
> > Bug: v8:7790
> > Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> > Commit-Queue: Georg Neis <neis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#72586}
>
> TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org
>
> Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180
> Bug: v8:7790
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72619}
Bug: v8:7790, chromium:1176509, chromium:1176318, chromium:1176504
Change-Id: Icaf285912bb948432a4a2d599cd174f6a5aa296e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685166
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72697}
Currently we sometimes refer to baseline code or the baseline compiler
by its codename (Sparkplug). The codename is fun, but we should be
consistent and call things by one name or the other. Following the
pattern of Ignition stuff being called "interpreter", we call Sparkplug
"baseline", and leave the codename only in flags and variants.
Bug: v8:11420
Change-Id: I432e5629518be7c7ad38b6acff024c91d4cfd6d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692186
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72696}
Following up on https://crrev.com/c/2689185, this CL significantly
simplifies the whole implementation of the stack trace capturing.
Before this CL, capturing any stack trace (for the purpose of the API or
Error.stack) would roughly work like this:
1. The CaptureStackTrace() function uses the StackFrameIterator to
walk the system stack. For each native frame it uses the
FrameSummary abstraction to get all (including potentially inlined)
frames. For each of those it appends a record consisting of six
elements to a FrameArray (this holds pointers to the actual
closures and receivers).
2. Afterwards the FrameArray is shrinked to the required size, and a
new FixedArray is allocated, and initialized with new
StackTraceFrame objects where each holds a reference to the
FrameArray, the index of the frame, and an initially uninitialized
StackFrameInfo reference. This new FixedArray is then returned from
CaptureStackTrace() and either stored on a message object or
provided to the API as v8::StackTrace.
The new approach removes a lot of the machinery in between and directly
creates a FixedArray of StackFrameInfo objects in CaptureStackTrace().
These StackFrameInfo objects are directly exposed as v8::StackFrame on
the public API, and they hold the six fields that were previously stored
flat in the FrameArray. This not only avoids a lot of copying around of
data and creation of temporary objects and handles, but most importantly
unifies and simplifies the stack frame function inside StackFrameInfo,
so you no longer need to wonder which function / object might be
responsible for a certain API.
There's still a lot of room for improvement. In particular we currently
don't cache the source position for a given StackFrameInfo (or
globally), but rather recompute it every time. This is still very fast,
significantly faster than the previous approach.
There are some notable (potentially user visible) changes:
- The CallSite#GetPosition() method now consistently returns the
Wasm module relative bytecode offset for all Wasm frames (previously
it'd return the function relative bytecode offset for non-asm.js
Wasm frames).
- The column and line numbers returned from StackFrameInfo methods are
consistently 1-based now, instead of sometimes being 0-based (Wasm)
and sometimes being 1-based (JS and asm.js Wasm). The only
potentially noticable difference is that for
CallSite#GetLineNumber() no longer returns 0 for Wasm frames, but
that was wrong and useless anyways.
- CallSite#GetThis() would sometimes return the_hole, another bug
flushed out by this CL.
The CL also contains some other not noteworthy drive-by-cleanups.
Fixed: chromium:1057211
Bug: chromium:1077657, chromium:1069425, v8:8742
Bug: chromium:1127391, chromium:1098530, chromium:981541
Change-Id: Iff12f6838a4d99080db8dd96bccc14440affc5a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689183
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72694}
UBSan starts complaining about a nullptr destination in memcpy after
https://crrev.com/c/2691828.
This CL fixes the error by not copying if there is nothing to copy.
R=nicohartmann@chromium.org
No-Try: true
No-Tree-Checks: true
Change-Id: I2c941b37d26931d6c2253bc3bb2c0aa659d4cb71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690605
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72690}
Ensure that epilogues are added to the LocalHeap before starting the GC.
Adding the epilogue after invoking NotifyStarted() might mean that the
epilogue is only added after the GC is already done and the epilogue
isn't run at all. The test flakily fails because the epilogue didn't
execute then.
Bug: v8:11434
Change-Id: I60723a99cd9224307f48acd0c0e8af3f93dd3eb2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690600
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72688}
Sparkplug is a new baseline, non-optimising second-tier compiler,
designed to fit in the compiler trade-off space between Ignition and
TurboProp/TurboFan.
Design doc:
https://docs.google.com/document/d/13c-xXmFOMcpUQNqo66XWQt3u46TsBjXrHrh4c045l-A/edit?usp=sharing
Bug: v8:11420
Change-Id: Ideb7270db3d6548eedd8337a3f596eb6f8fea6b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667514
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72686}
When the CPU profiler receives a bytecode flush event, ensure that we
clear the appropriate CodeEntry.
Bug: v8:11054
Change-Id: I94e771e42192b75ea6d317738e4f2d5b76533dc8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2691826
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Andrew Comminos <acomminos@fb.com>
Cr-Commit-Position: refs/heads/master@{#72684}
- Add a no-simd-sse flag to skip SIMD tests on bots with no
hardware support.
Change-Id: I4efdbb5ee39c2e10ea8776a1f1e536ac96823efe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2629465
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72682}
In https://chromium-review.googlesource.com/c/v8/v8/+/2641180 , we are
discussing renaming AccumulatorUse. To avoid polluting that change with
a large mechanical find&replace, I've created a separate change for the
renaming.
Change-Id: Ibc7e438f9e719571c9237e7e08ba86562a3c679f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2684923
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72679}
This speeds up sparkplug by >20%.
This reland fixes the OffHeapBytecodeArray to also register a GC
callback. Turns out off-heap here doesn't mean that the underlying
bytecode array is off-heap and it can in fact move.
Change-Id: I7c6e82abd2a7be08ead537ab84855e76edc3b290
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688400
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72677}
Reasons:
* We disabled it more than a year ago for all configs
* Not easy to re-enable
* Not compatible with pointer compression as-is
* Not compatible with concurrent TP/TF as-is
* No concrete plans to re-enable it
Also remove Map's layout_descriptor since it was only used for double
field unboxing.
Bug: v8:11422
Change-Id: I9260906eac199213b3210712e9903f1ecf1d7979
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676637
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72671}
cppgc/testing.h is already part of a testonly gn target which only can
be included from other test targets. This prevents any production
target to depend on cppgc/testing.h.
Bug: chromium:1056170
Change-Id: I51f6c47ffac2a05c8c63d7b4663c456a64fe75b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689196
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72670}
Currently %OptimizeFunctionOnNextCall returns if there is the function
is already optimized. This cl changes this function to allow tiering up
till we reach top tier. That allows us to tier up from Turboprop to
Turbofan using intrinsics. This cl also introduces a runtime-test
function to check if turboprop-as-toptier or turboprop-as-midtier is
enabled.
Bug: chromium:1172797, v8:9684
Change-Id: Idbd99b816d4b93e4e619be5d4ccdfe89fc561a9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2682638
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72668}
This reverts commit b471bc9318.
Reason for revert: Seems like we don't reliably deliver scriptParsed events on reload after this CL.
Original change's description:
> [wasm] Send a single scriptParsed event per script
>
> If a script was shared between multiple modules (because they used the
> same wire bytes) it could happen that we still triggered multiple
> "scriptParsed" events via CDP. This was because
> {WasmEngine::GetOrCreateScript} did not communicate back whether it
> used a cached script or whether it created a new one.
>
> This CL moves the call to {Debug::OnAfterCompile} (which triggers the
> "scriptParsed" event) to the {WasmEngine::GetOrCreateScript} method,
> such that we only call it once per script.
> Since the engine only holds a weak reference to the script, we would
> still trigger multiple events if the script is garbage-collected in the
> meantime. In this case there is no way around this, as the new script
> would have a new ID, hence we need to emit a new event to make it
> public to the debugger.
>
> R=thibaudm@chromium.org
> CC=bmeurer@chromium.org
>
> Bug: chromium:1151211
> Change-Id: I1a7986514fd708680541a0e5dc24e60f01f42c28
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
> Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
> Cq-Include-Trybots: luci.v8.try:v8_mac64_gc_stress_dbg_ng
> Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2687755
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72648}
TBR=clemensb@chromium.org,bmeurer@chromium.org,thibaudm@chromium.org
Change-Id: I6cc299734e4fcff29289355973e7660b60b49a25
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1151211
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_mac64_gc_stress_dbg_ng
Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689199
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72667}
In the latest spec, catch can take an exception index immediate, and
control-flow jumps to the appropriate catch handler depending on the
thrown exception.
Do this by allowing multiple jump targets for the same pc in labels and
in the control transfer map. At runtime, the unwinder will choose the
appropriate control transfer entry based on the exception tag, unpack
the exception and jump to the handler.
Enable the exception cctests that were currently disabled for the
interpreter, fix some issues and add tests for the new behaviors.
R=clemensb@chromium.org
Bug: v8:8091
Change-Id: I30cb8f9459647a7c6f7bfd9785b238a9c9e9fc10
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690587
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72661}
HeapBase::CollectStatistics returns a HeapStatistics struct that can be
used by blink to populate a memory dump.
Bug: chromium:1056170
Change-Id: Ic147a02ba6b4aa77bf92cfca067da70b7e1af55b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689181
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72660}
WrapperDescriptor is used to describe how JS wrapper objects can be
inspected to find C++ wrappable objects. In addition, to specifying
which embedder fields are used to find type and instance, the
descriptor also provides and embedder id that identifies
garbage-collected objects. It is expected that the first field of the
type is a uint16_t with that id.
Bug: chromium:1056170
Change-Id: I9cf8d79db972f2dea023114fd5a567e89a3bf373
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688399
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72657}
If a script was shared between multiple modules (because they used the
same wire bytes) it could happen that we still triggered multiple
"scriptParsed" events via CDP. This was because
{WasmEngine::GetOrCreateScript} did not communicate back whether it
used a cached script or whether it created a new one.
This CL moves the call to {Debug::OnAfterCompile} (which triggers the
"scriptParsed" event) to the {WasmEngine::GetOrCreateScript} method,
such that we only call it once per script.
Since the engine only holds a weak reference to the script, we would
still trigger multiple events if the script is garbage-collected in the
meantime. In this case there is no way around this, as the new script
would have a new ID, hence we need to emit a new event to make it
public to the debugger.
R=thibaudm@chromium.orgCC=bmeurer@chromium.org
Bug: chromium:1151211
Change-Id: I1a7986514fd708680541a0e5dc24e60f01f42c28
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_mac64_gc_stress_dbg_ng
Cq-Include-Trybots: luci.v8.try:v8_linux_gc_stress_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2687755
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72648}
V8 implements a fast-path for RegExp.prototype.split which diverges
from the spec: instead of creating a new sticky regexp instance
`splitter` and running it in a loop, we reuse the existing non-sticky
regexp without looping through each character.
This works fine in most cases, but we run into issues when matching at
the very end of the string. According to the spec, matches at the end
of the string are impossible in @@split, but in our fast-path
implementation they can happen.
The obvious fix would be to remove our fast-path but this comes with
high performance costs. The fix implemented in this CL adds a special
flag to `exec` s.t. matches at the end of the string can be treated as
failures. This is only relevant for @@split.
Bug: chromium:1075514
Change-Id: Ifb790ed116793998d7aeb37e307f3f3f764023d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2681950
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72644}
Also move it from post-mvp to mvp, since it is now in the proposal.
Bug: v8:11002
Change-Id: I711ee7a92e6937948c93e6028ef018188ea4c976
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676937
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72643}
This reverts commit a16add806d.
Reason for revert: Broke Win32 debug https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32%20-%20debug/29653/overview
Original change's description:
> [wasm-simd][ia32] Implement i64x2 signed compares
>
> The code sequence is exactly the same as x64.
>
> Bug: v8:11415
> Change-Id: I53ed2723eda29c0a250cff514372a3d45b203476
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683495
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72637}
TBR=bbudge@chromium.org,zhin@chromium.org
Change-Id: Idbfc8cd0fbbff607cff76953c53d0c149b87b573
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:11415
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688074
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72640}
The code sequence is exactly the same as x64.
Bug: v8:11415
Change-Id: I53ed2723eda29c0a250cff514372a3d45b203476
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683495
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72637}
This reverts commit 60748ee2df.
Reason for revert: Broke Linux64 ASAN https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20ASAN/38792/overview.
There are 4 changes in that range causing the failure, I found that this change caused the failure by running locally `./tools/run-tests.py --outdir=out/repro mjsunit/wasm/gc-stress --variant turboprop_as_toptier --random-seed-stress-count 100`.
Original change's description:
> Reland "[interpreter] Speed up the BytecodeArrayAccessor through direct memory access"
>
> Tbr: ulan@chromium.org, neis@chromium.org, leszeks@chromium.org
> No-Presubmit: true
> Change-Id: I4ceb9e21ac7d78a87776b4be174772539d2da8d9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685173
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72632}
TBR=ulan@chromium.org,neis@chromium.org,leszeks@chromium.org,verwaest@chromium.org
Change-Id: I441ddfda5d852b7a01f38a9e60edc56f40ae626a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2686266
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72635}
With top-level await, when Evaluate is performed on an already-evaluated
synthetic module, Module::InnerEvaluate returns undefined. This breaks
top-level await's assumption that the returned value is always a
promise.
In order to make SyntheticModule's behavior consistent with
SourceTextModule, the top_level_capability field is moved up to Module
and SyntheticModule::Evaluate places the promise returned from the
host's evaluation steps in that field. Now SourceTextModule and
SyntheticModule can share the same code to handle the case where the
module is either kErrored or kEvaluated, so the code for this
is moved up to Module.
Thus, SyntheticModule is now guaranteed to return the
promise from the evaluation steps even on subsequent Evaluate() calls.
Unfortunately Node hasn't yet updated their EvaluationStepsCallback
to return a Promise, so we can't yet assume that the returned value
is a Promise without breaking Node. So, this change also adds a clause
to check for this condition and create a new resolved Promise if one
was not provided by the callback steps. This could eventually be
removed once Node's callback steps are updated for top-level await.
Change-Id: I2d6ae918abfeba9e3a757838502d4df92946edaa
Bug: v8:11398
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2673794
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72629}
The implementation is similar to the callbacks that already exist for
the origin trial for WebAssembly simd.
Bug: v8:8091
Change-Id: I969b68c209ea62cf70dbaf317616300b782b5e14
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2672020
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72628}
Previously in https://chromium-review.googlesource.com/c/v8/v8/+/2545573
I updated BasicBlockInstrumentor to use 64-bit floating-point values
rather than 32-bit integers, so that it could never overflow. However,
I've now learned that some builtins (particularly RecordWrite) are not
allowed to use floating-point registers, and so running with
basic block instrumentation enabled could produce incorrect results.
This change switches back to 32-bit integers, but adds saturation logic.
Bug: chromium:1170776
Change-Id: Icbd93919fb05f50d615ec479263142addbe15c9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685617
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72626}
Dropping the gpu:none dimension broadens the choice of Mac bots from
so far only 8-core VMs to also include 4-core and 12-core Mac Minis.
This CL adjusts the shard configs to account for adding
4-core Mac Minis to the choice.
We also skip a test that's slow only on 4-core bots.
No-Try: true
Bug: chromium:1174040,v8:11418
Change-Id: Ic0be0db197341b7b8f88eb30aa284c38b0e69609
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685164
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72623}
By disengaging it from 'let' which is not implemented in liftoff yet.
Bug: v8:7748
Change-Id: I191695767bf8c6153f70d509dd13ff734fe75e01
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676631
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72620}
This reverts commit 42cd9eb78d.
Reason for revert: Clusterfuzz issues, e.g.
https://bugs.chromium.org/p/chromium/issues/detail?id=1176318
Original change's description:
> [compiler] Directly read PropertyCells
>
> Main changes:
>
> - Introduce a new broker data kind kBackgroundSerialized for objects
> that can be serialized in the background (when direct reads are on).
> (I'm planning to remove kPossiblyBackgroundSerialized in a followup,
> in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
> - Make PropertyCell use that new kind.
> - Introduce a bottleneck in runtime code for changes to PropertyCells
> and make sure that a certain protocol is followed that allows
> concurrent reads from the background thread.
> - Improve interface of PropertyCell in various ways.
>
> Bug: v8:7790
> Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72586}
TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org
Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180
Bug: v8:7790
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72619}
This is a partial revert of https://crrev.com/c/2457669/.
This change is slightly longer (in code-generator-x64.cc) because we
also implement support when SSE4_2 is not supported (the reverted change
seems to assume SSE4_2, which is not always the case). This code
sequence is from https://github.com/WebAssembly/simd/pull/412.
Bug: v8:11415
Change-Id: I3eef415667b4142887cf1c449d27d19ba5bbd208
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683219
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72611}
Implements https://github.com/tc39/ecma262/issues/2034
Currently the token sequence `for (async of` is ambiguous. It can be the
prefix for either `(async of => {};;);` or `for (async of foo);`. This
CL disallows the token sequence.
Note that `for await (async of` is still allowed, since there is no
C-style `for await (;;)`, and thus no ambiguity.
Bug: v8:11412
Change-Id: I3fede83a69420996baa2bc8b6c1cff000535d990
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683221
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72607}
- Removes kPadArguments boolean.
- Changes ShouldPadArguments to ArgumentPaddingSlots to reflect
that on some architectures more than 1 padding slot may be needed.
- Adds AddArgumentPaddingSlots and ShouldPadArguments convenience
functions.
Bug: v8:9198
Change-Id: Iba87518e071a75fb951b490d3f75a87ca715cc23
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679109
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72605}
This very large changeset adds support for RISC-V.
Bug: v8:10991
Change-Id: Ic997c94cc12bba6881bc208e66526f423dd0679c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571344
Commit-Queue: Brice Dobry <brice.dobry@futurewei.com>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72598}
The is_awaiting bit on async generators distinguishes waiting on an
await. When the async generator resumes from an await, the is_awaiting
bit is cleared.
It is possible through overriding Promise#constructor that `await`
throws *after* setting is_awaiting. There is an implicit try-catch
around the body of the async generator such that, usually, caught
exceptions would clear the is_awaiting bit. However, the exception
thrown from a monkeypatched Promise#constructor can be caught by script,
and thus never clear the is_awaiting bit.
This CL sets the is_awaiting bit *after* `await` completes, with the
exception of the return resumption. It is not possible to have the
exception thrown by the await in the return resumption be caught by
script.
Bug: chromium:1171667
Change-Id: I0b615617a5c949f03350ab0f06c42920d43b5488
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2659508
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72593}
Turboprop doesn't use optimizations based on field constness to reduce
the number of deoptimizations. While this is safe for loads, for stores
if a different value is stored to a const field we should update the
constness of the field. This is needed so we can safely deopt any other
code that is relying on the constness of the field. Currently, turboprop
doesn't do this. So for now treat stores to constant fields similar to
TurboFan. In future, we may consider adding code to update the field
constness if necessary to reduce the number of deoptimizations.
Bug: chromium:1172797, v8:9684
Change-Id: I1d660457cb5d647e1283a495040a7e452fe1ac7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2673401
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72590}
- Fixes a problem when constructing Wasm CallDescriptors, where the
allocation tries to treat parameters and returns as if they are in the
same frame. This doesn't work when slots may be aligned in their
frame. Instead, allocate parameters and returns separately and offset
return slots by the number of parameter slots.
- Adds argument slot padding in the CallDescriptor lowering case, to
prepare for when 32 bit targets align stack frames and require
padding.
- Adds a regression test.
Bug: chromium:1174500
Change-Id: I60d96a94b171a0d27ff61cbab35623976b0c6da8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683024
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72588}
Main changes:
- Introduce a new broker data kind kBackgroundSerialized for objects
that can be serialized in the background (when direct reads are on).
(I'm planning to remove kPossiblyBackgroundSerialized in a followup,
in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
- Make PropertyCell use that new kind.
- Introduce a bottleneck in runtime code for changes to PropertyCells
and make sure that a certain protocol is followed that allows
concurrent reads from the background thread.
- Improve interface of PropertyCell in various ways.
Bug: v8:7790
Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72586}
The detached CppHeap allows for allocation without invoking garbage
collections. Allocated bytes are reported on the first allocation
after the CppHeap has been attached to an Isolate.
States:
- Detached: Allow only allocation;
- Attached: Unified heap GCs;
- Termination GC: Require detached state;
Destruction:
- Heap::TearDown: Detach if attached;
- ~CppHeap: Detach if attached;
Bug: chromium:1056170
Change-Id: I95ce029f36a7f10392257080b6e23e13cc0fc7b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2672940
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72579}
This fixes a false positive TSAN report where an object transitions to
a new map in StoreIC. The scenario:
1) Object a transitions from map1 to a newly created map2 in runtime.
The map is installed with a release-store.
2) Object b transitions from map1 to map2 in StoreIC in generated code
that is not visible to TSAN.
3) Concurrent marker visits object b and loads it map with an acquire
load.
Since TSAN does not see the store in step (2) it thinks that the map
loaded in (3) is freshly allocated and is not guarded by a release
store.
Bug: v8:11353
Change-Id: Ifcace9edff987761a4098d3fdfb98c6190f1ee1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2682641
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72578}
This adds support for kBool, kInt32, and kUint32 types.
Bug: chromium:1052746
Change-Id: I54641eb036eea30113c44eab2c08626176ecc40a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2629463
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72574}
BREAKING CHANGE: The values of Wasm locals, stack, and globals are now
represented as objects instead of holding the (primitive) values
directly, and SIMD128 values are no longer represented as Uint8Arrays.
The DWARF extension has been prepared for this breaking change.
The new `WasmValue` comes with `type` and `value` properties that hold
its contents. The motivation here is that this is a more extensible
approach. In case of SIMD128, the `value` property holds the canonical
string representation, which has the additional advantage that these
values can be compared with `===` (and `==`).
This partially reverts https://crrev.com/c/2614428, the main difference
here being that WasmValue is now a proper JSObject that can be exposed
on the DebugEvaluate proxy API.
Screenshot: https://imgur.com/rcahNKM.png
Bug: chromium:1170282, chromium:1071432, chromium:1159402
Change-Id: Iea304e3680775123c41deb4c3d172ac949da1b98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2643384
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72570}
Those references would be passed over to Blink via buffer and dropped
after a virtual call.
Bug: chromium:1056170
Change-Id: Idd02acce7a2d5c927dd9dc2415fe507b00ff3e58
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2682646
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72568}
Prototype these 6 instructions on arm:
- f64x2.convert_low_i32x4_s
- f64x2.convert_low_i32x4_u
- i32x4.trunc_sat_f64x2_s_zero
- i32x4.trunc_sat_f64x2_u_zero
- f32x4.demote_f64x2_zero
- f64x2.promote_low_f32x4
For all these instructions we rely on having Q registers that map to S
registers, which means we can only use q0 to q7. We fix the src/dst
to q0 arbitrarily.
Bug: v8:11265
Change-Id: Ied95f2dde9859a60fc216ed67615f80e9d795bb7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679842
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72567}
Update the wasm spec tests to include the memory64 proposal. Some tests
are failing currently because of broken spec tests or missing v8
support. This will be addressed in follow-up CLs.
R=ahaas@chromium.orgCC=zhin@chromium.org
Bug: v8:11401
Change-Id: I1a8f75e70f9d0828ad32c960c113f5e4c0d1a44b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679683
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72561}
This change avoid dispatching a write barrier during the atomic pause.
The dispatch can generally be triggered through pre-finalizers.
In future, further checks may be added to avoid mis-use of
pre-finalizers.
Bug: chromium:1056170, chromium:1175560
Change-Id: I119e18372633b2375f60e17b4c881f68bb20bf66
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679685
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72560}
For functions with a very large stack, the debug side table repeats a
lot of information: Most values will be spilled to the stack, still
every single entry in the debug side table repeats information about
them (type, stack offset). This leads to the size of the debug side
table to be quadratic in the size of the function.
In the linked bug, the generation of the debug side table took ~400ms,
whereas Liftoff compilation alone just took 16ms.
This CL optimized the debug side table by delta-encoding the entries,
i.e. only storing stack slots that changed. This reduces the size of the
table significantly, at the cost of making lookup slower, since that now
has to search the table backwards for the last entry that had
information about a specific slot. For now, this seems like a good
compromise. If it turns out to be a problem, we could speed up the
lookup by either forcing a full dump of the stack state after N entries,
or by dynamically inserting new entries during lookup, whenever we find
that we had to search backwards more than N entries. That would speed up
subsequent lookups then.
On the reproducer in the linked bug, this change reduces the time to
generate the debug side table from ~400ms to ~120ms.
Before this CL, the debug side table has 13,314 entries with a total of
38,599,606 stack value entries. After this CL, it shrinks to 20,037
stack value entries in the 13,314 entries (average of ~1.5 instead of
~2,899).
R=thibaudm@chromium.org
Bug: chromium:1172299
Change-Id: Ie726bb82d4c6648cc9ebd130115ee7ab3d1d551b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676636
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72558}
Some types of supported low-level write barrier only requires passing
a slot, which may not be even part of a heap object but stack.
This complicates the situation, as even with caged heap, there's no
way to distinguish a stack and heap slot.
Solve this by passing an optional callback that can lazy be used to
get the heap. This can be used by the embedder to retrieve the heap
from e.g. TLS if needed. This aligns the barrier with Oilpan in
Blink.
Bug: chromium:1056170
Change-Id: I1e5d022ab17a2614a67b6ef39ed12691bcbd0ac6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2675924
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72550}
A background thread can register a callback that is guaranteed to be
invoked after each GC in a safepoint before background threads resume.
This will be allow the background compiler and parser to keep raw
pointers to frequently accessed objects and ensure that they are fixed
up after GC.
Note that the existing global GC epilogues are run after background
threads resume, so they are unsafe for background threads.
Change-Id: I1c782f912d63afc09c4982d393a6f3805a318962
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2675933
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72548}
In JSStackFrame::GetMethodName() we try to infer a useful method name to
show for the closure to which the stack frame belongs. This is done by
first considering the functions name, and checking if the receiver has a
property with that name and if that property's value is the closure. In
case the function doesn't have a name or the property's value is not the
closure itself, we fall back to a reverse lookup of the closure within
the object (and its prototypes).
This CL speeds up this logic by attacking two problems:
1. The reverse lookup was performed by first using the KeyAccumulator to
extract the names of all enumerable properties, and afterwards using
the LookupIterator on each name, and testing the resulting property
value against the closure. This is fairly slow and creates a lot of
temporary objects and handles. We now look into the descriptor arrays
or dictionary backing stores of the objects directly instead, which
is easily 2-10x faster.
2. For the common case of `o.foo = function() { ... }` the parser already
places an "inferred name" of `o.foo` onto the SharedFunctionInfo,
which we can use as a hint to infer the name of the function instead
of immediately falling back to the expensive reverse lookup.
This repairs the regression reported in http://crbug.com/1069425 and
recovers most of the slowdown reported in http://crbug.com/1077657
(there's still some overhead left from the async stack trace tracking).
Fixed: chromium:1069425
Bug: chromium:1077657
Change-Id: I88d23ccad123906df70c5217e815493106e03ccf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676635
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72545}
This requires a small fix in {Push,Pop}CalleeSavedRegisters, where
the return address was signed/authenticated at the wrong point,
which meant the stack pointer used as modifier was different from
the one the StackFrameIterator expected.
Bug: v8:10026
Change-Id: Idebd2ee8f07312b5e99dd2ea5181fc7a7e4a87bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667861
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72542}
This is a reland of 6ada6a90ee
- Fixed a GC issue
https://bugs.chromium.org/p/v8/issues/detail?id=11335:
GC expected all arguments on the stack from code with
CodeKind::TURBOFAN to be tagged objects. This is not the case now with
inlined Wasm calls, and this information can be passed in
SafepointEntry for each call site.
- Disabled JS-to-Wasm inlining for calls inside try/catch.
For more details, see updated doc:
https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
Bug: v8:11092
Original change's description:
> Reland "Faster JS-to-Wasm calls"
>
> This is a reland of 860fcb1bd2
>
> - Disabled the tests for this feature in V8-lite mode (the original
> change broke V8-lite tests).
> - Also modified test console-profile-wasm.js that was brittle with this
> change because it assumed that there was always a JS-to-Wasm wrapper
> but this is not the case when the TurboFan compilation completes before
> the Liftoff-compiled code starts to run.
>
> More changes in Patchset 8:
>
> - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
> into a new phase, wasm-inlining that reuses the JSInliner reducer.
> The doc
> https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
> describes the new logic.
>
> - Fixed a couple of small issues in wasm_compiler.cc to make sure that
> the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
> this should solve the problem we had inlining the calls in functions
> that can throw exception.
Original change's description:
> Faster JS-to-Wasm calls
>
> This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
>
> Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
> the basis of the signature of a Wasm function to call, and whose task
> is to:
> - set "thread_in_wasm_flag" to true
> - convert the arguments from tagged types into Wasm native types
> - calculate the address of the Wasm function to call and call it
> - convert back the result from Wasm native types into tagged types
> - reset "thread_in_wasm_flag" to false.
>
> This CL tries to improve the performance of JS-to-Wasm calls by
> inlining the code of the JS-to-Wasm wrappers in the call site.
>
> It introduces a new IR operand, JSWasmCall, which replaces JSCall for
> this kind of calls. A 'JSWasmCall' node is associated to
> WasmCallParameters, which contain information about the signature of
> the Wasm function to call.
>
> WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid
> generating code to convert the types for the arguments
> of the Wasm function, when the conversion is not necessary.
> The actual inlining of the graph generated for this wrapper happens in
> the simplified-lowering phase.
>
> A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
> lazy deoptimizations that can happen if the Wasm function callee calls
> back some JS code that invalidates the compiled JS caller function.
>
Bug: v8:11092
Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
Change-Id: Ie052634598754feab4ff36d10fd04e008b5227a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649777
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72541}
This prototypes i32x4.widen_i8x16_s and i32x4.widen_i8x16_u for arm64.
Bug: v8:11297
Change-Id: Ib9be5086c8ea98340c9bb1980c319626d7072c1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2664994
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72537}
