Bug: chromium:1170261
Change-Id: Id2c5d18df892ece2823f7784dee4e69e54b7454c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2652491
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72368}
The bot is pretty red, so skip the test until we have a fix.
TBR=zhin@chromium.org
Bug: v8:11357
Change-Id: I38bad23ba66518f95de0f13017a6b408623a519d
No-Try: true
No-Tree-Checks: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2652493
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72363}
The API allows for querying
- IsAllocationAllowed: Certain GC phases prohibit allocation which can
be queried; Should be mostly used for debugging checks.
- IsMarking: Allows for querying whether the garbage collector is
currently marking.
Bug: chromium:1056170
Change-Id: I20ba5fb5be9de6694e8418fa885920eb04bd75ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649257
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72359}
According to the new wasm-gc spec, ref.cast should forward a null input
without trapping.
Bug: v8:7748
Change-Id: Ifee17f02a572e7028c14482bc94f0e1c7fc82a5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2647261
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72358}
This reverts commit 0938188f85.
Reason for revert: new test times out on tsan: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN/35152/overview
Original change's description:
> [wasm][debug] Garbage-collect stepping code
>
> All wasm code has an initial ref count of 1, in the expectation that it
> will be added to the code table. When the code is removed from that
> table, the ref count will be decremented.
> Stepping code (and also other code under special circumstances) will not
> be added to the code table though. Hence the ref count will never be
> decremented below 1, and the code will never be garbage-collected.
>
> This CL fixes this, by decrementing the ref count if the code is not
> added to the code table.
> Note that the code will only be collected if no isolate is currently
> using it, so it won't be collected while still in use for stepping.
>
> R=thibaudm@chromium.org
>
> Bug: chromium:1168564
> Change-Id: I3047753591cbc52689ca019e9548ec58c237b835
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649040
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72354}
TBR=clemensb@chromium.org,thibaudm@chromium.org
Change-Id: I84f84324d2c4a3cae2ae6b97f469e3f22b0e3b3f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1168564
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2652485
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72357}
This is a reland of b77deeca4b
Changes compared to original: Add explicit narrowing casts in tests
for MSVC.
Original change's description:
> [wasm-gc] Remove abstract rtts
>
> In the latest wasm-gc spec, rtts of abstract types are no longer
> allowed. Consequently, canonical rtts of concrete types always have
> a depth of 0.
>
> Changes:
> - Change the immediate argument of rtts to a type index over a heap
> type. Abstract it with TypeIndexImmediate in function body decoding.
> This affects:
> value_type.h, read_value_type(), decoding of relevant opcodes,
> wasm subtyping, WasmInitExpr, consume_init_expr(), and
> wasm-module-builder.cc.
> - In function-body-decoder-impl.h, update rtt.canon to always produce
> an rtt of depth 0.
> - Pass a unit32_t type index over a HeapType to all rtt-related
> utilities.
> - Remove infrastructure for abstract-type rtts from the wasm compilers,
> setup-heap-internal.cc, roots.h, and module-instantiate.cc.
> - Remove ObjectReferenceKnowledge::rtt_is_i31. Remove related branches
> from ref.test, ref.cast and br_on_cast implementations in the wasm
> compilers.
> - Remove unused 'parent' field from WasmTypeInfo.
> - Make the parent argument optional in NewWasmTypeInfo, CreateStructMap,
> and CreateArrayMap.
> - Use more convenient arguments in IsHeapSubtypeOf.
> - Update tests.
>
> Bug: v8:7748
> Change-Id: Ib45efe0741e6558c9b291fc8b4a75ae303146bdc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642248
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72321}
Bug: v8:7748
Change-Id: I22b204b486fd185077cd6c7f15d492f5143f48fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2650207
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72355}
All wasm code has an initial ref count of 1, in the expectation that it
will be added to the code table. When the code is removed from that
table, the ref count will be decremented.
Stepping code (and also other code under special circumstances) will not
be added to the code table though. Hence the ref count will never be
decremented below 1, and the code will never be garbage-collected.
This CL fixes this, by decrementing the ref count if the code is not
added to the code table.
Note that the code will only be collected if no isolate is currently
using it, so it won't be collected while still in use for stepping.
R=thibaudm@chromium.org
Bug: chromium:1168564
Change-Id: I3047753591cbc52689ca019e9548ec58c237b835
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649040
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72354}
Listen to code deletion events by registering finalizers on code
objects, a first stab at non-leaky long-lived code entries.
Bug: v8:11054
Change-Id: Ieaaa5b63508263bd261e8385f5bf5dd3baedf9c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2628587
Commit-Queue: Andrew Comminos <acomminos@fb.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72342}
Multi byte values get stored on native host order when
arrays are being constructed, however as Wasm is LE enforced,
they get reversed on BE machines during simd load. This causes
incorrect values loaded into vector registers.
This CL will force mask elements to be saved in byte sizes
to eliminate endianness issues.
Change-Id: I7f2e5017664234e01fc8b51a95cdd852a418b651
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2645586
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72340}
movups is slower on older hardware (core2) than movaps, even if the
operand is aligned. (Not an issue on modern hardware).
Also move i8x16.splat(0x0F) to an external reference so we can load the
mask directly.
Bug: v8:11002
Change-Id: I0b01c27a142024d50b9faaa9e7bd6a1fe169e141
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2643242
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72336}
(Initially copied from nicohartmann@ CL
https://chromium-review.googlesource.com/c/v8/v8/+/2135631)
This CL adds a new intrinsic %ObserveNode(expr) which has noop semantics
but triggers the new NodeObserver set on the OptimizedCompilationInfo
when the node generated for expr is created or changed in any phase
(until EffectControlLinearization).
This provides the infrastructure to write reasonable unit tests that
check for the construction of or lowering to specific nodes (e.g.
depending on feedback).
When %ObserveNode(expr) is used an object of class ObserveNodeManager is
registered to every Reducer/GraphReducer and is notified by the Reducer
with all node changes. The same logic is added to classes
SimplifiedLowering/RepresentationSelector, which do not inherit from
class Reducer.
Observed Node modifications currently are:
* The Node Operator
* The Node type
* Node replacements
A first use case (cctest/test-sloppy-equality.cc) is included in this CL.
Change-Id: Idc5a5e38af8b1d9a2ec5021bf821c4e4e1406220
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2555219
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72331}
This is a reland of 5a0938e593
The fix is in instruction-selector-x64.cc, the OpParameter is a
uint8_t, I typo-ed a int8_t.
Drive-by fix to maro-assembler-x64.cc to use movaps instead of movapd.
Original change's description:
> [wasm-simd][x64] Prototype i32x4.widen_i8x16_{s,u}
>
> This prototypes i32x4.widen_i8x16_s and i32x4.widen_i8x16_u for x64. It
> uses some masks and pshufb for the widening. These masks (3 for each
> instruction) are stored as external references.
>
> Bug: v8:11297
> Change-Id: I6c8f55426bbb44b16ed552f393762c34c2524b55
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617389
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72301}
Bug: v8:11297
Change-Id: Ie1df32bd4ef3c71532cab6f82a515f619b6a2b67
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2648967
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72330}
Recompilation for tier down should not be triggered if the module had a
compile error. This CL ensures that by moving the recompilation a bit
later in the async compilation, to a place where a compile error would
have been detected already. An added DCHECK would catch similar bugs
earlier (crashing instead of timing out).
R=ahaas@chromium.org
Bug: chromium:1160031
Change-Id: I7eb3d2921db0f28bb39e9ec6150fd98fd4b99089
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649028
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72329}
Writing out the number of functions in the module is unnecessary. That
number is only used for validation when reading back the value, but only
validating that number is pretty arbitrary and does not protect against
bugs or attacks. Hence skip these two header fields.
R=thibaudm@chromium.org
Bug: v8:11164
Change-Id: I083075e2c8959f99690fd1478d0950a25eb7311f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2644946
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72326}
The GC requires all slots in a stack frame that store a reference to be
aligned. This alignment was not provided for spill slots in OOL code.
R=thibaudm@chromium.org
Change-Id: I17492362318623aecc4c54635407d0c8badf3d36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649025
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72324}
This reverts commit b77deeca4b.
Reason for revert: MSVC compile fails: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64%20-%20msvc/16535/overview
Original change's description:
> [wasm-gc] Remove abstract rtts
>
> In the latest wasm-gc spec, rtts of abstract types are no longer
> allowed. Consequently, canonical rtts of concrete types always have
> a depth of 0.
>
> Changes:
> - Change the immediate argument of rtts to a type index over a heap
> type. Abstract it with TypeIndexImmediate in function body decoding.
> This affects:
> value_type.h, read_value_type(), decoding of relevant opcodes,
> wasm subtyping, WasmInitExpr, consume_init_expr(), and
> wasm-module-builder.cc.
> - In function-body-decoder-impl.h, update rtt.canon to always produce
> an rtt of depth 0.
> - Pass a unit32_t type index over a HeapType to all rtt-related
> utilities.
> - Remove infrastructure for abstract-type rtts from the wasm compilers,
> setup-heap-internal.cc, roots.h, and module-instantiate.cc.
> - Remove ObjectReferenceKnowledge::rtt_is_i31. Remove related branches
> from ref.test, ref.cast and br_on_cast implementations in the wasm
> compilers.
> - Remove unused 'parent' field from WasmTypeInfo.
> - Make the parent argument optional in NewWasmTypeInfo, CreateStructMap,
> and CreateArrayMap.
> - Use more convenient arguments in IsHeapSubtypeOf.
> - Update tests.
>
> Bug: v8:7748
> Change-Id: Ib45efe0741e6558c9b291fc8b4a75ae303146bdc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642248
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72321}
TBR=ulan@chromium.org,jkummerow@chromium.org,manoskouk@chromium.org
Change-Id: I2f0d97f1a34f7c81c5a97d7c37925cb84c66eea3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7748
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2650206
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72322}
In the latest wasm-gc spec, rtts of abstract types are no longer
allowed. Consequently, canonical rtts of concrete types always have
a depth of 0.
Changes:
- Change the immediate argument of rtts to a type index over a heap
type. Abstract it with TypeIndexImmediate in function body decoding.
This affects:
value_type.h, read_value_type(), decoding of relevant opcodes,
wasm subtyping, WasmInitExpr, consume_init_expr(), and
wasm-module-builder.cc.
- In function-body-decoder-impl.h, update rtt.canon to always produce
an rtt of depth 0.
- Pass a unit32_t type index over a HeapType to all rtt-related
utilities.
- Remove infrastructure for abstract-type rtts from the wasm compilers,
setup-heap-internal.cc, roots.h, and module-instantiate.cc.
- Remove ObjectReferenceKnowledge::rtt_is_i31. Remove related branches
from ref.test, ref.cast and br_on_cast implementations in the wasm
compilers.
- Remove unused 'parent' field from WasmTypeInfo.
- Make the parent argument optional in NewWasmTypeInfo, CreateStructMap,
and CreateArrayMap.
- Use more convenient arguments in IsHeapSubtypeOf.
- Update tests.
Bug: v8:7748
Change-Id: Ib45efe0741e6558c9b291fc8b4a75ae303146bdc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642248
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72321}
This reverts commit ec7e9a8dbc.
Reason for revert: failure was due to a clang bug that is fixed in
latest rolled clang.
Original change's description:
> [test] Disable cctest/test-loop-analysis/LaEdgeMatrix2_0 on ODROID
>
> Bug: chromium:1163847
> Change-Id: Iabb152cd1a5c04e2032cb1254d8b27ea081cbb27
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614427
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71952}
TBR=machenbach@chromium.org,leszeks@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1163847
Change-Id: Iba18918e8ceab166e7d5e9751e857f13142ed583
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2647153
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72310}
This change completes support for import assertions for dynamic import().
A new version of the HostImportModuleDynamically callback taking import
assertions is added to the public API. The name is very verbose; we
could consider removing the "ImportAssertions" part when the old API
is removed.
Bytecode generation is updated to pass the assertions, if present, to
Runtime_DynamicImportCall.
Isolate::RunHostImportModuleDynamicallyCallback extracts the assertions
from the options bag, filters out the assertions not present in the
list specified by the host in HostGetSupportedImportAssertions, and
sorts them by code point order of the keys per
https://tc39.es/proposal-import-assertions/#sec-import-call-runtime-semantics-evaluation.
The resulting array is passed to the host in the callback.
Bug: v8:10958
Change-Id: I931df00f954a9f9c65bff5bcf461ba1c8f11e94e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2620578
Commit-Queue: Dan Clark <daniec@microsoft.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72307}
This CL implements the upcoming spec change:
https://github.com/tc39/proposal-regexp-match-indices/pull/49
A new JSRegExpResultWithIndices subclass is introduced with a separate map and
an extra slot for storing the indices. If /d is passed, exec() constructs a
JSRegExpResultWithIndices and eagerly builds indices.
The existing re-execution logic is removed.
Bug: v8:9548
Change-Id: Ic11853e7521017af5e8bd583c7b82bb672821132
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2616873
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72306}
This reverts commit 9c09c227b0.
Reason for revert: gc stress failures https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20gc%20stress/20563/overview
Original change's description:
> [wasm-simd] Merge all any_true to v128.any_true
>
> In https://github.com/WebAssembly/simd/pull/423, all any_true
> instructions were removed, and replaced with a single v128.any_true.
>
> This patch removes all but v8x16.any_true, and renames it to
> v128.any_true.
>
> Bug: v8:11331
> Change-Id: Ie394ec841a1a1c4030c4f589eac2cee8a6a2a1f9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639033
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72304}
TBR=neis@chromium.org,gdeepti@chromium.org,neis@google.com,zhin@chromium.org
Change-Id: I52dbf8de679059dd7b17908c1fe3ada0eb54ff84
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:11331
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649240
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72305}
In https://github.com/WebAssembly/simd/pull/423, all any_true
instructions were removed, and replaced with a single v128.any_true.
This patch removes all but v8x16.any_true, and renames it to
v128.any_true.
Bug: v8:11331
Change-Id: Ie394ec841a1a1c4030c4f589eac2cee8a6a2a1f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639033
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72304}
This reverts commit 5a0938e593.
Reason for revert: Broke build https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8857098178780038608/+/steps/Check/0/logs/RunWasm_I32x4WidenI8x16S_liftoff/0
Original change's description:
> [wasm-simd][x64] Prototype i32x4.widen_i8x16_{s,u}
>
> This prototypes i32x4.widen_i8x16_s and i32x4.widen_i8x16_u for x64. It
> uses some masks and pshufb for the widening. These masks (3 for each
> instruction) are stored as external references.
>
> Bug: v8:11297
> Change-Id: I6c8f55426bbb44b16ed552f393762c34c2524b55
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617389
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72301}
TBR=neis@chromium.org,gdeepti@chromium.org,neis@google.com,ahaas@chromium.org,zhin@chromium.org
Change-Id: I83aa2e86854e39ac6afd250fdc0dfac7cdd99e6d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:11297
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2648194
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72302}
This prototypes i32x4.widen_i8x16_s and i32x4.widen_i8x16_u for x64. It
uses some masks and pshufb for the widening. These masks (3 for each
instruction) are stored as external references.
Bug: v8:11297
Change-Id: I6c8f55426bbb44b16ed552f393762c34c2524b55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617389
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72301}
Factor out the code sequence into macro-assembler functions to be reused
by Liftoff.
Bug: v8:10975
Change-Id: I82e253c94e09bf62197e7de87359d0e3956d2dcc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2643662
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72300}
The change https://chromium-review.googlesource.com/c/v8/v8/+/2572173
implemented HostGetSupportedImportAssertions [1] in a fairly literal
sense, where the host supplies a list of supported import assertions
and V8 filters the import assertions in a ModuleRequest and exposes
only supported assertions via its API surface.
However, we've decided that the interop guarantees provided
by doing the filtering in V8 are probably not worth the added
complexity. Thus, this change removes the filtering. Going forward,
hosts will be expected to ignore unknown asserions received from V8.
This is mostly a revert of
https://chromium-review.googlesource.com/c/v8/v8/+/2572173, with
v8::Isolate::CreateParams::supported_import_assertions being kept
for now (since we first have to delete the Blink code that sets it),
and a new comment in v8.h instructing hosts to ignore unknown
assertions.
[1] https://tc39.es/proposal-import-assertions/#sec-hostgetsupportedimportassertions
Bug: v8:10958
Change-Id: I7e8e2a7fbfe2d5bf891805cff6c3160d0e6825cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2643563
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72299}
Prototype these 6 instructions on x64:
- f64x2.convert_low_i32x4_s
- f64x2.convert_low_i32x4_u
- i32x4.trunc_sat_f64x2_s_zero
- i32x4.trunc_sat_f64x2_u_zero
- f32x4.demote_f64x2_zero
- f64x2.promote_low_f32x4
Some of these code sequences make use of special masks, we keep them in
external references.
Code sequence based on suggestions at:
https://github.com/WebAssembly/simd/pull/383
Bug: v8:11265
Change-Id: Ied67d7b5b6beaaccac7c179ec13504482cb9c915
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2643562
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72297}
According to the latest wasm-gc spec, the type immediate for the
argument's heap type is no longer required. This CL also adds a missing
check that the rtt immediate is a subtype of the argument's type.
Bug: v8:7742
Change-Id: I627002d1c4bdb4ca3f2181d2f4b659ce3e95cb2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642246
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72287}
- Use movl which clears the upper 32bits on x64
- Use xorl + movb for Smi.ptr values <= 0xFF, saving one byte over movl
Change-Id: Iacdacfbe397670667e71d1d12ef427a01994481d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642250
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72282}
Looks like these may have been missed; all other related operators
silence NaNs.
Bug: v8:7519
Change-Id: If6ee8d6e02d304ccbb4821c21386f93eab225434
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637853
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72277}
This implements support for the following instructions:
ref.func, call_ref, return_call_ref
Bug: v8:7748,v8:9495
Change-Id: If5bdc2b9bc2347de056de2917430b8d9dc901c53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632591
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72270}
Users of padded objects must know the actual object size for
implementing custom finalizers.
Bug: chromium:1056170
Change-Id: I0ddf9066cfece0a8d18a9e6fd985d09449eea92a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2644941
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72269}
The TraceTrait<T> checks whether T is a mixin to decide whether we can
use the fast (arithmetic) or slow (bitmap) method to look up the HoH.
Before this CL, the mixin application would also be considered as a
mixin because the marker is present, resulting in all cases going
through the object start bitmap.
The initial intention was to use the arithmetic for the mixin
applications as those inherit from GCed.
Bug: chromium:1056170
Change-Id: Ib0ba82a8f98e0481d2879ebacc1ca9bd9e675858
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2643395
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72262}
This CL introduces cppgc::HistogramRecorder api which is similar to the
v8::metrics::Recorder api and is used by cppgc to report histogram
samples to embedders. Embedders should implement the api if they want to
collect histograms and provide an instance of it on heap creation.
CppHeap uses an adaptor class that implements the HistogramRecorder api
and is used to forward the relevant info to the relevant
v8::metrics::Recorder.
The api used 3 data structures: 2 for incremental steps that need to be
reported as they come (marking and sweeping) and 1 for the end of a GC
cycle that aggregates statistics over the entire cycle.
The data structure only provide the "raw" samples (e.g. atomic mark
time, incremental mark time, etc...). The embedder is expected to
compute aggregate histogram on its own (e.g. overall marking time).
Bug: chromium:1056170
Change-Id: If63ef50a29a21594f654edb83084598980d221ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642258
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72256}
This reverts commit 6ada6a90ee.
Reason for revert: Revert for link issue:
https://bugs.chromium.org/p/v8/issues/detail?id=11335
Original change's description:
> Reland "Faster JS-to-Wasm calls"
>
> This is a reland of 860fcb1bd2
>
> - Disabled the tests for this feature in V8-lite mode (the original
> change broke V8-lite tests)
> - Also modified test console-profile-wasm.js that was brittle with this
> change because it assumed that there was always a JS-to-Wasm wrapper
> but this is not the case when the TurboFan compilation completes before
> the Liftoff-compiled code starts to run.
>
> More changes in Patchset 8:
>
> - Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
> into a new phase, wasm-inlining that reuses the JSInliner reducer.
> The doc
> https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
> describes the new logic.
>
> - Fixed a couple of small issues in wasm_compiler.cc to make sure that
> the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
> this should solve the problem we had inlining the calls in functions
> that can throw exception.
>
>
> Original change's description:
> > Faster JS-to-Wasm calls
> >
> > This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
> >
> > Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
> > the basis of the signature of a Wasm function to call, and whose task
> > is to:
> > - set "thread_in_wasm_flag" to true
> > - convert the arguments from tagged types into Wasm native types
> > - calculate the address of the Wasm function to call and call it
> > - convert back the result from Wasm native types into tagged types
> > - reset "thread_in_wasm_flag" to false.
> >
> > This CL tries to improve the performance of JS-to-Wasm calls by
> > inlining the code of the JS-to-Wasm wrappers in the call site.
> >
> > It introduces a new IR operand, JSWasmCall, which replaces JSCall for
> > this kind of calls. A 'JSWasmCall' node is associated to
> > WasmCallParameters, which contain information about the signature of
> > the Wasm function to call.
> >
> > WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
> > of the Wasm function, when the conversion is not necessary.
> > The actual inlining of the graph generated for this wrapper happens in
> > the simplified-lowering phase.
> >
> > A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
> > lazy deoptimizations that can happen if the Wasm function callee calls
> > back some JS code that invalidates the compiled JS caller function.
> >
> > Bug: v8:11092
> > Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538
> > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> > Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Maya Lekova <mslekova@chromium.org>
> > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> > Cr-Commit-Position: refs/heads/master@{#71824}
>
> Bug: v8:11092
> Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
> Change-Id: I7d8523fa916bf4029a31f8c7a72bbd93336dc0b9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596784
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72147}
Tbr: ahaas@chromium.org, jgruber@chromium.org
Bug: v8:11092, v8:11335
Change-Id: Iab2908928dfe7ea353f70cb5d3bf2de4d3074db6
Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2644758
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72253}
On x64, reference types where not handled yet in LiftoffAssembler::push.
Note that the values pushed on the stack there do not have to be
handled by a safepoint. The reason is that stack parameters in general
are handled separately from safepoints.
R=thibaudm@chromium.org
Bug: chromium:1168116
Change-Id: Ie62479c13839f0ba240d0e41fa76d07a2cc48881
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642263
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72252}
This ensures that large objects have alignment suitable for a fixed
double arrays.
Bug: chromium:1161759
Change-Id: I64fe88d641fedbb5e27c2b38c1b9a4e75cab535a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639959
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72251}
It acquires the string lock to avoid race conditions. It does so in a
slow way (by getting the isolate from the string) to avoid piping the
Isolate through.
Bug: v8:7790, chromium:1166095
Change-Id: I8b769b4e96ee780314359d1d15d712012aade88a
Fix: chromium:1166095
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637861
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72236}
Provide a way to trigger a write barrier when updating the embedder
fields. In future, such a mechanism should be encapsulated into V8.
Bug: chromium:1056170
Change-Id: I4e43362993c3e58d5bebdd58a7d46a39c0aa4f06
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2640419
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72227}
Add a dependency to a cppgc target for the the cppgc unit tests sources
so that the header files are used correctly. Previously it was working
because it added the external config which sets up the include
directories correctly, but would fail if the v8-gn.h file was not
generated quickly enough or if the cppgc_unittests_sources was built on
its own.
Bug: v8:11292
Change-Id: If12be4809b59b8dd5705468ad0343a1118547092
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2640458
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72222}
This fixes typing (and type conversions) in the two compilers and adds a
test for executing a memory.size instruction in memory64.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: Ic06b224437cb818ad74d0732fc4c8e08c9095231
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632594
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72219}
The icache and jump-table-assembler tests need memory that is both
writable and executable. On Mac, to do this we need to pass MAP_JIT to
mmap which is wired with the VirtualMemory::JitPermission flag.
Change-Id: If8236fa8983a4a59ef39fe777f26a02103dc6f75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637227
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#72217}
Previously ShouldHaveBeenSerialized() would return false for
kPossiblyBackgroundSerializedHeapObject objects which prevented
checks for whether the correct serialization had been done before
accessing Map::prototype() for these ObjectRefs.
BUG=chromium:1168435,v8:7790,v8:9684
Change-Id: I31b4cf7c7ce67ba1c46aea1451172b279d215508
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2640479
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72215}
This is a reland of 1694925c72
Minor fix to linkage for constexpr.
TBR=ahaas@chromium.org,neis@chromium.org
Original change's description:
> Reland "[compiler][wasm] Align Frame slots to value size"
>
> This is a reland of cddaf66c37
>
> Original change's description:
> > [compiler][wasm] Align Frame slots to value size
> >
> > - Adds an AlignedSlotAllocator class and tests, to unify slot
> > allocation. This attempts to use alignment holes for smaller
> > values.
> > - Reworks Frame to use the new allocator for stack slots.
> > - Reworks LinkageAllocator to use the new allocator for stack
> > slots and for ARMv7 FP register aliasing.
> > - Fixes the RegisterAllocator to align spill slots.
> > - Fixes InstructionSelector to align spill slots.
> >
> > Bug: v8:9198
> >
> > Change-Id: Ida148db428be89ef95de748ec5fc0e7b0358f523
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2512840
> > Commit-Queue: Bill Budge <bbudge@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#71644}
>
> Bug: v8:9198
> Change-Id: Ib91fa6746370c38496706341e12d05c7bf999389
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2633390
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72195}
Bug: v8:9198
Change-Id: I91e02b823af8ec925dacf075388fb22e3eeb3384
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2640890
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72209}
The V8 inspector is using the DebugPropertyIterator (a debug only
interface) while building RemoteObjects. The DebugPropertyIterator
uses the `KeyAccumulator::GetKeys` for this, which can potentially
throw, but the DebugPropertyIterator ignores exceptions and keeps
iterating. If multiple iteration steps throw an exception
(e.g. due to a pending stack overflow), we run into a CHECK in
Isolate::Throw, as we can't throw exceptions while another
exception is still pending.
This CL fixes the CHECK crash by properly propagating exceptions
after the iterator is created or advanced and returning early
in the inspector if an exception happens.
Please note that the regression test that showcases this behavior
is still disabled, as fixing the crash causes currently an
endless loop. While the exception in `ValueMirror::getProperties`
is handled by early returing, we still need to forward it as
the result of the `Runtime::evaluate` all the way up the stack.
R=bmeurer@chromium.org, yangguo@chromium.org
Bug: chromium:1080638
Change-Id: I1d55e0d70490a06a6bc1b0a3525236411da7f64b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639954
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72203}
Move index constants into the wrapper, add getters, and use the
wrapper in more spots.
Bug: v8:1166136
Change-Id: I3f37a541482fd6b7c604719c759952a72d58bad2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637218
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72198}
This reverts commit 1694925c72.
Reason for revert: Link error in CFI release build: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Clusterfuzz%20Linux64%20CFI%20-%20release%20builder/19756/overview
Original change's description:
> Reland "[compiler][wasm] Align Frame slots to value size"
>
> This is a reland of cddaf66c37
>
> Original change's description:
> > [compiler][wasm] Align Frame slots to value size
> >
> > - Adds an AlignedSlotAllocator class and tests, to unify slot
> > allocation. This attempts to use alignment holes for smaller
> > values.
> > - Reworks Frame to use the new allocator for stack slots.
> > - Reworks LinkageAllocator to use the new allocator for stack
> > slots and for ARMv7 FP register aliasing.
> > - Fixes the RegisterAllocator to align spill slots.
> > - Fixes InstructionSelector to align spill slots.
> >
> > Bug: v8:9198
> >
> > Change-Id: Ida148db428be89ef95de748ec5fc0e7b0358f523
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2512840
> > Commit-Queue: Bill Budge <bbudge@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Reviewed-by: Andreas Haas <ahaas@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#71644}
>
> Bug: v8:9198
> Change-Id: Ib91fa6746370c38496706341e12d05c7bf999389
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2633390
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72195}
TBR=bbudge@chromium.org,neis@chromium.org,ahaas@chromium.org
Change-Id: Ic94763925195c3a3552930e61a0eb0b7f0c0c756
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9198
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2640474
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72197}
This is a reland of cddaf66c37
Original change's description:
> [compiler][wasm] Align Frame slots to value size
>
> - Adds an AlignedSlotAllocator class and tests, to unify slot
> allocation. This attempts to use alignment holes for smaller
> values.
> - Reworks Frame to use the new allocator for stack slots.
> - Reworks LinkageAllocator to use the new allocator for stack
> slots and for ARMv7 FP register aliasing.
> - Fixes the RegisterAllocator to align spill slots.
> - Fixes InstructionSelector to align spill slots.
>
> Bug: v8:9198
>
> Change-Id: Ida148db428be89ef95de748ec5fc0e7b0358f523
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2512840
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71644}
Bug: v8:9198
Change-Id: Ib91fa6746370c38496706341e12d05c7bf999389
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2633390
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72195}
DevTools can't unambiguously determine whether code is JS or wasm.
This CL adds a string to the tracing output that will be 'JS', 'wasm' or
'other'.
Bug: chromium:1168052
Change-Id: Iaacb5ea9a83327e22d60bf6114f607e6fa5532ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637859
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72193}
The inlining of JS-to-Wasm wrappers can fail inside try/catch because
the IR built by WasmWrapperGraphBuilder::BuildJSToWasmWrapper does not
always set the correct control outputs in the call node.
This patch disables inlining inside try/catch to work around this issue.
Bug: chromium:1168386
Change-Id: I1b43bdb044b38d95c2d309290e228a86ba1513a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639927
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72191}
The bytecode offset (previously 'bailout id') was referred to as 'ast
id', 'node id', 'bailout id' in different spots. And 'bailout id' was
used to refer to deoptimization exits. This CL makes used terms more
consistent.
Bug: v8:11332
Change-Id: I2b34c7d4ebf465939e18fdfba675d83852f2430a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639756
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72190}
This reflects the actual contents of the type, which is an offset into
the bytecode (or certain marker values). Historically, in the days of
FCG the bailout id used to refer to node ids - this is why certain
tracing output still calls the bailout id 'node id' and 'ast id'.
These spots will be fixed in a follow-up CL.
This change is mechanical:
git grep -l BailoutId | while read f; do \
sed -i 's/BailoutId/BytecodeOffset/g' $f; done
With a manual component of updating the DeoptimizationData method
name from 'BytecodeOffset' to 'GetBytecodeOffset'.
Bug: v8:11332
Change-Id: I956b947a480bf52263159c0eb1e895360bcbe6d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639754
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72189}
This change adds Torque field definitions for ScopeInfo and begins to
use the Torque-generated accessors in some places. It does not change
the in-memory layout of ScopeInfo.
Torque compiler changes:
- Fix an issue where the parser created constexpr types for classes
based on the class name rather than the `generates` clause. This meant
that generated accessors referred to the imaginary type HashTable
rather than the real C++ type FixedArray.
- Don't pass Isolate* through the generated runtime functions that
implement Torque macros. Maybe we'll need it eventually, but we don't
right now and it complicates a lot of things.
- Don't emit `kSomeFieldOffset` if some_field has an unknown offset.
Instead, emit a member function `SomeFieldOffset()` which fetches the
slice for some_field and returns its offset.
- Emit an `AllocatedSize()` member function for classes which have
complex length expressions. It fetches the slice for the last field
and performs the multiply&add to compute the total object size.
- Emit field accessors for fields with complex length expressions, using
the new offset functions.
- Fix a few minor bugs where Torque can write uncompilable code.
With this change, most code still treats ScopeInfo like a FixedArray, so
I would like to follow up with some additional changes:
1. Generate a GC visitor for ScopeInfo and use it
2. Generate accessors for struct-typed fields (indexed or otherwise),
and use them
3. Get rid of the FixedArray-style get and set accessors; use
TaggedField::load and similar instead
4. Inherit from HeapObject rather than FixedArrayBase to remove the
unnecessary `length` field
After that, there will only be one ugly part left: initialization. I
think it's possible to generate a factory function that takes a bunch of
iterator parameters and returns a fully-formed, verifiably correct
ScopeInfo instance, but doing so is more complicated than the four
mostly-mechanical changes listed above.
Bug: v8:7793
Change-Id: I55fcfe9189e4d1613c68d49e378da5dc02597b36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2357758
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72187}
Doing a function call into the logger to decide whether logging is
enabled or not is more costly than necessary.
This CL changes logging to take FLAG_log as main signal whether logging
could be active. If FLAG_log == false, logging cannot be active. In
that case we always call into the logger and perform detailed checks
there.
This CL changes flag-definitions to set FLAG_log if they need logging.
Change-Id: Ia51ed9fb7128451bf1dcf345fab257547aab4a47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2602461
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72186}
This is a reland of 8703c38d9a
The reland marks the new test as slow, skips all variants, and
skips all non-release modes.
Original change's description:
> [compiler] Emit a function-entry stack check on OSR-entry
>
> This CL extends the smarter function-entry stack check logic (see
> v8:9534) to OSR'd code. These smarter stack checks prevent
> overflowing the stack during deoptimization.
>
> The challenge for both function-entry (FE) and OSR-entry (OE) stack
> checks is that there is no dedicated physical StackCheck to
> deoptimize into. For more context: the physical StackCheck bytecode
> was removed in crrev.com/c/1914218.
>
> FE stack checks solve this by using a marker bailout id to signify
> a deopt bytecode offset before the first bytecode.
>
> In this CL, OE stack checks take a similar approach by using the
> OSR'd loop's JumpLoop bytecode, which is conceptually immediately
> before the OSR'd loop header.
>
> When a stack overflow at an OE stack check occurs: %StackGuard
> may cause a lazy deopt on return to the optimized OSR code,
> causing re-execution of the JumpLoop handler in the
> InterpreterEnterBytecodeAdvance builtin, ultimately continuing
> execution the interpreter at the first bytecode of the OSR'd loop
> header.
>
> Bug: chromium:1034322, v8:9534
> Change-Id: I1ae88a08702cde9a5eb84a451a9f1acc41204d5c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625872
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72153}
Tbr: neis@chromium.org, solanes@chromium.org
Bug: chromium:1034322
Bug: v8:9534
Change-Id: I28a23d0cc4b14d59c3d4a5dbadd5dab3ac31d442
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639753
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72183}
This would be useful for ForInPrepare. Syntax is unchanged; Torque
should now do the right thing for builtins that return a two-element
struct. More elements than that is still not supported.
Bug: v8:7793
Change-Id: Ic315699402203aba07e906ff6e029834ec0061c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596498
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72171}
This prototypes i32x4.widen_i8x16_s and i32x4.widen_i8x16_u for the
interpreter.
This is the first instruction of its kind, a post-mvp, unary operation
that takes one immediate. Which is why there are more changes to the
decoder than usual.
Bug: v8:11297
Change-Id: Ib5c58965e0cba8d7a395b0dc57673110bc60e87c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617385
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72170}
1) Computed property keys (esp functions in them) shouldn't be inside
the object literal scope.
2) I was using an imprecise "maybe uses super" and storing it to
preparse data. This won't fly, since it pollutes sister scopes and
leads to confusion wrt whether an object literal needs a home object
or not. Made it precise (mostly cancelling changes in the original CL).
3) PreParser::NewSuperPropertyReference was creating a VariableProxy for
this_function (which made it used) -> inconsistent scopes between
parsing and preparsing.
4) MultipleEntryBlockContextScope was messing up the accumulator
Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
This saves memory (the home object doesn't need to be stored for each
method, but only once per class) and hopefully makes the home object
a constant in the optimized code.
Detailed documentation of the changes:
https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055
Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72169}
`last` indicates that it's the last element of the list but in reality
this supposed to indicate the previous entry in the list. Rename this
to something more clearer.
Change-Id: I26c9a1fca02cf6b10d0447768da694d590a43932
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637229
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72167}
On arm64, Windows Performance Recorder gets confused by the fact that fp
in Builtins_JSEntry doesn't point to the saved {fp, lr} pair for the
caller frame. The expected usage of fp is documented in [1]:
The frame pointer (x29) is required for compatibility with fast stack
walking used by ETW and other services. It must point to the previous
{x29, x30} pair on the stack.
In slightly more detail, the Windows function RtlWalkFrameChain is
responsible for generating stack traces during profiling with Windows
Performance Recorder, and that function relies on the rule quoted above.
Notably, it does not make any effort to read the unwinding data that one
could obtain with RtlLookupFunctionEntry. Stack walks using that data,
such as those performed by WinDbg and the cctest StackUnwindingWin64,
work fine.
It would be convenient if we could use fp in a more standard way during
JSEntry so that Windows profiling tools work correctly. (We can also
reduce JSEntry by two instructions in doing so.)
Both arm and arm64 currently put a -1 value on the stack at the location
that fp points to. This could prevent accidental access during the
epilog of JSEntry, where fp might be zero. However, we believe that this
protection is no longer necessary, and any bug that causes a read from
fp during the end of JSEntry would cause various CQ failures.
[1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160
Change-Id: Iece5666129b9188fc4c12007809b50f046f4044f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2607636
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72165}
The test was explicitly tiering up or down a module, without respecting
other isolates. Thus it was failing in multi-isolate mode.
This CL removes two runtime functions which do not make sense in a
multi-isolate setting (and were only used in this one test), and
replaces them with runtime functions that mimic what enabling/disabling
the debugger domain does: As long as there is at least one isolate which
needs modules to be tiered down, we keep them tiered down.
R=thibaudm@chromium.org
Bug: v8:10359, v8:10099
Change-Id: Ia85f4ea29ba6a6bb54aca54a48fadd351121d3eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637231
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72164}
This reverts commit 8703c38d9a.
Reason for revert: New test is timing out on gc-stress (e.g. https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/31726/overview)
Original change's description:
> [compiler] Emit a function-entry stack check on OSR-entry
>
> This CL extends the smarter function-entry stack check logic (see
> v8:9534) to OSR'd code. These smarter stack checks prevent
> overflowing the stack during deoptimization.
>
> The challenge for both function-entry (FE) and OSR-entry (OE) stack
> checks is that there is no dedicated physical StackCheck to
> deoptimize into. For more context: the physical StackCheck bytecode
> was removed in crrev.com/c/1914218.
>
> FE stack checks solve this by using a marker bailout id to signify
> a deopt bytecode offset before the first bytecode.
>
> In this CL, OE stack checks take a similar approach by using the
> OSR'd loop's JumpLoop bytecode, which is conceptually immediately
> before the OSR'd loop header.
>
> When a stack overflow at an OE stack check occurs: %StackGuard
> may cause a lazy deopt on return to the optimized OSR code,
> causing re-execution of the JumpLoop handler in the
> InterpreterEnterBytecodeAdvance builtin, ultimately continuing
> execution the interpreter at the first bytecode of the OSR'd loop
> header.
>
> Bug: chromium:1034322, v8:9534
> Change-Id: I1ae88a08702cde9a5eb84a451a9f1acc41204d5c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625872
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72153}
TBR=neis@chromium.org,jgruber@chromium.org,solanes@chromium.org
Change-Id: Ie72f2e2927ffa83d595aad0d88c606d422f953a2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1034322
Bug: v8:9534
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637858
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72158}
The inspector fuzzer is terminating the isolate after two seconds. At
this point, we can be in pretty much any state, and any further JS
execution would fail.
This CL fixes an issue where we got the termination signal when creating
a context for a regexp (while installing extensions).
There might be more places that need fixing, but with this CL the linked
issue does not reproduce locally any more, so it's a step forward.
R=szuend@chromium.org, bmeurer@chromium.org
Bug: chromium:1166549
Change-Id: I33b48205b71877aca6cfe5267f353fa899bfa05c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2636153
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72156}
Termination GCs are used to destroy remaining C++ object on the
managed heap to free potential off-heap memory. This is important for
gracefully shutting down workers.
Drive-by: Add guard prohibiting recursive sweeping calls on the
mutator thread.
Bug: chromium:1056170
Change-Id: I02ea3b632d38f5beab18cc8f077cf717ed877909
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2631504
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72155}
This CL extends the smarter function-entry stack check logic (see
v8:9534) to OSR'd code. These smarter stack checks prevent
overflowing the stack during deoptimization.
The challenge for both function-entry (FE) and OSR-entry (OE) stack
checks is that there is no dedicated physical StackCheck to
deoptimize into. For more context: the physical StackCheck bytecode
was removed in crrev.com/c/1914218.
FE stack checks solve this by using a marker bailout id to signify
a deopt bytecode offset before the first bytecode.
In this CL, OE stack checks take a similar approach by using the
OSR'd loop's JumpLoop bytecode, which is conceptually immediately
before the OSR'd loop header.
When a stack overflow at an OE stack check occurs: %StackGuard
may cause a lazy deopt on return to the optimized OSR code,
causing re-execution of the JumpLoop handler in the
InterpreterEnterBytecodeAdvance builtin, ultimately continuing
execution the interpreter at the first bytecode of the OSR'd loop
header.
Bug: chromium:1034322, v8:9534
Change-Id: I1ae88a08702cde9a5eb84a451a9f1acc41204d5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625872
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72153}
If a register is used for both input and output by a SAME_INPUT_OUTPUT
operand, then it represents a different virtual register for the end
use-position of an instruction (since that will become the output's
virtual register). It therefore can't be used to represent the input
virtual register for any input operands that are USED_AT_END.
BUG=chromium:1163715,v8:9684
Change-Id: I8dc0008ba81d5f1d0e38091b6dc013725c62b1b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632700
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72149}
Docs: https://docs.google.com/document/d/13n1qaB6A-gvgWc9NDhWm-UPuOqow_Y0DNgCeTbtIotI
Modify that C++ backend so that it can emit either runtime C++ or
postmortem debugging code. When in postmortem debugging mode, the
overall code structure would look similar with some difference:
1. Instead of passing an Isolate* everywhere, we pass a MemoryAccessor.
2. Instead of runtime class names like String, we use uintptr_t
3. When loading data from objects, instead of TaggedField<T>::load or
Object::ReadField (which read from the current process), we use the
MemoryAccessor and read data from the debuggee process.
4. Return values should be wrapped in the Value struct.
Implement the debug accessors for complex length expressions and add
test for such class (SmallOrderedHashSet).
Change-Id: I34107c92b31ed4e07bb628ae58c84487e41ba648
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2477921
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72148}
This is a reland of 860fcb1bd2
- Disabled the tests for this feature in V8-lite mode (the original
change broke V8-lite tests)
- Also modified test console-profile-wasm.js that was brittle with this
change because it assumed that there was always a JS-to-Wasm wrapper
but this is not the case when the TurboFan compilation completes before
the Liftoff-compiled code starts to run.
More changes in Patchset 8:
- Moved inlining of the "JSToWasm Wrapper" away from simplified-lowering,
into a new phase, wasm-inlining that reuses the JSInliner reducer.
The doc
https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
describes the new logic.
- Fixed a couple of small issues in wasm_compiler.cc to make sure that
the graph "JSToWasm Wrapper" subgraph has a valid Control chain;
this should solve the problem we had inlining the calls in functions
that can throw exception.
Original change's description:
> Faster JS-to-Wasm calls
>
> This replaces https://chromium-review.googlesource.com/c/v8/v8/+/2376165/.
>
> Currently JS-to-Wasm calls go through a wrapper/trampoline, built on
> the basis of the signature of a Wasm function to call, and whose task
> is to:
> - set "thread_in_wasm_flag" to true
> - convert the arguments from tagged types into Wasm native types
> - calculate the address of the Wasm function to call and call it
> - convert back the result from Wasm native types into tagged types
> - reset "thread_in_wasm_flag" to false.
>
> This CL tries to improve the performance of JS-to-Wasm calls by
> inlining the code of the JS-to-Wasm wrappers in the call site.
>
> It introduces a new IR operand, JSWasmCall, which replaces JSCall for
> this kind of calls. A 'JSWasmCall' node is associated to
> WasmCallParameters, which contain information about the signature of
> the Wasm function to call.
>
> WasmWrapperGraphBuilder::BuildJSToWasmWrapper is modified to avoid generating code to convert the types for the arguments
> of the Wasm function, when the conversion is not necessary.
> The actual inlining of the graph generated for this wrapper happens in
> the simplified-lowering phase.
>
> A new builtin, JSToWasmLazyDeoptContinuation, is introduced to manage
> lazy deoptimizations that can happen if the Wasm function callee calls
> back some JS code that invalidates the compiled JS caller function.
>
> Bug: v8:11092
> Change-Id: I3174c1c1f59b39107b333d1929ecc0584486b8ad
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557538
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Georg Neis (ooo until January 5) <neis@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#71824}
Bug: v8:11092
Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
Change-Id: I7d8523fa916bf4029a31f8c7a72bbd93336dc0b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596784
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72147}
StateValuesAccess iterates over actual (non-adapted) arguments, thus
we must be careful not to iterate past their end when handling rest
args and advancing through the initial non-rest-args.
Tbr: neis@chromium.org
Bug: chromium:1167709,chromium:1166136
Change-Id: If506050a5518f394e0dcdbf39840b99923d4cbae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637213
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72145}
For asynchronous compilation, the beginning and end of compilation are
marked with different trace events. To allow to connect these events, a
compilation id is added to the start and end events. Note that the
compilation id is not added to all trace events to avoid bloating
traces. Ids may be added later to these events if necessary.
R=clemensb@chromium.org
Bug: chromium:1084929
Change-Id: I36ad598d27dea355fcca8992534c91e5a880fdaa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2629274
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72144}
This reverts commit 4d5b878b61.
Reason for revert: Suspected to cause a failure on ChromeOS, which is blocking the roll - https://chromium-review.googlesource.com/c/chromium/src/+/2636263
Original change's description:
> [super] Store home object in Context instead of JSFunction
>
> This saves memory (the home object doesn't need to be stored for each
> method, but only once per class) and hopefully makes the home object
> a constant in the optimized code.
>
> Detailed documentation of the changes:
> https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
>
> Bug: v8:9237
> Change-Id: Ia0925bdc8bfe54cbefcba6d10f64746d63a530c7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72137}
TBR=marja@chromium.org,leszeks@chromium.org
Change-Id: Idc5a8240cef4da8893ccc608ee4ae0d7206a1ba8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9237
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637215
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72142}
There was a bug that only the last local with a reference type got
initialized to null, all other locals kept the initial value of 0. This
CL fixes this bug.
Additionally this CL optimizes the code slightly. Before this CL, the
null reference was loaded from the instance for every local with
reference type. Now the null reference is cached after the first load
and then used for all other locals.
R=thibaudm@chromium.org
Bug: chromium:1167587
Change-Id: Ic11fc76b650e6daa029491154744fc132778f70d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632695
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72139}
Removes:
- v8_disable_arguments_adaptor GN flag
- ArgumentsAdaptorTrampoline
- ArgumentsAdaptorFrame class
Change-Id: I382ebe6c25c3c172bee5df3e86e762fca10fa392
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2622911
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72133}
memory.size returns in i64 if memory64 is enabled.
This CL fixes typing and adds a decoder test. Execution will be tested
and fixed in a follow-up CL.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: I15818a6273b579d0faacec7f77dc813ae9ba218f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632593
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72132}
For memory64, the init expressions for data segments provide a 64-bit
value. This CL adds a new {EvalUint64InitExpr} function alongside
{EvalUint32InitExpr}. It supports i64.const and global.get operations.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: I58acbb28acb8771a0947f9d5df1c14e6ca0f79cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632589
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72131}
FrameState parameters must not be iterated directly since parameters
can be encoded into StateValues (i.e. parameter i is not necessarily
InputAt(i)). Instead, they should be accessed through the
StateValuesAccess helper class.
One example:
82: StateValues[sparse:^^^^^^](81, 31, 32, 33, 34, 35)
81: StateValues[sparse:^^^^^^^^](110, 24, 25, 26, 27, 28, 29, 30)
31: NumberConstant[8]
32: NumberConstant[9]
33: NumberConstant[10]
34: NumberConstant[11]
35: NumberConstant[13]
Here, node 81 holds multiple parameters. These are properly iterated
by the StateValuesAccess class.
Bug: chromium:1166136
Change-Id: I12725f83994e1c05571bcba153ff45154b16d93f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625879
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72126}
This reverts commit 3a6f75ac94.
Reason for revert: performance regressions https://bugs.chromium.org/p/chromium/issues/detail?id=1163063
Original change's description:
> [objects] Remove MakeExternal case for uncached internal strings
>
> 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}
TBR=leszeks@chromium.org,solanes@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7790
Change-Id: I5dcc734869c3c921eacd89426309141127a85f47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2633547
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72123}
This reverts commit b3d09001eb.
Reason for revert: https://chromium-review.googlesource.com/c/v8/v8/+/2565511 has to be reverted, and this was a follow-up to that
Original change's description:
> [objects] Remove uncached internal external string type
>
> We shouldn't be creating those anymore since they are not thread-safe.
>
> Bug: v8:7790
> Change-Id: I4546d995fa32eb076c8dfe9d95301fad719c9e07
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615347
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72006}
TBR=rmcilroy@chromium.org,leszeks@chromium.org,solanes@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7790
Change-Id: I4eb1a6b8446fa602eeb5bf29fbf1fe57182cdbf3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2627605
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72122}
There is an implication from --predictable => --single-threaded =>
--no-wasm-tier-up. This implication introduces conflicting flags for
all tests that set --wasm-tier-up. This CL disables all these tests.
R=machenbach@chromium.org
Bug: v8:11319
Change-Id: I32452d74ae33fc0e081971c5c0ed840334f274d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632598
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72119}
I haven't done any test262 rolls in forever and won't be doing any for
the foreseeable future, there's no need for me to be an OWNER.
Change-Id: I51d5915f5704d0c15c0735c95cfbff9464a0e929
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632592
Auto-Submit: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72117}
Exception ref is not part of the latest exception handling
proposal. Remove the corresponding value type, the type opcode and some
obsolete tests.
R=clemensb@chromium.org
Bug: v8:8091
Change-Id: I5e068ba3426f4b56b90ef056193acdd8cc8fe7d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632599
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72116}
This is a reland of 2f3cda580b
GetFirstUnusedStackSlot is restored, and used for finding the padding
slot location, if any.
Original change's description:
> [compiler] Rework calculation to start of return slots
>
> - Changes GetOffsetToReturns to take into account return slot padding
> and argument padding.
> - Changes GetStackParameterDelta to use GetOffsetToReturns for the SP
> delta calculation.
> - Removes GetFirstUnusedStackSlot.
>
> Change-Id: I13df72e86750c62798bae262f0560cf1d7f981db
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2593306
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72078}
Change-Id: I954d7e7487728dbd6a545a6c84efb8f8f65d894d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2626979
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72115}
This reverts commit 37c3e05e81.
Reason for revert: https://chromium-review.googlesource.com/c/v8/v8/+/2565511 has to be reverted, and this was a follow-up to that
Original change's description:
> [test] Update MakeExternal tests
>
> They weren't initializing the VM at the start of the test. Also updated
> the test description.
>
> Bug: v8:7790
> Change-Id: I7b9df9e3aebb43fc526e16ec260aa071c0fdeb92
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615019
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71978}
TBR=leszeks@chromium.org,solanes@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7790
Change-Id: I35bc0090c3beed4ef11a458f0e26c44b22f7b654
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2627606
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72114}
Liftoff is not fully feature complete yet. To test that Liftoff can
bailout to TurboFan also for debugging, this CL adds
* an opcode that is only implemented in TurboFan
* a flag that allows that opcode to be compiled with TurboFan
* a bailout for this opcode to Liftoff.
R=clemensb@chromium.org
Bug: v8:7581
Change-Id: Ie4b4654d0d36ab937a7dfe9b1bb6a187b17615fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2629284
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72113}
76217f5 fixed the profiler so it would only sample a thread if
it had the Isolate lock. Unfortunately, this fix missed a timing
window where a thread might have the Isolate lock but might not
have restored the thread-specific data such as thread_local_top_
for the locked thread yet, so the sampler might end up using data
from a different thread.
This doesn't cause any seg faults or the like because the thread
we *meant* to sample has the Isolate lock so the thread we're
accidentally sampling can't mess with any Isolate data but we can
still get incorrect sample data which can be especially obvious if
the accidentally sampled thread is inside code that would never
run on the thread we meant to sample.
Fortunately, we can tell when all thread-specific data has been
restored to the Isolate because thread_state_ in the
PerIsolateThreadData for a thread is set to a non-null value
until everything has been restored, at which point it gets set
to null. So the fix adds a check after the test for the Isolate
lock to check if thread_state_ is null for the thread we mean to
sample. If so, we know all the data in the Isolate is good to go
for sampling.
Bug: v8:11316
Change-Id: I02d6361d8cbd6ec809ad8fb7ef07f5e9c94c7d1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2628133
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72112}
Port: 646bdbf843
Bug: v8:10972
Change-Id: I9b199dc75d0e759a768da55298af383ebeb30e90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2632351
Auto-Submit: Liu yu <liuyu@loongson.cn>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72108}
Remove the ambient dependency on the currently entered isolate, let the
embedder pass it in explicitly.
Bug: v8:11287
Change-Id: I03690390a308a59e2c6ea5c6ae268780d836b717
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2608209
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72105}
Offsets in regular expressions are limited to 16 bits.
It was possible to exceed this limit when emitting greedy loops where
the length of text nodes exceeded 16 bits, resulting in overflowing
offsets.
With this CL we throw a SyntaxError "Regular expression too large" to
prevent this overflow.
Bug: chromium:1166138
Change-Id: Ica624a243bf9827083ff883d9a976f13c8da02e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2629286
Commit-Queue: Patrick Thier <pthier@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72095}
Changes:
- Add --wasm-loop-unrolling flag. Everything in this CL happens behind
this flag.
- In decoding, DoReturn does not take returned values as an argument.
It is now the responsibility of graph-builder-interface.cc to extract
these values. Note that this is what was already happening in Liftoff.
- In pipeline.cc, add phase to remove loop exits after generating the
turbofan graph.
- Explicitly disallow calling FallThruTo() on loops.
- Add loop assignments and loop header node to Control type in
graph-builder-interface.cc. Assign them in Loop().
- Main change: Add loop exit nodes to wasm-generated graphs. For
details, consult this design doc: https://docs.google.com/document/d/1AsUCqslMUB6fLdnGq0ZoPk2kn50jIJAWAL77lKXXP5g
- Inline PrepareForLoop().
Bug: v8:11298
Change-Id: I65058f1b5df3f862f4a62f4dcb0bd7e1f1dcf4ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2621082
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72094}
Adds support for Member<const T> by keeping the untyped storage in
MemberBase const, which is stronger than the required constness. All
accesses go through BasicMember which can re-add the appropriate
constness specified by the user.
The same concept is applied to all Member and Persistent handles.
Bug: chromium:1056170
Change-Id: I5a620258be3acb6a1b4b1437e69b8d7d1ec5ce6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625871
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72090}
This is a reland of 164cf80bbb
The reland fixes UB (left-shift of negative integer type) with a
static_cast<uint32_t>.
Original change's description:
> [regexp] Hard-crash on invalid offsets in AdvanceCurrentPosition
>
> Drive-by: Range checks in `Emit(byte, twenty_four_bits)` to ensure the
> given packed bits actually fit into 24 bits.
>
> Bug: chromium:1166138
> Change-Id: I2e711e6466bb48d7b9897f68dfe621d12bd92508
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625877
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72064}
Tbr: leszeks@chromium.org
Bug: chromium:1166138
Change-Id: I514495e14bb99dfc9588fdb4a9f35d67d8d64acb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2626663
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72088}
- Changes GetOffsetToReturns to take into account return slot padding
and argument padding.
- Changes GetStackParameterDelta to use GetOffsetToReturns for the SP
delta calculation.
- Removes GetFirstUnusedStackSlot.
Change-Id: I13df72e86750c62798bae262f0560cf1d7f981db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2593306
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72078}
This CL prepares the WasmModuleBuilder for memory64 and adds a first
mjsunit test which executes a few memory loads and stores, some of them
trapping.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: Ia77c32ff0ee774665cd4bd0997c3609f6f17b80f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2589974
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72077}
Implement these 4 instructions for arm64 and arm Liftoff:
- i64x2.widen_low_i32x4_s
- i64x2.widen_high_i32x4_s
- i64x2.widen_low_i32x4_u
- i64x2.widen_high_i32x4_u
Drive-by cleanup of the test case to make it clearer that we are
checking against an unsigned result.
Bug: v8:10972
Change-Id: I509a8df8a6f2109417ad5aaaa0324ced50bdc84a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2626713
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72074}
Ext mul's codegen assumes that all inputs are in registers, but the
instruction-selector wasn't the correct constraints. The codegen for ext
mul is slightly complicated so we chose to restrict the inputs to be
registers rather than changing codegen.
Bug: chromium:1165966,v8:11262
Change-Id: I5d4eb56d17a4d0a2927b089dbf74362c7e7ff4fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2626711
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72073}
Drive-by: Range checks in `Emit(byte, twenty_four_bits)` to ensure the
given packed bits actually fit into 24 bits.
Bug: chromium:1166138
Change-Id: I2e711e6466bb48d7b9897f68dfe621d12bd92508
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625877
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72064}
This skips sending the data urls along with Runtime.CallFrame,
and Runtime.ExceptionDetails.
Also-by: bmeurer@chromium.org
Bug: chromium:1132260
Change-Id: I45136bc0d3217caf8fbd93946b021f56f64f04b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2621077
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72063}
This moves the logic for the debug name heuristic, which derives names
for imported and exported entities from the relevant tables, into
wasm-debug.{cc,h} and stores these maps on the DebugInfoImpl rather than
on the WasmModule.
Drive-by-fix: Also use the import table based heuristic for function
names, just like we use it for everything else.
Bug: chromium:1164305
Change-Id: I8a21e0880c680079f63e6607b5b62c788049b9e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2625870
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72061}
bulk-memory shipped in V8 v7.5, hence the feature flag can be removed
now. This saves some binary size and a few dynamic checks for the flag.
R=ahaas@chromium.org
Bug: v8:11074
Change-Id: Ia73622637939f2192940fdd6909520786ed27286
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2622913
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72045}
This adds the following internal properties to `WasmInstanceObject`
values in DevTools:
- `[[Module]]` pointing to the `WasmModuleObject`, allowing the
developer to find the module to an instance no matter where in
DevTools front-end the instance is inspected.
- `[[Functions]]`, `[[Globals]]`, `[[Memories]]`, and `[[Tables]]`
are shown (when they aren't empty), allowing developers to inspect
the entities within an instance no matter where in DevTools front-end
it's inspected.
This also updates the _Module_ scope for Wasm frames to show the entity
containers (`functions`, `globals`, `memories` and `tables`) in addition
to the `instance` and `module` to make it easier accessible (fewer
clicks to get there), but also to align it better with the _Add property
path to Watch_ and _Copy property path_ features (since exactly the same
names are exposed via Debug Evaluate on Wasm frames).
```
> Stack
> Locals
v Module
> module
> instance
> functions
> globals
> memories
> tables
```
Drive-by-fix: Move GetWasmModuleObjectInternalProperties() logic into
debug-wasm-support.cc
Screenshot: https://imgur.com/ksEHG2I.png
Doc: http://bit.ly/devtools-wasm-entities
Fixed: chromium:1165294
Bug: chromium:1071432, chromium:1164241, chromium:1165304
Change-Id: Ia88fb2705287c79988ff2b432e4a33ac34e098f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2622912
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72042}
`0x12345678` will be written to memory in the same order on BE
machines however, as Wasm is LE enforced, a memory load will
force a byte reverse operation on BE machines which changes the value.
To fix the problem, we write the reversed value to memory.
Change-Id: I0d562768d5cef823cb918ed1b57a2a41e404ffc6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2622927
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72041}
... and fix an issue in TurboFan and issues in Liftoff.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: I3493205ab56a4ded550af6fcd75c465f7d8894ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618246
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72035}
The watchdog previously didn't terminate execution, it just prevented
the execution of additional tasks.
This CL fixes that by making {TaskRunner::Terminate} actually terminate
execution in the isolate.
It also adds a regression test for this.
R=szuend@chromium.org
Bug: chromium:1154412, chromium:1142437
Change-Id: Ic6638e8a5c37e8840a85651b4d4bea2ee0f71c43
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2622212
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72031}
Use a bit to work around the issue of ICU getType() bug.
Bug: v8:11295
Change-Id: I15d65bd44c489031d789e7638ea8abab90128124
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614216
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72028}
Prototype these 4 instructions:
- i64x2.widen_low_i32x4_s
- i64x2.widen_high_i32x4_s
- i64x2.widen_low_i32x4_u
- i64x2.widen_high_i32x4_u
Implementation is the same as x64.
Drive-by fix to add a missing CpuFeatureScope to x64.
Bug: v8:10972
Change-Id: Iacc84bce156053d0ac39b1a419727c93c499a8c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2612339
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72025}
Also remove some ifdefs since it is implemented on all architectures.
Bug: v8:10997
Change-Id: I06f82e2c67219a8990bdd7c78e63b1300c8f34d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2620907
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72024}
Implementation is the same as x64.
Disassembly support for the new instruction, pmulhrsw, is already
supported due to the macro list.
Bug: v8:10971
Change-Id: I099c4f8c3da521006ef5e2b151626f25a5df1ed9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2620898
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72021}
This CL fixes a bug in the code generation for I32AtomicCompareExchange
in Liftoff on ia32. The problem is the inconsistency that
LiftoffAssembler::PeekToRegister(...) introduces to the cache state.
PeekToRegister loads the value from the value stack into a register, but
does not pop the value off the stack. When the value was already stored
in a register, the use counter of that register gets decreased, even
though the value is still on the stack.
The problem arises when this register later gets reused, which is
necessary unfortunately on ia32. When SpillRegister is called for this
register, all stack values that are stored in this register get written
to memory. SpillRegister uses the use counter of the register to detect
when the register was spilled to all stack slots that were cached by
this register. However, as described above, the value stack and the use
counter are inconsistent at that moment, so SpillRegister finishes
early and does not spill the register to all stack values, and this
causes the bug later.
With this CL the decrement of the use counter gets delayed until when
the value actually gets popped off the stack.
R=clemensb@chromium.org
Bug: chromium:1145135
Change-Id: I07cb256a7e5135dbce41b246c120650635ad2758
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2602464
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72018}
In memory64, the index is a 64-bit value even on 32 bit. Thus the bounds
check needs to check explicitly that the high word is zero. The (pointer
sized) low word is then checked against the actual memory size.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: I311664ccadaec44a6c88777a60b1a3b45b6c0642
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617088
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72016}
This adds a first execution test for memory64 in the form of a cctest.
Several things are still not working correctly, hence this test only
checks TurboFan on 64-bit systems, and Liftoff.
Bounds checks in Liftoff are fixed to work correctly on 32-bit.
Follow-up CLs will extend the test to also test TurboFan on 32-bit, the
interpreter, and traps. All of those features still have issues.
R=manoskouk@chromium.org
Bug: v8:10949
Change-Id: Ic7edcf3783421634fe2ec99eac6f257c557a29b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2610968
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72014}
This change unifies the locals, stack, and globals objects exposed for
WebAssembly frames via the Scope view and via DebugEvaluate to use the
same underlying objects (implemented via interceptors). This also
means that for locals and globals we now consistently expose names
prefixed by a dollar symbol everywhere.
Drive-by-fix: Move the debug::ScopeIterator implementation for WasmFrame
into debug-wasm-support.cc, so WebAssembly scope details are all found
in one place instead of scattered around the code.
Drive-by-cleanup: Rename GetJSDebugProxy to GetWasmDebugProxy for
consistency. GetJSDebugProxy is a bit misleading, since the debug proxy
is not about JavaScript, but just exposed to JavaScript.
Doc: http://bit.ly/devtools-wasm-entities
Bug: chromium:1159307, chromium:1127914, chromium:1162229
Change-Id: If932bd06bbce72542823f63dac1bd976ab33937a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615348
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72009}
We shouldn't be creating those anymore since they are not thread-safe.
Bug: v8:7790
Change-Id: I4546d995fa32eb076c8dfe9d95301fad719c9e07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615347
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72006}
New internal properties expose the byte length of an ArrayBuffer as well
as the pointer to the backing store, which will serve as a unique ID
to show when SharedArrayBuffers in different workers are the same buffer.
Bug: chromium:1163800
Change-Id: I49930765cb38f75ba5c6cee5a0a6827f4fec42d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618242
Commit-Queue: Eric Leese <leese@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72000}
When creating a new closure, we check feedback vector for any optimized
code and install it on the newly created closure. We evict the optimized
code from the feedback vector if it is marked for deoptimization. We
used to evict the code before creating the new closure. However,
creating a new closure could cause allocation failures and hence trigger
a GC. This could mark optimized code on feedback vector for
deoptimization if any weak objects held by optimized code are GC'ed.
This cl delays the eviction unitl after the closure was created.
Bug: v8:1163184
Change-Id: I217279e4a51f75b87bb7ae5a00fd1cf57805e3c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2613034
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71999}
Changes:
- Add two additional PopTypeError overloads which take a C++/C-style
string as argument over a ValueType.
- Change type errors in decoding to use PopTypeError. This improves
consistency of error formatting as well as code readability.
- Improve some immediate argument errors.
- Adapt decoding unit tests.
Change-Id: Ifd54712965049a80692dbc3fde1ef489596e8662
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614059
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71998}
Invoking Goto in graph-builder-interface from inside a 'let' can cause
the number of locals between source and target ssa environment to be
different. This CL addresses this bug and adds a few unit tests.
Unfortunately, after this change we have to resort to always using
copy-constructors for SsaEnv, which might cause slowdown in decoding.
Bug: v8:9495
Change-Id: Idf5ace6c7563eff9d774d402f3a81e77959556ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614062
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71993}
This is a reland of a3ce2f6da2
(No changes; was reverted because a dependency was reverted.)
Original change's description:
> [wasm-gc] Liftoff support part 5: i31
>
> This implements support for i31.get_s and i31.get_u.
>
> Bug: v8:7748
> Change-Id: Icbfddbc2ff46b4eb6bf3edf7b3a794f9797361d4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595309
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71808}
Bug: v8:7748
Change-Id: Id8e66cab285d2a36fcd712b92a522e83dea93193
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617089
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71984}
Previously the Debug Proxy API that's exposed on Wasm frames by
Runtime.evaluateOnCallFrame() was implemented via actual JSProxy
instances. That means that all entities such as "memories", "tables",
"stack", "globals", etc. were JSProxy instances with "get" and "has"
traps. But that has a couple of down-sides:
1. In DevTools front-end, the proxies are shown as JSProxy, which is not
very useful to developers, since they cannot interact with them nor
can they inspect their contents. And the object preview also only
shows "Proxy {}" for them.
2. The performance doesn't scale well, which becomes a painful
bottleneck with larger Wasm modules that contain hundreds of
thousands of functions or globals.
3. We cannot use the JSProxy instances in the Scope view (for the
reasons outlined in 1.) and hence we have different logic to provide
Scope values than values in the rest of DevTools, which led to subtle
but annoying bugs and inconsistencies.
This also changes the "locals" implementation by querying the values
ahead of time, similar to the object exposed to the Scope view, instead
of on-demand, since the "locals" object might survive the current
debugger pause and peeking into the stack afterwards would read invalid
memory (and might even be a security issue). For being able to change
locals we need to look into a similar solution as what we have for
JavaScript locals already. The expression stack already works this way.
For performance reasons (especially scaling to huge, realistic Wasm
modules), we cache the per-instance proxies ("functions", "memories",
"tables" and "globals") on the WasmInstanceObject and reuse them (which
is safe since they have a `null` prototype and are non-extensible), and
we also cache the proxy maps (with the interceptors) on the
JSGlobalObject per native context.
Doc: http://bit.ly/devtools-wasm-entities
Bug: chromium:1127914, chromium:1159402, chromium:1071432, chromium:1164241
Change-Id: I6191035fdfd887835ae533fcdaabb5bbc8e661ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606058
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71981}
Prototype load lane instructions on Liftoff, only for x64.
Bug: v8:10975
Change-Id: Ifdf58f08b65762d592e99de91c7c622d2a964a9a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2612335
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71980}
They weren't initializing the VM at the start of the test. Also updated
the test description.
Bug: v8:7790
Change-Id: I7b9df9e3aebb43fc526e16ec260aa071c0fdeb92
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615019
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71978}
In order to avoid internal external uncached Strings, we can copy the
String at the moment of internalizing if it is an external & uncached
String.
Bug: v8:7790
Change-Id: Ie7ed287c105a127b8b4c867aab1a808265a922b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2613029
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71977}
We were incorrectly clearing the high reg from the list of regs to load.
The intention was to prevent double (and incorrect) loading - loading
128 bits from the low fp and the loading 128 bits from the high fp.
But this violates the assumption that the two regs in a pair would be
set or unset at the same time.
The fix here is to introduce a new enum for register loads, a nop, which
does nothing. The high fp of the fp pair will be tied to this nop, so as
we iterate down the reglist, we load 128 bits using the low fp, then
don't load anything for the high fp.
Bug: chromium:1161654
Change-Id: If2ea79132b78623e5990237c60cf0883d9a8223f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2617380
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71976}
Now that the underlying bug is fixed, we can expect the test to always
pass.
Also simplify the test a tiny bit and skip it on debug builds because
it's slow.
Bug: chromium:1161357
Change-Id: I2ce5e064b4f707f4bd680f04df95d5a342bec1b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2616220
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71972}
This is a reland of 94f2212b4d
Nothing changed, think the failures were flaky.
Original change's description:
> [wasm-simd] Scalar lowering for extended multiply
>
> R=bbudge@chromium.org
>
> Bug: v8:11262
> Change-Id: Idd6a7514a16c561832af603dbf63779a0e402f45
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2603771
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#71920}
Bug: v8:11262
Change-Id: I6c504b2e0d1ad39e202483a72419dadb3b66eea8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2612330
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71965}
When AVX2 is available, we can use vbroadcastss. On AVX, use vshufps,
since it is non-destructive. On SSE, shufps is 1 byte shorter.
FIXED=b/175364402
Change-Id: I5bd10914579d8db012192a9c04f7b0038ec1c812
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2599849
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71964}
Previously we had introduced a special `v8::internal::WasmValue` type
which we used to expose Wasm values to the Scope view in Chromium
DevTools. The problem however is that these values cannot be exposed to
JavaScript (and in particular not to Debug Evaluate), which means that
particularly for v128 and i64 we have inconsistent representations
across the various parts of DevTools.
This change removes the `wasm` type from the RemoteObject and all the
adjacent logic, and paves the way for a uniform representation of Wasm
values throughout DevTools. For i64 we will simply use BigInt
consistently everywhere, and for i32, f32 and f64 we'll just use Number.
For externref we will represent the values as-is directly. For v128
values we currently use a Uint8Array, but will introduce a dedicated
WasmSimd128 class in a follow-up CL.
Bug: chromium:1071432
Fixed: chromium:1159402
Change-Id: I0671e5736c9c27d7ca376e23ed74f16d36e03c80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614428
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71962}
There's a bit more work to do to add support for import assertions for
dynamic import(). This is the first of a series of changes to do that.
This adds parser support for the form of import() that takes import
assertions per https://tc39.es/proposal-import-assertions/#prod-ImportCall
A future change will pass the assertions expression along to
Runtime_DynamicImportCall where the assertions will be unpacked and
filtered per Isolate::supported_import_assertions_.
Bug: v8:10958
Change-Id: Ib1c80d15ac44923d97c5fdfcc4bd732cb9245cf9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2612038
Reviewed-by: Adam Klein <adamk@chromium.org>
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@{#71960}
Previously, for wrapper/wrappable pairs, only JS object size was
accounted for. With this change, the C++ part is also accounted for.
Change-Id: Ibd945cb28c808d8c01fa41453f94a6de9883b764
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615258
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71959}
When --harmony-dynamic-import was removed in
https://chromium-review.googlesource.com/c/v8/v8/+/2509942 it looks
like we were left with some redundant invocations of
RunParserSyncTest/RunModuleParserSyncTest in ImportExpressionErrors.
This removes them.
Change-Id: I2fb68c7e21bc4e039ab77396cdca7ca0d18eca95
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2613370
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#71956}
This implements the spec change in
https://github.com/tc39/ecma262/pull/2164
Making TA elements configurable has interaction with delete. While
the elements are configurable, they are only "deletable" via detaching
the underlying ArrayBuffer, not via `delete`. That is, `delete ta[idx]`
for an in-bounds `idx` still returns false.
Bug: v8:11281
Change-Id: I2e9348a7ec3c3239a92cc35e51b7182423736834
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2605234
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71955}
The flag was enabled by default in M85, it is time to remove it.
R=clemensb@chromium.org
Bug: v8:7741, chromium:1160677
Change-Id: Ic4a9490efa645a7466cb844484169ab262f0df38
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2610965
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71945}
Due to the transition to the jobs API, WebAssembly compilation was using
background threads, even when --single-threaded and therefore
--wasm-num-compilation-tasks=0 was used. With this CL, the compilation
job is started with a maximum concurrency of 0 when
--wasm-num-compilation-tasks=0. To ensure compilation progress in
asynchronous compilation, the main thread waits for baseline compilation
to finish right after initializing all compilation units, and thereby
participates in the compilation.
R=clemensb@chromium.org
Bug: v8:11279
Change-Id: I85f93f82c00cdbd6afd46110599089a052101a00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2599546
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71944}
This adds a regression test for a bug in lowering load transforms.
This test will fail if 0efa3fd97e is
reverted.
Bug: chromium:1124885
Change-Id: I31b714d4565c4fff730c1274af8059031cb1e1b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2610508
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71919}
The tests were failing in official release builds, because those drop
the fatal error message and always print "ignored" instead.
R=ecmziegler@chromium.org
Bug: v8:11251
Change-Id: I40512ca308337cf070ecb6a206dc4a5323d67415
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595445
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71914}
The wasm-scope-info-liftoff.js and wasm-set-breakpoint-liftoff.js tests
were originally testing the Liftoff path (when we still had the Wasm
interpreter), and have received some updates along the way. Nowadays the
interpreter is going and the non-liftoff versions of these tests don't
provide any additional test coverage, but are merely a slightly less
updated version of the liftoff test.
Bug: chromium:1162229
Change-Id: Ifc9933d47f33674a83b99425ef9d0e4bc5550323
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2609415
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71909}
Consistently use InspectorTest.runAsyncTestSuite() in wasm inspector
tests to make tests easier to debug (they'll fail instead of timing
out in case of errors).
Bug: chromium:1162229, chromium:1071432
Change-Id: I7aada196f9e34071aa1bb059bb45f85f75226060
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2609414
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71908}
In https://crrev.com/c/2591859 we changed the way we generate code for
v128.select, which assumes that all inputs are registers. We did not
update the instruction selector with this new constraint.
Fixed: chromium:1161954
Bug: v8:11282
Change-Id: I5fc9a0315873a3e795078997d87aa92d4c8bddfe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2603764
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71904}
.. to verify that the trampoline_pc has been set.
Bug: chromium:1161357
Change-Id: If7e1a13cff9919e2e8a65c095d80dfcef2dc05cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606333
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71896}
The "imports" and "exports" that were exposed on WebAssembly frames via
Debug-Evaluate aren't useful for the DWARF C/C++ extension (and likely
not for any other language extension), since they only expose static
information that's easily available (upfront) by reading the Wasm wire
bytes.
In fact, there are already standardized functions in the WebAssembly
specification, namely `WebAssembly.Module.imports(module)` and
`WebAssembly.Module.exports(module)`, which yield static information
about the imports and exports of a Wasm module.
So instead of exposing special, non-standard "imports" and "exports", we
now instead expose both the "instance" and the "module" objects via both
the Debug Proxy and the Scope view, and also add internal [[Exports]]
and [[Imports]] properties to WasmModuleObject, which under the hood use
the standard methods mentioned above.
Fixed: chromium:1162069
Bug: chromium:1071432, chromium:1083146
Screenshot: https://imgur.com/lcaW2jL.png
Doc: https://docs.google.com/document/d/1rqbu0jKTl3q_xCxLnKzkjGXWEsHnJ9aERVhKV9RNDgE#bookmark=id.925bb2qgou38
Change-Id: Ie27e55bb08ea5f90493c57375bf2b48dfb11a4d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606050
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71893}
For JSArrayBuffer instances (which map to both v8::ArrayBuffer and
v8::SharedArrayBuffer), we add a couple of synthetic views to its
ValueMirror to make it easy for developers to peak into the contents of
the JSArrayBuffer. These were previously real properties, but that's
just wrong (both intuitively and semantically), and they should instead
be internal properties.
Drive-by-fix: The [[IsDetached]] internal property should only be shown
on actually detached JSArrayBuffer's to reduce visual clutter. And for
detached JSArrayBuffers creating views on them throws TypeErrors per
specification, so we shouldn't attempt to display views on them.
Bug: v8:9308, chromium:1162229
Change-Id: Ia006de7873ca4b27aae7d00d46e1b69d2e326449
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606047
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71892}
This fix the following instructions:
kExprI32SConvertF64 in mips32, RecordSpillsInSafepoint in mips32 and mips64.
Change-Id: I762fe4a7afa06fa8470fb0de932756a145d66099
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2605905
Auto-Submit: Liu yu <liuyu@loongson.cn>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71889}
In AVX, it is better to use the appropriate integer or floating point
moves depending on which instructions produce/consume these moves, since
there can be a delay moving from integer to floating point domain. On
SSE systems, it is less important, and we can move movaps/movups which
is 1 byte shorter than movdqa/movdqu.
This patch cleans up a couple of places, and defines macro-assembler
functions Movdqa, Movdqu, Movapd, to call into movaps/movups when AVX is
not supported.
Change-Id: Iba6c54e218875f1a70f61792978d7b3f69edfb4b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2599843
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71884}
With https://crrev.com/c/2087396 we introduced a new CDP method
`Debugger.executeWasmEvaluator()`, which we originally intended
to use as the foundation for Debug-Evaluate on Wasm frames.
However in the process of prototyping we learned that it is too
costly and too inefficient to use WebAssembly modules here, and
we switched to regular Debug-Evaluate with JavaScript instead
(with a special debug proxy exposed that allows JavaScript to
peak into the Wasm frame), since JavaScript is better suited
for short-lived / short-running snippets and we don't need
clang and wasm-ld then to generate these snippets.
The JavaScript exposed debug proxy (as described in [1]) not
only enables more powerful and flexible Debug-Evaluate for the
DWARF C/C++ extension, but also serves as the basis for various
aspects of the Basic Wasm Developer Experience.
In order to pay down technical debt and to keep the maintenance
overhead low, we should remove the initial prototype now, also
to ensure that we don't accidentally attract other users of CDP
to rely on this unsupported API (despite it being marked as
"experimental").
[1]: https://docs.google.com/document/d/1VZOJrU2VsqOZe3IUzbwQWQQSZwgGySsm5119Ust1gUA
Fixed: chromium:1162062
Bug: chromium:1020120, chromium:1068571, chromium:1127914
Change-Id: I6dba8c906a8675ce6c29a52e3c32bb6626a27247
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2605186
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71882}
If we attempt to pause, we'd check whether frames are framework code
which we pattern match with a regexp. That could cause re-entering
regexp, which is not allowed.
Fixed: chromium:1125934
Change-Id: I3b52b202a5570f7929def39176cfe5e52be3dfd5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2602948
Commit-Queue: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71876}
JavaScript scopes are reported from inner-most to outer-most, while
previously we would report WebAssembly frames from outer-most to
inner-most. This is quite confusing for developers, and also doesn't
really make sense, so this CL fixes this inconsistency.
Bug: chromium:1071432
Change-Id: I6a4742f13b9a0df33e50c6fcd40992873996aaf5
Fixed: chromium:1159309
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2602947
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71875}
This adds ExecutionContextDescription.uniqueId for a system-unique
way to identify an execution context and supports it in Runtime.evaluate.
This allows a client to avoid accidentally executing an expression
in a context different from that originally intended if a navigation
occurs while Runtime.evaluate is in flight.
Design doc: https://docs.google.com/document/d/1vGVWvKP9FTTX6kimcUJR_PAfVgDeIzXXITFpl0SyghQ
Bug: v8:11268, chromium:1101897
Change-Id: I4c6bec562ffc85312559316f639d641780144039
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2594538
Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71869}
Detect AVX2 support and use vpbroadcastb or vpbroadcastw.
No new assembler helpers required because we are only emitting the
VEX-128 versions of these instructions.
Bug: v8:11258
Change-Id: Ic50178daa6fc8fe767dfc788e61e67538066bdea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596582
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71866}
When a 8x16 shuffle matches a 32x4 shuffle (every group of 4 indices are
consecutive), and the first 2 indices are in the range [0-3], and the
other 2 indices are in the range [4-7], then we can match it to a
shufps. E.g. [0,2,4,6], [1,3,5,7]. These shuffles are commonly used to
extract odd/even floats.
Change-Id: I031fe44f71a13bbc72115c22b02a5eaaf29d3794
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596579
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71860}
As a first step towards freeing CodeEntry objects that are neither still
referenced by JS or stored in a profile, enable freeing of refcounted
strings by CodeEntry instances. For now, this leaves behaviour unchanged
until we receive CodeEntry destruction events.
Bug: v8:11054
Change-Id: Iabd05aa730343cd1a879ff5b04326f23e68aa948
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2590604
Commit-Queue: Andrew Comminos <acomminos@fb.com>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71858}
