In previous change https://crrev.com/c/2274308 , I attempted to fix an
issue where FindOptimalSpillingPos could sometimes fail to find the
LiveRange that covers the top of the loop. However, I misunderstood how
TopLevelLiveRange::GetChildCovers behaves, so I introduced a different
case where FindOptimalSpillingPos would fail to find the right
LiveRange. This change updates GetChildCovers to do what I had thought
it would do, so it can find the right LiveRange in all cases.
chromium:1102243
Bug: chromium:1101958, chromium:1101954, chromium:1102257,
Change-Id: If91c642c3f7f5e3a8b4cfaa3b3577865c84afcb6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2288660
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#68758}
After native-context-independent codegen, verify that the resulting
Code object does not embed any nc-dependent objects, and that no code
dependencies have been created.
Bug: v8:8888
Change-Id: I894e74b27e86e7727ff17aa0dbfdd908373a5e55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2284498
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68757}
By introducing a globally known map for each generic type.
These maps are never used to allocate objects, they only
serve as sentinels for generic heap types.
Bug: v8:7748
Change-Id: I950a8c712dc1510759a833fe9122b9e9a6222dc2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2288860
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68755}
Since main thread allocation does not start incremental marking anymore
while holding allocation_mutex_, background allocation does not need
ParkedMutexGuard anymore to avoid deadlocks.
This also means background thread allocation isn't paused anymore to
perform a GC, which already resulted in subtle bugs (e.g. in
ExpandBackground with incremental marking). We also do not
stop-the-world anymore while holding allocation_mutex_.
Bug: v8:10315
Change-Id: Iadf00bc26434c765722b82a10497ab06151f15cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2289771
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68754}
The tool is no longer supported since we migrated to Turbofan.
Change-Id: I55b911f47867b2a6985ce14f973cd837f71ec4b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2288859
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68753}
For 64-bit binary operations, Liftoff on arm made the assumption that
register pairs are always ordered, i.e. the register code for the low
word is lower than the register code for the high word.
Ensuring this was only implemented in {GetUnusedRegister} in
https://crrev.com/c/2168875. Other cases were missing though, e.g.
return values, but also different places were we
construct register pairs internally.
Thus, this CL removes this constraint again and instead handles
unordered register pairs in 64-bit binary operations on arm.
R=thibaudm@chromium.org
Bug: chromium:1101304
Change-Id: I4cd9fb1577f82ab06d34c9dde6533cf04a2cade7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2287870
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68752}
This rounds up all SIMD instructions as included in the proposal as of
9f1295a494.
Bug: v8:10180
Change-Id: Icd4cb0aeddede6a611de6f8f3916dc036977c499
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2285789
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68746}
And removed the ifdef guards around instruction-selector and
tests since v128.const is now implemented for x86, x64, arm, arm64.
Bug: v8:8460
Change-Id: I0ed8aede0a07db2fd286bf0c3385eba1079558f8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2285149
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68745}
The second argument of FromParameterIndex should be the parameter count, including the receiver.
Previously it worked by chance, because the code was trying to access the receiver but did not include it in the parameter count, accessing the first argument. This does not work anymore when the arguments are reversed (V8_REVERSE_JSARGS).
Change-Id: I8ca9054a99d074c130f9a9b444e7b8a379840991
Bug: v8:10201
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282531
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68742}
--trace-wasm-decoder should not imply --single-threaded, as
--single-threaded implies --no-liftoff. Hence we cannot trace the
decoder in Liftoff mode.
R=thibaudm@chromium.org
Change-Id: I3e4f0ea119288ef88c4b00dd2f2a11244b77c204
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2287492
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68741}
Instead of having one decoder method per opcode, make all load and store
opcodes use the same method, and load the necessary information from a
static array.
R=thibaudm@chromium.org
Bug: v8:10576
Change-Id: I27daf52b9cb0af6a288a5642913c132e20f0eabd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2287489
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68740}
This CL attempts to hide panels from the user view until
data upload event to help users read instructions more easily.
Screenshots: https://imgur.com/a/qFgIKI8
Bug: v8:10665
Change-Id: Ida666aa850b80cff3f428e1789cc92592ec79a6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2278474
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Cr-Commit-Position: refs/heads/master@{#68738}
Due to an optimization in how resumable functions are compiled, we can
actually see another Oddball type as StrictEquality inputs. I'm giving
up on getting the DCHECK right and removing it entirely.
Bug: chromium:1102683
Change-Id: Ia210777c66641e898e96900713710a51ebed311d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2287494
Auto-Submit: Georg Neis <neis@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68735}
Goal is to include coverage of builtin functions into coverage
bitmap send to Fuzzilli fuzzer. In order to do this, after each
REPRL loop, coverage data of bitmaps are retrieved from JS heap
and stored into coverage bitmap. Additionally, there is an option,
to print out statistics about how many of edges from builtin
functions were turned on by the program inputted into REPRL loop.
This commit introduces two flags:
--no-fuzzilli-enable-builtins-coverage - when enable-builtins-coverage
turned of, builtins coverage will not be exported to fuzzilli
--fuzzilli-coverage-statistics - when turned on, d8 prints
statistics into covlog.txt file after each loop
Change-Id: I8f9cf8dc693b952467b108c6d6bc00134125bc5f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2263154
Commit-Queue: Peter Ralbovsky <ralbovsky@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68733}
Instead of having one method with a big switch, and specializing that
method for each single opcode, we now have one proper method per opcode.
This makes the code way more readable, and also reduces the compile time
of liftoff-compiler.cc significantly.
Unfortunately, we cannot use template specializations for this, since
GCC does not support specializing the methods within an unspecialized
templated class.
Hence, we need to have another dispatch per opcode when generating the
opcode handler table. I left a comment explaining why we do it this way.
The upside of this is that we get nicer method names.
R=thibaudm@chromium.org
Bug: v8:10576
Change-Id: I8c7026177490893711c999217eeb1e4f2fbb5e36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282533
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68732}
Native context independent code generation should, at the moment, not
use any collected feedback.
We implement this by returning InsufficientFeedback from the heap
broker's ReadFeedbackForX methods if currently compiling nci code.
Thus all feedback.IsInsufficient() calls inside the compiler will
return true (disabling feedback-based optimizations).
FeedbackSource::IsValid() (used in generic lowering) can still return
true.
Bug: v8:8888
Change-Id: I198b6457276073e7376c777b206c50726f1b3645
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2284494
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68726}
We used to expose raw WasmGC objects via the JS interface and made
use of that in our cctests. Since those objects would cause crashes
when used in JavaScript, this patch prevents such interactions, and
migrates the tests to use the C-Wasm interface instead.
Bug: v8:7748
Change-Id: I76a10663cda43c940c8c22c57c14922be9b05134
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2284497
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68725}
The unregister_token slot is iterated as a custom weak pointer slot,
which means the heap verifier treats it as a strong slot. Currently,
popped WeakCells (that is, WeakCells for which the owning
FinalizationRegistry's finalizer has already been invoked) neither
clears out the unregister_token slot nor marks it, which trips the heap
verifier.
Bug: chromium:1102161
Change-Id: I0a803f12379fc9df6935bc8331b3d5ecb199571a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2284202
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68723}
In turboprop, we reuse the code on a soft deopt. It will be good to
differentiate between a deopt that reuses the optimized code on the
next run and the deopt that discards the code. The deopt that reuses the
code is called a "bailout" because it is just bails out for one
execution to the unoptimized code.
Change-Id: I9a300201e9b327415e94c2817065d6a561f8ece5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2277807
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68722}
Adds const modifiers to several methods and their parameters in
AllocationStats, BasicMemoryChunk and ReadOnlySpace.
Also moves BasicMemoryChunk::OffsetToAddress to ReadOnlyPage.
Bug: v8:10454
Change-Id: Ibda8f9212d95dff71ed1d8f1f985eb1c7e6087aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2284986
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@{#68721}
This is needed for write-barrier and persistent-handle code that does
not otherwise get an instance of LocalHeap
Bug: v8:10315
Change-Id: I480e31f32141510f2f9e678af3449d5841e3156e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2284492
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68720}
Rather than only removing the continuation range for the last return
statement prior to a synthetic return statement, remove the
continuation tracking for whatever statement occurs prior to the
synthetic return.
Bug: v8:10628
Change-Id: Ieb8e393479c9811cf1b9756840bbfdbe7f44a1b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2280585
Commit-Queue: Benjamin Coe <bencoe@google.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68719}
By default the v8::MeasureMemory API forces GC after some timeout.
There are use cases that require low overhead measurements without
forcing GC at all.
Change-Id: I7d57c552d78d86800c4f37acb680c70c6422477f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2257856
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68718}
- Adds JSVisitor that is used for unified heap marking.
- Adds JSMember as supported reference type that also encapsulates a
write barrier in future. JSMember is a replacement for
TracedReference which can be deprecated with EmbedderHeapTracer once
the library is used to handle unified heap collections.
The dispatch for v8::JSMember on cppgc::Visitor is provided through a
specialization of TraceTrait.
Bug: chromium:1056170
Change-Id: I60d976ae66db3e5fa2e690a21627bdcb8c6871af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2284488
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68716}
When rtt.sub is called repeatedly with the same arguments, it
should return the same result. This CL introduces a cache for
previously created sub-RTTs to achieve that.
Bug: v8:7748
Change-Id: Ie6c74eedf0df6f94cd973fdb0b6b6fc0130a9c41
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2275967
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68715}
This lets us type the last VARIABLE. PrepareValueForWriteToTypedArray
still returns Node* for the non-templated version since it can return
Word32T or Float64T or Float32T or BigInt.
Bug: v8:6949
Change-Id: I90dee90d2e7eff08b1f69a57af371dec399b94c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282595
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68714}
Similar to the feedback vector, we cannot embed the native context as
a constant in NCI code (it is trivially native-context-dependent). In
NCI mode, load it from the current context. In default turbofan, we
keep the HeapConstant.
Bug: v8:8888
Change-Id: Iff95c673b25245c701c7755416abf2038b5fdf08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282532
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68712}
HasProperty and InstanceOf now both have a feedback vector input, and
collect feedback in generic lowering.
CreateClosure loads the feedback cell (in nci mode) instead of embedding
a heap constant.
Bug: v8:8888
Change-Id: Id479cda344684aeb5054f687b087c4fedeac05d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282530
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68711}
Turbofan now has support for generating generic code in two variants,
with and without feedback collection. Currently, feedback is collected
only for some load and store operators (historical reasons).
This CL enables feedback collection for (almost) all operators by
default. The exception in the default TF configuration are call and
construct variants (see also https://crrev.com/c/2276042). In NCI mode,
all operators collect feedback.
Regression have looked acceptable in our benchmarks so far. This is an
experiment to see impact on real world. If successful, the
non-collecting variants can be removed.
Bug: v8:8888
Change-Id: I0dddc7113ce94071552d5c4d992471db5ac5f989
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2239571
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68710}
This CL types almost all remaining VARIABLEs. Only one remains (in
PrepareValueForWriteToTypedArray) since it depends on a variable
MachineRepresentation. Will be done in a follow-up.
Bug: v8:6949
Change-Id: Icdec3d8fdc1459c0b35fc3d1f7e8816981bbccba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282594
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68709}
