This type is uninhabited by any actual values, but it can show up
as a "theoretical" value in the type system, e.g. for conditional
branches that are statically never-taken.
Bug: v8:7748
Change-Id: Ieb8a5354dbd04fe76e1047766c5bb60f02f6cdd0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4013859
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84125}
We may try to notify full sweeping completed twice.
The scenario is as follows:
1) Start full sweeping.
2) Start a minor GC. V8 sweeping is out of work so we finalize. Oilpan
sweeping is still on-going. Start minor sweeping
3) Start another minor GC. Minor sweeping is out of work so we finalize
it. Oilpan sweeping is still on-going.
FinishIfOutOfWork always finalizes full sweeping. Thus in the above
scenario, when we finalize a second time, we enter
NotifyFullSweepingCompleted which assumes it is not called twice for the
same GC, but it is called multiple times as long as Oilpan sweeping is
not finished.
Bug: v8:12612
Change-Id: Ie172cef5515ba8a09751e80fd09a733f868c4127
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4013682
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84124}
Currently, if a script is deserialized on a background thread and a
matching Script object is found in the Isolate compilation cache, the
new content is merged into the existing Script. This CL implements the
same merging for the much simpler case of deserializing on the main
thread. I expect speed changes to be minimal, because merging is only
needed in a small minority of compilations. When needed, it usually
takes about 10% as long as the corresponding deserialization.
Bug: v8:12808
Change-Id: Ie7a92bcb3111edf4cdab0eddeb7567979b35f437
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4010100
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#84123}
In particular, the validation happening during decoding has a few more
checks whether it's actually necessary to validate. In particular, it's
not necessary if the functions will get eagerly compiled with Liftoff
anyway.
R=ahaas@chromium.org
Bug: v8:13447, chromium:1382051
Change-Id: I7fb9f81d840956db10256b5b870edbd85e787332
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008842
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84122}
Reset counter whenever we should grow, not just when we actually grow.
Bug: chromium:1381850
Change-Id: I4b246e8197729e49348052ea4d4c0688c215d08e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4013160
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84121}
- Debounce creating tooltips to declutter the UI
- CTRL-mouse move causes immediate tooltips
- Use icons and help text on tooltip buttons
- Recreate tooltip target nodes in timeline views to avoid moving the
existing tooltip if the update is debounced
Change-Id: I65a885827ebfeafc09c1c08e2cfe9c2dd448edca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4012720
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84120}
The field is initialized from the corresponding v8 flags, and never
changed to anything else. Thus use the flag value directly, which can
be read equally fast and is guaranteed to stay unchanged during
execution.
R=ahaas@chromium.org
Bug: v8:13447
Change-Id: Iec30e769e004e0360eb06e2f3e325c45976811cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008541
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84119}
When introducing heap type decoding we added some module-specific checks
to the constructor of certain immediates. This broke the previous design
where module-specific checks were done in a separate {Validate} method.
This CL restores that state.
R=jkummerow@chromium.org
Change-Id: I1ed887daecc25990272c95a24f4444da2d8b5466
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008318
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84118}
SharedFunctionInfo::DiscardCompiled must set two fields on the SFI:
outer_scope_info_or_feedback_metadata and function_data. If it causes an
allocation between setting those two fields, then the GC can see the
object in a partially updated state, which causes trouble in the GC's
bytecode flushing logic. This CL avoids the problem by performing the
allocation before updating the object.
Bug: v8:13448
Change-Id: Ifa03ecd42803dc899489eec0fd88ea763b47fb1a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4010098
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84116}
When we don't need to load Code field atomically we can compute the
Code object pointer from the code entry point by subtracting the Code
header size.
For atomic accesses we already have either the code cage base or an
Isolate from which we can load the code cage base value.
Drive-by: cleanup some unnecessary Code <-> CodeT conversions.
Bug: v8:11880
Change-Id: Ief12d13d28266c95eb8d5ba93b3afd568c4683cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008264
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84115}
When shifting a 64-bit input in MachineOptimizationReducer, where the
shift output is on 32-bit, we need to convert the input to 32-bit
before shifting, rather than shifting on 64-bit and then converting
the result (because the upper 32 bits of the input could be garbage
that would get shifted-in).
Fixed: v8:13458
Change-Id: Ida35fc92c0e3f5a00256bff0c571a3c17299b789
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008364
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84114}
Change-Id: Ife69129bc0bf5e565154b7e04bc1d6ad4d106c0c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4006746
Auto-Submit: Juan José <soyjuanarbol@gmail.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84113}
Controlled by a command-line flag --wasm-disassembly-max-mb,
set to 1000 MB for now. The intention is to avoid OOM crashes
for huge modules.
Bug: chromium:1362286
Change-Id: Ifc0cdd7e8dda016c7cc65dcd75ff6ed51c785a6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008625
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84111}
When a 32-bit binop operates on the result of a 64-bit shift, for
example the decoding of a BoundedSize, the previous code would attempt
to perform the shift as part of the 32-bit binop, failing a CHECK when
attempting to get the 32-bit shift constant. With this CL, the
instruction selector will now only attempt to perform the shift as part
of another binop if both operations are either 32-bit or 64-bit.
Bug: chromium:1379738
Change-Id: I2e4cf54fe5b0edcd28bf0ffd662e43259cb6bebf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3990832
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84110}
This CL adds the regression test originally authored for
crbug.com/1085693. It no longer crashes or re-produces but we were
unable to bisect to the CL that fixed the problem since bisecting
seems to be broken.
R=bmeurer@chromium.org
Fixed: chromium:1085693
Change-Id: Iaaf2b557767a02829fc497591ed7f3623965a66c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4012718
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84108}
This is a no-op in practice because clang_ was previously only
not used if `is_chromeos && !is_clang`, but all CrOS builds use
clang nowadays.
Bug: None
Change-Id: Ife7fa1bb2cf99107136a5fa5155dd611ed83b8e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4012059
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Nico Weber <thakis@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84107}
The GN build by now supports more cross build scenarios than
the gyp build ever did.
Change-Id: Ibe1c1ab75a0c6f9d32831a016dc119b27cff002b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4012138
Auto-Submit: Nico Weber <thakis@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84106}
Rolling v8/build: 07e7b8e..dff033c
Rolling v8/buildtools/reclient: re_client_version:0.81.1.0853992-gomaip..re_client_version:0.83.0.da55f4f-gomaip
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/a1cc425..b26b298
Rolling v8/third_party/depot_tools: 03b187d..e6f3d66
Rolling v8/third_party/fuchsia-sdk/sdk: version:10.20221106.2.1..version:10.20221107.2.1
Rolling v8/third_party/zlib: 74a5a82..8bbd6c3
Rolling v8/tools/clang: b65f30f..d3df9cc
Change-Id: Icb1b19e095488b21293ec5d8d97401a679fdd56f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4011780
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#84105}
Ran into hardcoded limit when writing shared struct benchmarks.
Drive-by deletes d8's kMB in favor of internal::MB.
Change-Id: I99c0b256809a6858c9a65f7f51aac4acc0009132
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4010099
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84102}
This CL supports BigInt modulo operations in turbofan and refactors
the code in simplified lowering to avoid boilerplate.
Bug: v8:9407
Change-Id: Id9d80bd82a94a50c6684956d1f8e60f99761c517
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3976434
Commit-Queue: Qifan Pan <panq@google.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84100}
The SuppressMicrotaskExecutionScope being pushed was for the isolate's
default queue. It should be for the current queue not the default one.
This wouldn't cause any issues because microtasks are also suppressed
via the is_running_microtasks_ variable as well but is odd to read.
BUG=chromium:961186
Change-Id: Id7a64aac0fb86322014f9755f0abc0330a85556f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4004599
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84099}
If toptier is enabled and turbofan is disabled, maglev will not update
interrupt budgets anymore. This makes it easier to compare
--maglev,--noturbofan with --nomaglev,--turbofan.
Bug: v8:7700
Change-Id: Ibfe645d02d91c041c1d5ae42cb62fe1660eda50b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008618
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84098}
The BytecodeIterator does not pass a module, so we cannot validate heap
types properly. Thus disable validation completely for the
{BytecodeIterator} and provide a second method (for testing only) which
also validates.
Drive-by: Pass the {WasmFeatures} enum set by value.
R=jkummerow@chromium.org
Change-Id: Ieb231304193c789601a59c3b22a023f10b79a730
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4003079
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84097}
Instead of validating all functions synchronously on the main thread,
use a JobTask to parallelize the job. The main thread participates in
the work.
R=ahaas@chromium.org
Bug: v8:13447
Change-Id: Iab7db525882eca2a4c6754d7c8d40f5f2b82d74f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4004742
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84096}
We do not need to go through the builtin when the function reference is
already set.
For faster checks, we ensure that
{WasmInstanceObject::wasm_internal_functions} is set at instance
object instantiation time. Therefore it does not need to be optional.
Change-Id: Ie0a6564c171c6a6e3424c3cc0eeae3c83929e616
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4005823
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84095}
We should invoke {LoadContextIntoSsa} just after the {IfException}
node after a call, rather than at the catch/cathcall point.
This way, we ensure that this is done before {BuildNestedLoopExits},
and we create a {LoopExitValue} node for the reloaded memory start/
size. Also, we only need to do so for Call and not Throw nodes.
Bug: chromium:1380646
Change-Id: Ibaa8fd7e39869c38c33cf62b1b6caf9238ced969
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008578
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84094}
This adds a separate test module and output expectation for names in
the custom "name" section in Wasm binaries.
Also fixes a small inconsistency: The index of both data and element
segments is now printed as a comment, in case one prints their name
(as we do for functions, globals, etc.)
Data segment names are currently not printed for consistency with
legacy behavior.
Change-Id: I8900f54b02e031a811dfd9be8326d6f63d26d4a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4004717
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Daniel Lehmann <dlehmann@chromium.org>
Auto-Submit: Daniel Lehmann <dlehmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84093}
The builtin inlining for FunctionPrototypeCall has to consider the case
where there is no new receiver to the call. It now does this by
considering the new call args to be kNullOrUndefined instead of kAny.
Drive-by cleanup of CallArguments to always consider the register count
and not the argument count, unifying the with/without receiver
correction for the list-of-regs and RegList cases.
Bug: v8:7700
Change-Id: I7e8cb7e9d654fdfcbb8add80e7a0a01a39d36504
Fixed: chromium:1381663, chromium:1381665
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008638
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84092}
The assumption in {DecodeAtomicOpcode} (added in
https://crrev.com/c/3990654) is only true for valid opcodes. Since
Atomic opcodes are variable-length encoded, it's possible to create
out-of-bounds atomic opcodes which violate the assumption.
This CL fixes that by checking for such out-of-bounds opcodes early in
the method. This replaces the assumption, which the compiler can now
derive from the if-statement.
R=ahaas@chromium.org
Bug: chromium:1381330
Change-Id: Ifaaceb0c8a765811fe2f934be1920bcb14675f36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008538
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84091}
This used the production builder names in MB and test configs
after the orchestrator roll-out.
This can first land after:
https://crrev.com/c/4002978
Bug: chromium:890222
Change-Id: I7215fdb86e7ddddac5c2d3172fb112b30a373141
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4006615
Reviewed-by: Liviu Rau <liviurau@google.com>
Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84090}
OptimizationPhaseImpl is now called GraphVisitor. Its ReduceXXX
methods are now called VisitXXX, to avoid name conflicts with
Assembler/Reducer methods.
Its non-template-dependent fields have been moved out to a separate
class (which will be easier to use in some contexts).
Assembler now inherits from GraphVisitor (ex OptimizationPhaseImpl),
which allows it to trigger visitation of Blocks or Operations.
Bug: v8:12783
Change-Id: I14f57621c62fc83f27fae1169be514a400396ecd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3985908
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Auto-Submit: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84089}
The {BytecodeIterator} that also read locals declarations had a weird
fallback path to allow decoding of locals to fail, and just assume no
locals, decoding all bytes as code.
This CL removes that, and modifies the test that needs this
functionality to prepend a zero byte for encoding "0 locals".
R=jkummerow@chromium.org
Change-Id: I609e2bf6986eeb6380d65b03bf8512f0b09af764
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4003078
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84088}
The decoder can only fail if validation is enabled. Wrapping the {ok()}
or {failed()} checks in the {VALIDATE} macro adds likely/unlikely
annotations and removes branches in non-validating uses.
Note that the same effect cannot be achieved by overwriting {ok()} and
{failed()} in the {WasmDecoder} class (where we have access to the
{ValidationTag}). It seems like the {V8_LIKELY} annotation gets lost
when inlining.
R=jkummerow@chromium.org
Change-Id: I4e19f95b9837797e42d244f867210af0f2c05985
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4006140
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84087}
Having the printout (including object addresses) in stdout confuses the
correctness fuzzer and makes it unable to dedupe bugs properly.
Drive-by: make %GlobalPrint handle its arguments gracefully.
Change-Id: I30cad408527b549dc15963e692a760f53174a951
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3999281
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84086}
Previously, some float literals were printed with loss of information by
the Wasm disassembler, e.g., `1234567.5` was printed as `1234568`,
which is clearly wrong.
With this fix, the disassembler will always preserve information in its
output, i.e., it will print the correct `1234567.5`.
However, unfortunately, it will now print the binary representation of
`0.1` as `0.100000001`, since 0.1 can actually not be represented
exactly as a binary fraction.
Ideally, we would print the smallest representation of a float that,
when parsed again (e.g., by `wat2wasm`), produces the same float.
Unfortunately, there is currently no easy way to implement this.
There are several options, but they are either incorrect in other ways
or not available here:
- `DoubleToCString`: output will be even longer for decimal fractions
that cannot be represented in binary, since it will just round to the
nearest double instead.
- `printf` + `%g` format specifier: still prints `0.1` as `0.100000001`.
- `std::format`: C++20 only.
- `std::to_char`: C++17, but this particular header is not yet allowed.
- `absl::to_char`: Abseil is not available in V8.
It seems we have to choose either between losing information (such that
the output of the disassembler would not round-trip if assembled to a
binary again), or to have those ugly, long outputs.
Change-Id: Id40044a1724aeb115309688cbf05f71aa4745c6b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4004957
Commit-Queue: Daniel Lehmann <dlehmann@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84084}
Use the `PageAllocator` that is generated/provided via
`cppgc::InitializePlatform()`.
Bug: v8:13442
Change-Id: I7f3a83ae3fe9000b430ab085929f98646585164f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4000486
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84083}
In the case that an invalid module gets compiled twice concurrently, one
thread might get a prefix cache hit but then later not find the
corresponding cache entry (because the module is invalid, so the prefix
sentinel was deleted again). It then enters the non-streaming async
compilation path at the {PrepareAndStartCompile} phase. This phase
assumes that all functions have been validated already, though. Thus add
explicit validation on that specific path.
R=ahaas@chromium.org
Bug: v8:13361
Change-Id: Iddef130ba791753a818222c2802177a6b326b204
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3999840
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84082}
No need for intra review on this file (as brought up in
https://crrev.com/c/3980257).
R=machenbach@chromium.org
No-Try: true
Change-Id: I21179ebe0e44be0079a664b8f408b31b190be398
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4004744
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84081}
In assertOptimized and assertUnoptimized, we can optionally pass in the
function name. We also used to pass in an optional 'sync' parameter, to
decide whether to wait for background compilations to finish before
checking state.
The sync parameter was removed in favour of explicit intrinsics, so fix
callers of assertOptimized to no longer try to set it. Also, use
function.name as the function name when no name was passed.
Change-Id: I8e98d4d02e2d097d059989ad78bf46b97b57bdca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4000480
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84080}
With this change, ReduceJSCallMathMinMaxWithArrayLike will work on both PACKED_DOUBLE_ELEMENTS and HOLEY_DOUBLE_ELEMETNS kind.
It will also work when the opcode of arguments_list is JSCreateEmptyLiteralArray to deal with following use cases.
var array = [];
array.push(num1); // add elements
array.push(num2);
console.log(Math.min.apply(Math, array));
Change-Id: I39840a17607c31baea2c6b1d33218700f723d760
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4007927
Commit-Queue: Fanchen Kong <fanchen.kong@intel.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84079}
Restructure such that we only either shrink or grow the space, and only
at the end of the GC.
Bug: v8:12612
Change-Id: I7671e139b6023cd04f438f48401cf392d4549b8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3980253
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84076}
