f64x2min/max need to canonicalize the output only if both
inputs are also canonicalized, otherwise any arithmetic NaN
(from either lane) can be placed into the result register.
We also need to make sure the output value is a QNAN.
Change-Id: I363f88528674014cd92828d429a61442406025b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2573484
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#71614}
This makes sure that the code tested by fuzzers is the same as running
on native hardware.
R=ahaas@chromium.org
Bug: v8:11041
Change-Id: I1005b2de3a22d88a6bdf164338633bbb7991bc1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2573481
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71613}
Port String::Flatten to Torque (using a fast C call for the
non-allocating part) and provide fast and easy access to sequential
string data in Torque: GetStringData() flattens if necessary and
computes slices that allow direct access.
Applications: String.prototype.replaceAll, String.prototype.endsWith,
and String.prototype.beginsWith now use GetStringData() and direct
slice access instead of the slow StringCharCodeAt and they no
longer bail out to the runtime for flattening.
Drive-by changes:
- Expose String instance type bits as bitfields and enums in Torque.
- Fix method lookup in Torque to include superclass methods.
- Use char8 and char16 types in more places.
- Allow fast C calls with void return type.
- Add Torque macros to create subslices.
- Add no-GC scopes to runtime functions loading external string data.
Bug: v8:7793
Change-Id: I763b9b24212770307c9b2fe9f070f21f65d68d58
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565515
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71611}
This reverts commit b614cd78c3.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64/40448/overview
Original change's description:
> Reland "Reland "[heap] Add epoch to GC tracing events""
>
> This is a reland of 3238162da7
>
> No changes since the last reland.
>
> Original change's description:
> > Reland "[heap] Add epoch to GC tracing events"
> >
> > This is a reland of be52501d52
> >
> > Fix data race by not emitting the epoch for sweeper background jobs
> > at them moment.
> >
> > Original change's description:
> > > [heap] Add epoch to GC tracing events
> > >
> > > This CL adds the TRACE_GC_EPOCH macro, which adds the epoch as attribute
> > > to the trace event. Use TRACE_GC_EPOCH for top-level events, nested
> > > events can get the information from its parent.
> > >
> > > V8's GC needs an epoch for young and full collections, since scavenges
> > > also occur during incremental marking. The epoch is also process-wide,
> > > so different isolates do not reuse the same id.
> > >
> > > Change-Id: I8889bccce51e008374b4796445a50062bd87a45d
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565247
> > > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#71521}
> >
> > Change-Id: Ib8f4bfdc01c459955eb6db63bb6e24a8aa068f09
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567702
> > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#71567}
>
> TBR=ulan@chromium.org,dinfuehr@chromium.org
>
> Change-Id: I09dcfabbad4ef1ad50e02a227282982cd7d87997
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571122
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71609}
TBR=ulan@chromium.org,dinfuehr@chromium.org
Change-Id: I9dfd37f969ec0c5e5f278e6a82732995fd82e5d9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2574002
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71610}
This is a reland of 3238162da7
No changes since the last reland.
Original change's description:
> Reland "[heap] Add epoch to GC tracing events"
>
> This is a reland of be52501d52
>
> Fix data race by not emitting the epoch for sweeper background jobs
> at them moment.
>
> Original change's description:
> > [heap] Add epoch to GC tracing events
> >
> > This CL adds the TRACE_GC_EPOCH macro, which adds the epoch as attribute
> > to the trace event. Use TRACE_GC_EPOCH for top-level events, nested
> > events can get the information from its parent.
> >
> > V8's GC needs an epoch for young and full collections, since scavenges
> > also occur during incremental marking. The epoch is also process-wide,
> > so different isolates do not reuse the same id.
> >
> > Change-Id: I8889bccce51e008374b4796445a50062bd87a45d
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565247
> > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#71521}
>
> Change-Id: Ib8f4bfdc01c459955eb6db63bb6e24a8aa068f09
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567702
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71567}
TBR=ulan@chromium.org,dinfuehr@chromium.org
Change-Id: I09dcfabbad4ef1ad50e02a227282982cd7d87997
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571122
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71609}
Rolling v8/build: cb1a537..acf4f5e
Rolling v8/third_party/aemu-linux-x64: h_lfZjWg21ZL3JBJXSabJsKCnyhbzTyNAISwoJCfLCAC..Ld6Ho8txe7fnUwYDIgKsMmU0e2gBZ9Zx1n43O83aofUC
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/5537c03..d1cf5db
Rolling v8/third_party/depot_tools: 4640dfb..b2c18f2
Rolling v8/third_party/fuchsia-sdk: f8df9ff..efa4658
Rolling v8/tools/clang: 8636efe..9ec0bb3TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com
Change-Id: I4244d6d44df9c205b5c33c570100f46826bc4560
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2573012
Reviewed-by: 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/master@{#71608}
This reverts commit 716dae3ae0.
Reason for revert: broke noavx build https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20debug/33124/overview
Original change's description:
> [wasm-simd][ia32] Prototype sign select
>
> The implementation is the same as on x64.
>
> Bug: v8:10983
> Change-Id: I2654ce4a627ca5cc6c759051ab9034c528d9f25a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567194
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71606}
TBR=bbudge@chromium.org,zhin@chromium.org
Change-Id: I6408268945e41ef7acf5938ac989bab9824df185
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10983
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2573996
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71607}
The implementation is the same as on x64.
Bug: v8:10983
Change-Id: I2654ce4a627ca5cc6c759051ab9034c528d9f25a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567194
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71606}
Some extract lane and replace lane opcodes overlap with the ones used
for load lane, with a different addressing mode. Merge those cases
together and delete unused opcodes.
Drive by clean-up to rename kF32x4ReplaceLane to kIA32Insertps to follow
the naming convetion (kIA32 prefix) and also make it more general if in
the future we use insertps for other purposes.
Bug: v8:10975
Change-Id: Id143670f63e69cb45cf7c1ce358297a928383035
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2568924
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71605}
brc or brcl may be emitted depending on the offset length.
The emitted instr size may be 4 or 6 bytes.
Change-Id: I542ae6a60378ee33e48e08d4f1cdeda4c4c70bb1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2572497
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#71603}
First step towards the new exception handling proposal:
https://github.com/WebAssembly/exception-handling/issues/125
This is essentially a revert of:
"[wasm] Switch to new 'catch' and 'br_on_exn' proposal."
The changes are:
- "catch" instruction takes a tag immediate,
- "rethrow" instruction takes a label immediate,
- Add "catch_all" instruction,
- Remove "br_on_exn" instruction,
- Do not push exceptions on the stack, only the encoded values
R=clemensb@chromium.org
CC=aheejin@chromium.org
Bug: v8:8091
Change-Id: Iea4d8d5a5d3ad50693f645e93c13e8de117aa884
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484514
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71602}
TurboFan creates DisallowHeapAccess scopes, to prevent heap access in
the concurrent parts of the compiler. Then, for parts of the compiler
that do want to access the heap, it either creates Allow* scopes (which
should be avoided since they "punch a hole" in the Disallow* scopes), or
relies on a weakening of Handle::IsDereferenceAllowed which allows
handles owned by a LocalHeap to be dereferenced even if there is a
DisallowHeapDereference scope.
This patch:
a) Strengthens the implicit requirements around handle dereferencing
to require a running heap on this thread (either main-thread heap
or an un-parked, un-safepointed LocalHeap).
b) Removes the overly strict Disallow scopes in TurboFan, relying
instead on implicit requirements for allocation/handle
dereferencing in off-thread code.
c) Cleans up the "should_disallow_heap_access" predicate to be more
explicit about what should be disallowed (e.g. property accesses
can't be computed concurrently)
Change-Id: Icb56b7764913ac17e2db197a70bb189af88a6978
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2554617
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71600}
I'd implemented Module::GetModuleRequests() such that it can only be
called on a SourceTextModuleRecord, forgetting that one of the APIs
it replaces, Module::GetModuleRequestsLength(), could be called on a
synthetic module. The old behavior allowed embedders to write code that
iterates over a module's requests without needing to handle synthetic
modules as a special case. GetModuleRequestsLength() would just return
0 for all synthetic modules and the code to process the requests
would be skipped seamlessly for them.
With the new GetModuleRequests() API, this would no longer be possible,
and embedders would explicitly need to check IsSyntheticModule()
before calling it. Thus, to reach parity with the old API, this change
allows embedders to call GetModuleRequests() on a synthetic module,
which will always result in an empty FixedArray.
Bug: v8:10958
Change-Id: I6024261fe46d18fa7acc83b0ec8f69d6af21b28d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2570146
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#71599}
These tests are pretty slow with both TSAN and
--stress-incremental-marking enabled.
* Skip octane/raytrace for the variant stress when TSAN is enabled.
* Test wasm/shared-memory-worker-stress is slow with TSAN.
Change-Id: Ia4b8ce2986d04e6ef2fc7d28991cd5ce7faf31e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571129
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71598}
AnalyzeLoopAssignment did not take into account that 'let' shifts local
indexes.
Drive-by: Use gTest infrastructure in AnalyzeLoopAssignment tests
(EXPECT_*) instead of CHECKs.
Bug: v8:9495
Change-Id: Ic0ddb5edfde48acf172f4cac9bdcd0312b6121a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567955
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71595}
This is a reland of 2afb00c0e8
Original change's description:
> [heap] Remove SWEEPING phase in incremental marking
>
> The SWEEPING phase in incremental marking was used to finish sweeping
> of the last GC cycle concurrently before starting incremental marking.
> This avoids potentially long pauses when starting incremental marking.
> However this shouldn't be necessary in most cases where sweeping is
> already finished when starting the next cycle. The implementation also
> didn't cleanly separate the GC cycles.
>
> In case the sweeping phase is necessary for pause times, we can
> introduce a "CompleteSweep" phase which runs right before starting
> incremental marking.
>
> Change-Id: Iaff8c06d5691e584894f57941f181d0424051eec
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567707
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71555}
Change-Id: I173bdeaf342d4c0590453f7d9eeb8ab5cfddc73c
Bug: v8:11220, v8:11221
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571111
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71592}
Safepoint maps record all spill slots that contain a tagged value. The
introduction of multi-value return changed the stack frame layout though
and the calculation of spill slots has not been adjusted accordingly.
This CL adjusts the creation of safepoints now to work for multi-value
returns as well.
R=neis@chromium.org
Bug: v8:11206
Change-Id: Id623dbc28b976dcf625ac78738e03e642fafbb36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569762
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71591}
Also construct the `JSMap`s used to store these names lazily and
only on-demand, and construct them directly instead of first doing
a `std::vector<Handle<String>>` and using that to construct the
`JSMap`. The latter resulted in a gigantic root set of 150k+ handles,
which wasn't well received by the GC.
Bug: chromium:1154154
Fixed: chromium:1154564
Also-By: bmeurer@chromium.org
Change-Id: I92e8931f15eda133e2a62b5cc53fbe1f2dafcead
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2568275
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71589}
EncodeNeonUnaryOp and EncodeNeonSizedOp are essentially the same, they
are both helpers to encode instructions in the encoding group "Advanced
SIMD two registers misc". Consolidate them into a single helper.
Bug: v8:11074
Change-Id: I8b0c21bfbce51de72b41cbd3d34cf4fed9ce8819
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567535
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71587}
This is a reland of e2aa734aef
The original change was speculatively reverted in
https://crrev.com/c/2568925 but seems unrelated to the flakey
test failures (which are on x64).
Original change's description:
> [wasm-simd][arm] Prototype i8x16.popcnt
>
> Bug: v8:11002
> Change-Id: Ib97e51ed52249a1af7a4b879396b70a016991719
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567534
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71552}
Bug: v8:11002
Change-Id: I714918e2640d27d29953f940e3bedeb9ea2f8a08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567243
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71585}
It doesn't seem to be a problem at all, I think we already have SSE4_1
scope enabled somewhere.
Change-Id: I501166a4e45214832e85df8a2594dabe6976bfd3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567191
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71584}
br_on_null should push a value on the stack, even in unreachable code.
Bug: v8:9495
Change-Id: Ic227c2f889b863a267a7ff5f33e539b43e66b42f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567966
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71582}
These instructions have the same implementation in code-generator.
Bug: v8:11217
Change-Id: I06fa7eaf6360aa8f142ee1d0b36832be3a518b7b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2568920
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71581}
Movddup can take a memory operand, so we can save a move from gp reg to
xmm reg in that case. No problem with unaligned memory since we are
loading 64 bits (not 128 bits).
Also drive-by comment on i32x4.splat, it uses pshufd, which can also take
a memory operand (saving a mov), but we need aligned memory for that
first.
Bug: v8:9198
Change-Id: I55969888db1debb6ed4d193f767589d0da598386
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567538
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71580}
Cleanup Memcpy and use get/set_simd_register_by_lane
Change-Id: Icbdd838e075d93d75064bd8e47eb95c02f1da9d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2568589
Commit-Queue: Junliang Yan <junyan@redhat.com>
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#71577}
Due to the lane numbering difference between Intel and IBM machines,
we need to switch the input registers when doing a vector pack.
Change-Id: Id01d6292cb2a65b78dccdf3bab1d5ff010e1d018
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569996
Reviewed-by: Junliang Yan <junyan@redhat.com>
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#71575}
Concurrently accessing internal external uncached strings is not
thread-safe. We are removing a case where we can make such a string
through MakeExternal.
Bug: v8:7790
Change-Id: I958062c15cf40ccc330600bb572de98620866e54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565511
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71573}
read_heap_type did not have knowledge of the module for which the heap
type was being decoded. As a result, callers of read_heap_type (or
read_value_type, which in turn calls read_heap_type) had to check after
the fact that a decoded indexed type (ref, ref null, or rtt) references
a type index within the module's bounds. This was not done consistently,
and was missing (at least) in DecodeLocals.
To avoid such problems in the future, this CL refactors read_heap_type
to accept a module and check the decoded index against it.
Changes:
- Add WasmModule argument to read_heap_type. Do so accordingly to all
its transitive callers (read_value_type, immediate arguments,
DecodeLocalDecls, DecodeValue/HeapType in unittests).
- Add index check to read_heap_type and emit an error for an
out-of-bounds index.
- Remove all other now-redundant index validations. Replace them with
decoder->ok() if needed (since read_heap_type will now emit an error).
- Fix error message in Validate for BlockTypeImmediate.
- In DecodeLocalDecls in unittests, pass an empty module to
DecodeLocalDecls in the main code.
- Add a unit test with an invalid index in local type declarations.
Bug: v8:9495
Change-Id: I4ed1204847db80f78b6ae85fa40d300cd2456295
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569757
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71572}
Port b6643320b9
Original Commit Message:
In order to reduce the codegen size of dynamic map checks, add the
ability to have an eager with resume deopt point, which can call
a given builitin to perform a more detailed check than can be done
in codegen, and then either deoptimizes itself (as if the calling
code had performed an eager deopt) or resumes execution in the
calling code after the check.
In addition, support for adding extra arguments to a
deoptimization continuation is added to enable us to pass the
necessary arguments to the DynamicMapChecks builtin.
Finally, a trampoline is added to the DynamicMapChecks which saves
the registers that might be clobbered by that builtin, to avoid
having to save them in the generated code. This trampoline also
performs the deoptimization based on the result of the
DynamicMapChecks builtin.
In order to ensure both the trampoline and DynamicMapChecks
builtin have the same call interface, and to limit the number
of registers that need saving in the trampoline, the
DynamicMapChecks builtin is moved to be a CSA builtin with a
custom CallInterfaceDescriptor, that calls an exported Torque
macro that implements the actual functionality.
All told, this changes the codegen for a monomorphic dynamic
map check from:
movl rbx,<expected_map>
cmpl [<object>-0x1],rbx
jnz <deferred_call>
resume_point:
...
deferred_call:
<spill registers>
movl rax,<slot>
movq rbx,<object>
movq rcx,<handler>
movq r10,<DynamicMapChecks>
call r10
cmpq rax,0x0
jz <restore_regs>
cmpq rax,0x1
jz <deopt_point_1>
cmpq rax,0x2
jz <deopt_point_2>
int3l
restore_regs:
<restore_regs>
jmp <resume_point>
...
deopt_point_1:
call Deoptimization_Eager
deopt_point_2:
call Deoptimization_Bailout
movl rcx,<expected_map>
movq rdx,<handler>
cmpl [<object>-0x1],rcx
jnz <deopt_point>
resume_point:
...
deopt_point:
call DynamicMapChecksTrampoline
jmp <resume_point>
R=rmcilroy@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=v8:10582
LOG=N
Change-Id: I0739c1b40ed06bb22b73ebe1833ea648b540882a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569359
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#71571}
This reverts commit 2afb00c0e8.
Reason for revert: Some tests started to timeout.
Original change's description:
> [heap] Remove SWEEPING phase in incremental marking
>
> The SWEEPING phase in incremental marking was used to finish sweeping
> of the last GC cycle concurrently before starting incremental marking.
> This avoids potentially long pauses when starting incremental marking.
> However this shouldn't be necessary in most cases where sweeping is
> already finished when starting the next cycle. The implementation also
> didn't cleanly separate the GC cycles.
>
> In case the sweeping phase is necessary for pause times, we can
> introduce a "CompleteSweep" phase which runs right before starting
> incremental marking.
>
> Change-Id: Iaff8c06d5691e584894f57941f181d0424051eec
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567707
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71555}
TBR=ulan@chromium.org,dinfuehr@chromium.org
Change-Id: I9adea60c21ff7cdfa7bbac3e6a4a240640fa5ea9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569766
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71570}
This reverts commit 3238162da7.
Reason for revert: Speculative revert for https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64/40411/overview, causing SEGV_ACCERR on test/mjsunit/harmony/promise-any-overflow-2.js and other failures in minor_mc variant
Original change's description:
> Reland "[heap] Add epoch to GC tracing events"
>
> This is a reland of be52501d52
>
> Fix data race by not emitting the epoch for sweeper background jobs
> at them moment.
>
> Original change's description:
> > [heap] Add epoch to GC tracing events
> >
> > This CL adds the TRACE_GC_EPOCH macro, which adds the epoch as attribute
> > to the trace event. Use TRACE_GC_EPOCH for top-level events, nested
> > events can get the information from its parent.
> >
> > V8's GC needs an epoch for young and full collections, since scavenges
> > also occur during incremental marking. The epoch is also process-wide,
> > so different isolates do not reuse the same id.
> >
> > Change-Id: I8889bccce51e008374b4796445a50062bd87a45d
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565247
> > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#71521}
>
> Change-Id: Ib8f4bfdc01c459955eb6db63bb6e24a8aa068f09
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567702
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71567}
TBR=ulan@chromium.org,dinfuehr@chromium.org
Change-Id: I29a131f798c3536d16e4b4c44c0fcb8b35dd0051
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569764
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71569}
This is a reland of be52501d52
Fix data race by not emitting the epoch for sweeper background jobs
at them moment.
Original change's description:
> [heap] Add epoch to GC tracing events
>
> This CL adds the TRACE_GC_EPOCH macro, which adds the epoch as attribute
> to the trace event. Use TRACE_GC_EPOCH for top-level events, nested
> events can get the information from its parent.
>
> V8's GC needs an epoch for young and full collections, since scavenges
> also occur during incremental marking. The epoch is also process-wide,
> so different isolates do not reuse the same id.
>
> Change-Id: I8889bccce51e008374b4796445a50062bd87a45d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565247
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71521}
Change-Id: Ib8f4bfdc01c459955eb6db63bb6e24a8aa068f09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567702
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71567}
If DecodeLocals exits early, num_locals_ is left in an inconsistent
state. This CL fixes this issue by updating num_locals_ as the
local_types_ are updated.
Bug: chromium:1154439
Change-Id: I02328a050df8b2827a42f59443e994f535d3c826
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567954
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71566}
