CallOrConstructWithArrayLike and CallOrConstructWithSpread builtins
expect only Smi in the array length field. This is true when we
have fast elements kind, but for dictionary mode we can have HeapNumbers
This cl fixes by moving the loading of length fields after the check
on elements kind to avoid loading length fields on dictionary mode
JSArrays.
Change-Id: I838a260353efa25fb0357e6f03247d3075cebe3b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431206
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70133}
When stack slots are spilled after the register moves, some registers
may get overwritten, e.g. by constants.
R=clemensb@chromium.org
Change-Id: Ie94aff0fd63cd9c271b90df34895818594cee3b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429032
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70131}
- Adds a --harmony-atomics feature to gate Atomics. This allows us to
independently add SharedArrayBuffer and Atomics on the global object
of Contexts, which is necessary for migration to a COOP+COEP site
isolation requirement.
Bug: chromium:923807
Change-Id: If80c12eb86dc0251a5e5fad62a6dd5ced3380b5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2340322
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70129}
f32x4->16x8, 64x2->8x16, and 16x8->8x16.
This allows us to pass more spec tests.
Bug: v8:10507
Change-Id: I1810ce2d17f93529b2e69cf5c767cb7b480b4b49
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429807
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70128}
Using the proper `add` operation assures the NAN value
is properly propagated to the result register.
Change-Id: Icb86193f85534604f2a4a583d177a6f319ca38c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429804
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#70127}
PagedSpace::RefillFreeList() needs to invoke wasted_memory()
while holding the lock. Otherwise this races with
PagedSpace::FreeLinearAllocationArea() which uses add_wasted_memory()
and already holds the lock.
Bug: v8:10315
Change-Id: I3a57191529cdd81d75833ec334a57f84a9a59194
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2428930
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70126}
In atomic.notify we overwrote the register which stored the index,
without checking if it was still in use or not.
R=clemensb@chromium.org
Bug: v8:10898
Change-Id: I59ed7a2c1f1342ff4252e3c4d33822111caee82c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2426616
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70125}
When loading from the exported function data without pointer
compression, wrong load was used before.
Bug: v8:10701, chromium:1130385
Change-Id: If66913bcd5284eeb6fb7b795357f1512682a062f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2426383
Commit-Queue: Eva Herencsárová <evih@google.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70124}
On ppc64 and s390x, Liftoff is not implemented yet, so if a Liftoff
compilation unit finishes after all top-tier units (hence after the "top
tier finished" callback), it will still increase the turbofan counter.
R=clemensb@chromium.org, ecmziegler@chromium.org
Bug: chromium:1092417
Change-Id: I0b99061f26851288f1abb8fcc3a30ca92a55164e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429564
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#70123}
This test checks SizeOfObjects after GC, but there might be concurrent
allocations in-between.
Bug: v8:10315
Change-Id: Id904c8865e44ac5c3b486ff6f1316e536cf20e9f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2428864
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70122}
The memory offset is read as a u64 in the memory64 proposal, independent
of the actual type of the memory. The actual memory size of a module (at
runtime) can only be within intptr_t/uintptr_t range though. This
assumption was already used when constructing the TurboFan graph, but
the C++ types did not reflect it yet.
This CL fixes that:
1) Use uint64_t type for bounds checks (only within the method for now,
callers still pass a uint32_t).
2) Use uintptr_t for storing the minimum and maximum possible memory
size at runtime (in CompilationEnv); clamp memory sizes to values
that can actually happen at runtime.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: I6559f9a3abc2aa338eba4618479456f6efb5e772
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2426405
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70121}
Make sure that tests grow the new space in a safepoint. This fixes
races with concurrent allocation.
Bug: v8:10315
Change-Id: I6fce6740bc3c9385f18bbbcde4b06ba881a03635
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2428946
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70120}
When reading the FixedDoubleArray value and representation, we are
reading the same value but bitcasting it diffrently. In this vein, we
can read it only once and ask whether it is the hole or not.
Bug: v8:7790
Change-Id: I0d7b29ce037b9abb55c5a1332c7e6d06887905e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2428587
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70119}
Changes:
- Add dedicated exception for call_ref invoking a WasmJSFunction.
- Small restructuring of read_value_type.
- Change HeapType::kLastSentinel to point to the last valid type,
update is_valid().
- Remove redundant DCHECK from ValueType constructors.
- Rename a few section-related macros in module-decoder-unittest.cc,
add a small test.
- Rename "Simd128" -> "s128" in error message.
- Write some documentation, mostly in value-type.h and wasm-subtyping.h.
Bug: v8:7748
Change-Id: I4fc4826fbdeac50e21ef524787c2024d7aa1b3b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424139
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70118}
Avoid data race by only setting FLAG_local_heaps to true if not
already enabled.
Bug: v8:10315
Change-Id: Ib562b6d525448f5c088da39bf60928debd97db43
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2426610
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70115}
This unifies {max_initial_mem_pages} and {max_maximum_mem_pages} into
{max_mem_pages}.
The {CompilationEnv} constructor was incorrectly using the former
instead of the latter anyway. This did not really matter though, since
they typically have the same value.
Also, there is not a single test that sets --wasm-max-mem-pages-growth.
R=manoskouk@chromium.orgCC=jkummerow@chromium.org
Bug: v8:10949
Change-Id: Ib7ab9b4c239d50b72013087eda5a214829c90369
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2426619
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70114}
Ensure that events are triggered when a module is decoded, compiled,
instantiated and tiered-up.
This is a reland of Ib5883a338c3756c6f3488fbdd7b6861ecc2ba218.
R=clemensb@chromium.orgTBR=adamk@chromium.org
Bug: chromium:1092417
Change-Id: I803ae3db23a5f71f26e8ec118251eccdfc551353
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2425056
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70113}
The actual fix is in LoadIC::ComputeHandler (checking
lookup_start_object == holder instead of receiver == holder) + the
LookupIterator changes for preserving lookup_start_object.
The rest is renaming / refactoring.
Reland: not relying on the prototype validity cell after all
Previous version: https://chromium-review.googlesource.com/c/v8/v8/+/2414039
Bug: v8:9237, chromium:1127653
Change-Id: I1949442f8ddcecb776f0c5d2cf737cb75f80e313
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2428588
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70112}
Use Global instead of Persistent such that GlobalHandle is reset at the
end of the function. Persistent doesn't reset in the destructor,
which means that the GC resets the GlobalHandle. With
--stress-concurrent-allocation this might not happen in the test
function itself but when the cctest framework itself works through
the event queue. At that point the Persistent isn't live anymore.
Bug: v8:10315
Change-Id: If77388ad5acb80538852beca0ab22a4ebaf0b5c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2426612
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70111}
This is a first small step for implementing the memory64 proposal:
1. Add a feature flag.
2. Add the 0x04 and 0x05 limits flag for memory64.
3. Read memory limits as LEB-encoded u64 (instead of u32) if a memory64
limit flag was read.
4. Unify {MaximumFlag} and {MemoryFlag}, which was used inconsistently
before.
5. Add test for memory limits encoded with >5 bytes.
6. Move some macros from module-decoder-unittest.cc to wasm-macro-gen.h.
Note that still the same limits for the maximum number of pages applies
as before, i.e. you cannot specify a memory >4GB yet. But you can encode
that small number in >5 bytes.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: I90a4f08426ae714a67440281785eb00cfc24a349
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423712
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70110}
This fixes a case in which we forgot to assign flags to TextNodes
created through
AddBmpCharacters
AddNonBmpSurrogatePairs
AddLoneLeadSurrogates
AddLoneTrailSurrogates
functions. If these initially had a flag (e.g. case-insensitive 'i')
set, that information was lost. This bug resulted in missing case
folding in no_i18n builds (perhaps other things as well that just
aren't covered by our test suite).
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Bug: v8:10131,v8:10120
Change-Id: Icef4f0dbd47971a538e07bab2f1067c383fd59c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423718
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70106}
Benchmarks showed a large number of useless NCI compilation
tasks, i.e. code objects were generated and cached but never used.
Ideally, we'd only spawn an NCI task when the generated code will
be used in the future. To approximate this behavior, we now delay
task creation to the *second* time a function is optimized; the
thought being that a function that has been optimized twice is likely
to be optimized (= become hot) again in the future.
Bug: v8:8888
Change-Id: Ia37ae6a4c3861a611086964c20c313dda1974f14
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414032
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70103}
Load splat implementation is almost the same, except for the vector
format used for the output register. We encode this information in
MiscField (the size of each lane), and with some helper functions we can
easily reuse a single opcode for 4 load splats.
Bug: v8:10930
Change-Id: Ieed4dc7358821a0d1d7bab4add7a59d808c5aad8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2422354
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70098}
Add lowering for F64x2 in S128Const and converting to and from f64x2.
Bug: v8:10507
Change-Id: Ic2c4f1f41d3dd804e012a943391a46b534864b51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424679
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70097}
For now, V128 values are converted to String16 (since they are not
serializable). It is shown as a list of 16 uint8_t (hex). This
description can be tweaked as necessary.
Some updates to ARM64 required to push/pop the full Q register.
Bug: v8:10347
Bug: chromium:1130474
Change-Id: I1bffbb49f47c06da3cd26d830addae0416a4441a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2422082
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70096}
This CL fixes two things:
1) It properly creates code entries for the generic js-to-wasm builtin
(others are left out because we don't want to include all builtins in
profiles).
2) It includes js-to-wasm frames in profiles. The generic js-to-wasm
builtin will map to that frame type in the future (see referenced
bug). js-to-wasm frames are currently included because they are wrongly
mapped to OPTIMIZED frames by the SafeStackTraceIterator.
R=petermarshall@chromium.orgCC=ahaas@chromium.org, evih@google.com
Bug: v8:10701
Change-Id: I26e3fa6901890e041feab7c001069e67a616c986
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416495
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70095}
- Make Module::RecordErrorUsingPendingException and
Module::RecordError static (There is no need for them to be
"fast" instance methods with raw pointers)
- Share various debug print snippets
- Share status change code in SetStatusInternal
- Simplify several casts
Change-Id: I159dc3dd9104bf76858a2d5ad142a72a75640716
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416490
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70094}
Avoid --log-all which activates profiling timers that have issues on
certain bots. --log-code is good enough to test whether logging works.
Bug: v8:10937
Change-Id: I3284801f7b423480756abb0f3c33980a9776575d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424349
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70093}
Currently, the generic wrapper is used for i32 and i64 params and 0 or 1
i32, i64, f32, f64 return value.
Bug: v8:10701
Change-Id: I610172995457354879afd3c9c2c6c2d55c2b700f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414219
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Eva Herencsárová <evih@google.com>
Cr-Commit-Position: refs/heads/master@{#70090}
We currently have a pattern of setting a dereferenced Handle location to
update that Handle's value:
*handle.location() = new_value.ptr()
This is slightly opaque, and definitely not type-safe, so add a new
Handle<T>::PatchValue method which does this operation.
Ideally we would make Handle::location() return a const pointer to
discourage this sort of use, but there's a bunch of places where that
location pointer is used and passed around as a Handle surrogate, so
those would have to be updated first.
Change-Id: I157f7e2473ed1b86f7a93cae260b0932fed0ad88
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424249
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70088}
Currently the kWasmInstanceOffset is computed according to the reg
a0(kWasmInstanceRegister)'s position in the frame. And according
to Builtins::Generate_WasmCompileLazy, it's the 7th gp_regs that
are pushed on to stack, so the index should be 6 other than 7.
Since the kWasmInstanceRegister will be pushed on to stack after
all parameter registers, so we can use it's index, which does not
reply on which reg kWasmInstanceRegister is, and what order the
parameter registers are pushed on to stack.
So the new index is equal to the number of all parameter registers.
Change-Id: I7a77fb052a5d68ee28dab10409462260ad491578
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2425329
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70087}
For invalid modules, the {kFinishedExportWrappers} event and the
validation error can happen in any order. Make the order deterministic
for predictable mode.
R=clemensb@chromium.org
Bug: v8:10936
Change-Id: Ib5b1e5a1a3af901a81bc37919b5aff4e5c237579
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424134
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70086}
Not needed for correctness but this avoids adding the pending object
to the on_hold worklist.
Bug: v8:10315
Change-Id: Ide910cee37a4069c71c4046c32fa9f663265775e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424137
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70085}
