- moved test data closer to tests
- removed the coverage related code
- refactored to remove boilerplate from test code
Bug: v8:12785
Change-Id: I1013d29d8ff2c3ecb786c294ae3b3ab6decdca20
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3683610
Commit-Queue: Liviu Rau <liviurau@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80921}
Code ageing too early can have a bad impact on performance. Let's
evaluate keeping code alive a little longer. Later we can look at more
elaborate heuristics.
Change-Id: Ib220c4dcd24165d6b6e5020cb1829c669ed3e736
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3686416
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80920}
Currently, if the same script text is compiled multiple times with
differing details (such as name, line number, or host-defined options),
then multiple copies of that script are added to the Isolate's
compilation cache. However, any attempt to look up those scripts can
find only the first instance. This change makes the script compilation
cache behave more consistently by checking the details while searching
the hash table for a match, rather than after a potential match has been
found.
Bug: v8:12808
Change-Id: Ic9da0bf74f359d4f1c88af89d585404f173056ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3671615
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#80919}
This reverts commit c7aef55208.
Reason for revert: Merged the wrong CL for the fix.
Original change's description:
> [maglev] Fix dead fallthrough merging
>
> Add a method which optionally merges dead fallthrough paths, in case the
> iteration in EmitUnconditionalDeopt reaches a merge point that is live
> from another jump but dead on the fallthrough.
>
> Bug: v8:7700
> Change-Id: Ie505cd5356fcf70208f2f6d3e52b805956485f74
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663086
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80878}
Bug: v8:7700
Change-Id: I75a21777aecfa08138fcc25a882ae109f3409159
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687649
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#80917}
Use the existing {base::Optional} instead of the extra {MaybeBoolFlag}
struct. This makes writing to a maybe-flag simpler because you just
write a boolean value and that automatically initializes the optional.
R=cbruni@chromium.org
Bug: v8:12887
Change-Id: I940d20286d65ba4355dc04b4b6068a306706f295
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3686412
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80915}
This adds a new flag to freeze all flag values after initializing V8.
For now, the only effect is that future calls to {SetFlagsFromString},
{SetFlagsFromCommandLine} or {EnforceFlagImplications} will fail.
In the future (once tests and embedders are fixed to not change flags
after initialization) we plan to actually protect flag values via memory
protection.
R=cbruni@chromium.org
Bug: v8:12887
Change-Id: I7974bb9b86715694122f788e08952f7dcc3acdbd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3679099
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80914}
We should not use kSimd, which has already shipped. Instead, use a new
kRelaxedSimd bailout reason.
R=thibaudm@chromium.org
Bug: chromium:1324081
Change-Id: I394e288014245ed9ae69e20f811f8cf7555e6149
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3686413
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80913}
We introduce a typing phase into the Turbofan compilation pipeline for
wasm-gc. It has two functionalities: (1) to type nodes that were not
typed during code generation (mainly phi nodes) and (2) to narrow types
as much as possible.
The following nodes are handled, which should be enough for our
purposes: TypeGuard, WasmTypeCast, AssertNotNull, Phi, LoadFromObject,
and LoadImmutableFromObject.
Loop phi types are computed by first assigning the type of the
non-recursive input, and updating once we have the type of the recursive
inputs, and repeating this process to a fixed point.
Drive-by: Remove the narrowing of function signatures during wasm
inlining, as it created some issues and should not be needed after this
series of changes.
Bug: v8:7748
Change-Id: I8a72488d5c221c4ae8257fc5abf6f0368cf10e96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3678208
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80912}
code cache logic
Previous break condition is meeting JumpLoop to loop nesting level 0,
this is probably a JumpLoop getting removed if it's dead code. Add out
of bytecode array to break condition for avoiding dead loop in the case
of the JumpLoop to loop nesting level 0 getting removed.
Bug: v8:12927
Change-Id: I854187a6e226c4537981ffbbb7e88f1584cf70e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3686589
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Tao Pan <tao.pan@intel.com>
Cr-Commit-Position: refs/heads/main@{#80909}
Previously if we had no bytecode the SFI wasn't removed. This was a bug
introduced after replacing Fullcodegen ageing (where we checked the code
object, which could have been the lazycompilestub).
Change-Id: I13add56a2c62fffddb11abdc35019272abc72c30
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3686409
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80908}
In https://crrev.com/c/3522896 we changed the last_id_ to be a member
variable. This subtly changed how profile id's were generated.
This CL changes this part back to a static variable that guarantees
process-wide unique profile ids.
Bug: chromium:1330726, chromium:1297283
Change-Id: I5f3dddcbbc156d0dee7d1eedde8a731c53d080dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3684289
Auto-Submit: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80902}
Currently getting the following error with gcc 8.4,
including on x64 linux:
```
error: ':InterpreterState::scratch_' is used uninitialized in this function
```
Change-Id: I95ae848bf2503f6a0dac30254b19b08047b73cce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3683104
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#80901}
The fuzzer instantiates the module twice: Once for reference
interpretation / execution, and once for the actual execution of
Liftoff/TurboFan code.
For some reason, the two code paths for interpretation and Liftoff
reference execution used different patterns: Interpretation was using
the first instance, and then creating a second instance for actual
execution, whereas the Liftoff path used a second instance for the
reference execution and used the first one for the actual execution.
This CL refactors this to always create a "reference instance" first,
use that for either the interpreter or Liftoff, and then create a second
instance for the actual execution.
R=thibaudm@chromium.org
Bug: v8:12425
Change-Id: I19754264240d8570f00161abb7aecba1cc2b2ae0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3683323
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80900}
This is a partial reland of https://crrev.com/c/3597106 including fixes
from https://crrev.com/c/3654413
Before this change, a script cache key is the same format as an eval
cache key, which is a FixedArray containing:
- The SharedFunctionInfo of the containing function
- The source text
- The language mode in which the code was parsed
- The position in the source where eval was called
After this change, a script cache key is a WeakFixedArray containing:
- A weak pointer to the Script
- The hash value of the source text
This sets up for a subsequent change which can cause these keys to
outlive their corresponding values (top-level SharedFunctionInfos)
without leaking any memory beyond the key itself.
Bug: v8:12808
Change-Id: Ibdfe5d10eafe5b7392e554c500af47975baf45c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3668304
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#80899}
The OOB check belongs in ValidateIntegerTypedArray according to the
spec.
This also fixes the error types for OOB TypedArrays when doing Atomics:
OOB TypedArrays should get a TypeError, not RangeError.
Bug: v8:11111
Change-Id: Ice2e5695d69d84b2c20a4cf8f06880673d901a91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3676859
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80898}
This CL addresses a TODO left from implementing Wasm entry to fast C
calls in https://chromium-review.googlesource.com/c/v8/v8/+/3440694/
and avoids generating a branch in case it's not needed (either because
the embedder isn't providing an options object, which is the case
for Wasm, or because we're not generating overloads).
Bug: chromium:1052746
Change-Id: I7323f85801c034f0c47877ea15f677a53d3acea3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3650923
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80897}
IsCompiledScope retains code to protect against code flushing. The
current API is easily misused by forgetting to initialize
IsCompiledScope with a SFI's current state.
Change-Id: Ie8ab60acc4fb85c4b8b76c52040976e2e34f9d5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3674117
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80896}
Some parses are actually re-parses of an already parsed function; things
like source position collection, CallPrinter AST walks, debugger, etc.
These may want slightly different parse behaviour -- in particular, we
likely don't want to post parallel compile tasks for them. So, keep
track externally of which parses are reparses, and suppress parallel
compile tasks for them.
Change-Id: I8b38caad1a385e08231bd247774e9804a409de0e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3291317
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80895}
MinorMC only used a single color (grey) while the full MC used 2 colors
(grey and black). Update MinorMC to use black as well. This aligns and
brings full MC and MinorMC closer, and allows to reuse more of the
existing sweeping infrastructure for the non-moving MinorMC.
Bug: v8:12612
Change-Id: Ifa740537c4587dc197196e41829ea74a312b79d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3683320
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80894}
The fuzzers sometimes fail to instantiate a module that we already
instantiated before. This is nondetermistic and hard to reproduce (maybe
an out-of-memory situation).
Make the fuzzers print the error message so we learn more about those
failures.
R=ahaas@chromium.org
Bug: chromium:1330572
Change-Id: I0db103bdb113b1c1cedf662e02fb7a7f9d34ebd7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3680298
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80893}
The last line of output (which is not terminated by a newline) was not
showing for me when running the merge script. We can either fix it by
specifying `flush=True` at the `print` statement, or flushing before
reading user input. The latter seems more future-proof.
R=machenbach@chromium.org
Change-Id: I61cb929d2f7cdd20b3e32b9beb1653fe2d5c5791
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3676857
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80890}
The removing the optimized OSR code logic depends on collecting
the reference of the optimized OSR code in ic.
Bug: chromium:1330405, chromium:1330452, chromium:1330454, chromium:1330486, chromium:1330545
Change-Id: I0981a6b2f41bd7f90b74a1866c91d6eb35c5c591
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3679846
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Tao Pan <tao.pan@intel.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80886}
List all variants for the --variant help text
Change-Id: I249d8140b19e13dc3eceedaade2b856b1fdb1567
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663088
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80884}
When injecting locations for block-end gap moves into Phis, make sure to
maintain register frame state too, so that the subsequent
MergeRegisterValues call sees the result of these moves.
Bug: v8:7700
Change-Id: I4f68e386c5a6cc578d26904306cb9b0c2f7a90d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3676861
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80879}
Add a method which optionally merges dead fallthrough paths, in case the
iteration in EmitUnconditionalDeopt reaches a merge point that is live
from another jump but dead on the fallthrough.
Bug: v8:7700
Change-Id: Ie505cd5356fcf70208f2f6d3e52b805956485f74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663086
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80878}
Rolling v8/build: b2f1ec8..fb6ee35
Rolling v8/buildtools: a5fa465..8b16338
Rolling v8/buildtools/linux64: git_revision:c547ca1497e3ff0dcbc0b2cb036b3d40380cbeeb..git_revision:37baefb026b199605affa7bcb24810d1724ce373
Rolling v8/buildtools/third_party/libc++/trunk: 79a2e92..b126981
Rolling v8/buildtools/third_party/libc++abi/trunk: 4ad92ec..c30c515
Rolling v8/buildtools/third_party/libunwind/trunk: d03f56b..5e737be
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/a1cf7a2..fba169d
Rolling v8/third_party/depot_tools: 4e6aa25..e1197f0
Rolling v8/third_party/fuchsia-sdk/sdk: version:8.20220522.3.1..version:8.20220531.3.1
Rolling v8/third_party/zlib: 80b28c9..64bbf98
Rolling v8/tools/clang: 6df1876..393c871
Rolling v8/tools/luci-go: git_revision:0ef9351a5b73943d547fb27d463d5f4a1572727f..git_revision:de014227dd270df7c61bfab740eb4ae4b52ac2a7
Rolling v8/tools/luci-go: git_revision:0ef9351a5b73943d547fb27d463d5f4a1572727f..git_revision:de014227dd270df7c61bfab740eb4ae4b52ac2a7
R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: I350575968cfc4adfe6d6785146735d83debfa0a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3682481
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#80876}
This is a reland of commit ea9a1f1cbe
Changes since revert:
- Make the state field uintptr-aligned since arm64 faults on
atomic accesses to non-naturally aligned addresses.
Original change's description:
> [shared-struct] Add Atomics.Mutex
>
> This CL adds a moving GC-safe, JS-exposed mutex behind the
> --harmony-struct flag. It uses a ParkingLot-inspired algorithm and
> each mutex manages its own waiter queue.
>
> For more details, please see the design doc: https://docs.google.com/document/d/1QHkmiTF770GKxtoP-VQ1eKF42MpedLUeqiQPfCqus0Y/edit?usp=sharing
>
> Bug: v8:12547
> Change-Id: Ic58f8750d2e14ecd573173d17d5235a136bedef9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3595460
> Commit-Queue: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80789}
Bug: v8:12547
Change-Id: I776cbf6ea860dcc6cb0ac51694a9b584b53d255c
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_mac_arm64_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3673354
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80875}
When async compilation finishes for WebAssembly, the promise returned by
`WebAssembly.compile()` gets resolved. Resolving the promise creates a
microtask that should get executed automatically when the call stack
empties up when MicrotasksPolicy::kAuto is used. However, this policy
requires a CallDepthScope to work, but there is no CallDepthScope when
WebAssembly compilation finishes. This CL adds this CallDepthScope.
R=jkummerow@chromium.org
Bug: chromium:1297672
Change-Id: I1bd607dec9daf08b3dbb1294393a8af255d222ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3679579
Auto-Submit: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80872}
