In the TestTypeOf handler, use the statically known value of the type-of
literal flag to emit the specific type-of check for that type, rather
than going to the general type-of builtin. These checks are very simple,
so we can get away with hand-writing them in the baseline compiler.
Bug: v8:11420
Change-Id: Id9f51042916abaea62f929a2f95cf2c64dc32ee3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2772613
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73520}
Live ranges defined by a constant operand normally don't require a spill
slot since they can just rematerialize the value from the constant. In
the attached issue however, deoptimization adds an explicit slot
requirement for a range that is defined by a constant operand. This case
is not expected in the register allocator and we eventually hit a
DCHECK.
This fix allocates a new stack slot during the MeetRegisterConstraints
and adds the missing gap move.
Drive-by: remove dead method LiveRange::NextSlotPosition.
R=sigurds@chromium.org
CC=nicohartmann@chromium.org
Bug: chromium:1146880
Change-Id: I08fbb890f2f3d9574196989cf3e5ef6232433484
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563689
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73510}
Throwing an object that needs special property lookup currently traps
when we catch it in wasm. We should just return undefined to let the
caller know that this is not a wasm exception object.
Drive-by: use the named {caught_tag} register consistently.
R=clemensb@chromium.org
Bug: chromium:1188825
Change-Id: I8ebd4db756ac7ba04208ab43c7349c28b813fc49
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2767519
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73497}
This brings the WasmModuleBuilder in the mjsunit test suite
up to date wrt. the latest changes of the GC proposal.
Bug: v8:7748
Change-Id: I4e1a3d34a1e83626ab89d2fa0e10ca4aa61d75ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690590
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73496}
If the block is unreachable, the interface is not called and the
{try_info} field is not set. Therefore, check it before accessing it.
R=clemensb@chromium.org
Bug: chromium:1188975
Change-Id: Ic6d7d2b7e26b0448143076e25a89c036216e8618
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2767017
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73480}
When dropping the exception from the stack, we have to
take locals into account when computing the right stack
slot.
Fixed: chromium:1187836
Change-Id: I76acb1e4dc50992524123cc369dea8e51242164c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2764749
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73469}
Processing StateValues into operands is one of the most costly
parts of instruction selection. As it happens, StateValues are
shared by many nodes, and so we are unecessarily reprocessing
the same StateValues multiple times. This CL introduces caching
for the processed StateValues enabling very fast emitting of
operands for subsiquent instructions with the same StateValue.
The hitrate for the cache is higher than 90% on most optimizations.
BUG=v8:9684
Change-Id: I7edcfa1b0d7add16e509f0e2abeda0a8873f5a95
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2756535
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73434}
Note that top-level await is already on-by-default in blink. This flips
the flag in V8 only for other embedders.
Bug: v8:9344
Change-Id: Ic860b22316718b353a0493799fdf95200a71acc1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2746843
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73416}
If a Proxy is passed as argument to d8.test.verifySourcePositions,
unwrap the target function.
Bug: chromium:1186491
Change-Id: Iaacbf800f023121a07035a88745919df68f79217
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2748081
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73398}
This flag enables feedback allocation heuristics to be based on the
function size. The threshold for feedback allocation is set to
12 * bytecode size to roughly mimic the allocation after 12 invocations.
We tried 4 * bytecode size earlier and there were few memory regressions
on real world pages. Speedometer improved by ~1% [1, 2]. This time
trying with a higher factor this time to see if we still have
speedometer improvements without any memory regressions.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=1177124
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=1177241
Change-Id: I39c7d4aaf90b948b07419e4598e2193b8355c067
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752150
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73369}
This is a reland of 80f5dfda01. A condition
in pipeline.cc was inverted, which lead to a CSA verifier error.
Original change's description:
> [no-wasm] Exclude src/wasm from compilation
>
> This is the biggest chunk, including
> - all of src/wasm,
> - torque file for wasm objects,
> - torque file for wasm builtins,
> - wasm builtins,
> - wasm runtime functions,
> - int64 lowering,
> - simd scala lowering,
> - WasmGraphBuilder (TF graph construction for wasm),
> - wasm frame types,
> - wasm interrupts,
> - the JSWasmCall opcode,
> - wasm backing store allocation.
>
> Those components are all recursively entangled, so I found no way to
> split this change up further.
>
> Some includes that were recursively included by wasm headers needed to
> be added explicitly now.
>
> backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
> because it only tests wasm backing stores. This file is excluded from
> no-wasm builds then.
>
> R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
>
> Bug: v8:11238
> Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
> Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73344}
TBR=jgruber@chromium.org
Bug: v8:11238
Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73348}
This reverts commit 80f5dfda01.
Reason for revert: Fails CSA verification: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20verify%20csa/21766/overview
Original change's description:
> [no-wasm] Exclude src/wasm from compilation
>
> This is the biggest chunk, including
> - all of src/wasm,
> - torque file for wasm objects,
> - torque file for wasm builtins,
> - wasm builtins,
> - wasm runtime functions,
> - int64 lowering,
> - simd scala lowering,
> - WasmGraphBuilder (TF graph construction for wasm),
> - wasm frame types,
> - wasm interrupts,
> - the JSWasmCall opcode,
> - wasm backing store allocation.
>
> Those components are all recursively entangled, so I found no way to
> split this change up further.
>
> Some includes that were recursively included by wasm headers needed to
> be added explicitly now.
>
> backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
> because it only tests wasm backing stores. This file is excluded from
> no-wasm builds then.
>
> R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
>
> Bug: v8:11238
> Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
> Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73344}
Bug: v8:11238
Change-Id: I93672002c1faa36bb0bb5b4a9cc2032ee2ccd814
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752866
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#73346}
This is the biggest chunk, including
- all of src/wasm,
- torque file for wasm objects,
- torque file for wasm builtins,
- wasm builtins,
- wasm runtime functions,
- int64 lowering,
- simd scala lowering,
- WasmGraphBuilder (TF graph construction for wasm),
- wasm frame types,
- wasm interrupts,
- the JSWasmCall opcode,
- wasm backing store allocation.
Those components are all recursively entangled, so I found no way to
split this change up further.
Some includes that were recursively included by wasm headers needed to
be added explicitly now.
backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
because it only tests wasm backing stores. This file is excluded from
no-wasm builds then.
R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
Bug: v8:11238
Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73344}
OptimizedFrame::Summarize is used by debugger features etc
to inspect the frame of an optimized function (and the virtual frames
of functions that got inlined). It could end up materializing a JSArray
with the same backing store as one that would later get left-trimmed,
resulting in a dangling elements pointer. This CL fixes that by creating
a fresh copy of the elements store instead.
Bug: chromium:1182647
Change-Id: Iaf329464520a927b0ba33166cad2524d3752c450
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2748593
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73330}
This is done with a script that does something like:
files=$(ag 'v\d\d?x\d\d?[._]?all_?true' -l)
sed -i 's/V\(8x16\|16x8\|32x4\|64x2\)\([._]\?\)\([aA]ll_\?[tT]rue\)/I\1\2\3/g' $(files)
sed -i 's/v\(8x16\|16x8\|32x4\|64x2\)\([._]\?\)\([aA]ll_\?[tT]rue\)/i\1\2\3/g' $(files)
And manual fixups in test-run-wasm-simd.cc and wasm-opcodes-inl.h.
Bug: v8:10946
Change-Id: Ib5dad388dd6dd9cd0fb575ad961dffc189a2e6ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2740488
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73309}
They were using a fixed offset of pc+2, but since the instructions can
be multiple bytes long (leb128 encoded), it should be using *len.
Drive-by fix to add missing instructions to wasm-module-builder.js.
Bug: chromium:1185323,chromium:1185492
Change-Id: I12f396cc2969ecc284aba35b94b1bc5640f12277
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2745977
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73308}
Push the caught exception on the value stack, so that we can access it
from an inner catch block and rethrow it.
R=clemensb@chromium.org
Bug: v8:11453
Change-Id: Ibc5e653a07c3e4436e252c001b53bc2d3402abc9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739974
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73295}
With the value stack refactoring in 1b5c7e15 / r73193, the
combination of helper functions called by PeekArgs() ended
up checking the stack height repeatedly. This CL avoids that
by introducing a ValidateArgType() helper that does not check
stack height.
Bonus: achieve a small speedup by special-casing two of the
most common opcodes in the decoder's main dispatcher.
Fixed: chromium:1185082
Change-Id: I6d51aca844ef9377d203147f74ff8137e12a23e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2745341
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73294}
This is a reland of a8b61ef521
The main reason for the revert was not related to this CL and was fixed
with https://crrev.com/c/2739646
In addition debug output in d8.test.verifySourcePositions was removed
due to TSAN complaints.
Original change's description:
> [sparkplug] Change bytecode offset mapping and introduce iterator.
>
> Previously, we recorded pairs of (bytecode offset, sparkplug pc) to
> create a mapping of bytecode offset <-> sparkplug pc.
> These pairs were only recorded after builtin/runtime calls.
> In preparation for deoptimizing to Sparkplug, we need a more precise
> mapping.
> With this CL, we record positions for every bytecode. Instead of storing
> a pair of (bytecode offset, sparkplug pc), we store only the pc,
> calculating the bytecode offset from the index in the mapping table.
> For easier use an iterator to access the mapping is introduced.
>
> Drive-by: Reduce sampling interval in cpu-profiler cctest to get rid of
flaky failures.
>
> Bug: v8:11420, v8:11429
> Change-Id: I36a9171f43a574eb67880cbca6cf9ff7ab291e60
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720189
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Auto-Submit: Patrick Thier <pthier@chromium.org>
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73186}
>
> Change-Id: I9ab4cb60da002ef130f8a21ad10ba69e2826a7b6
Change-Id: I9ab4cb60da002ef130f8a21ad10ba69e2826a7b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2745335
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73293}
Instead of using addresses of prototype and constructor (which can be
movedby GC) when computing the hash of a Map, we use the addresses of the
prototype map (which won't be compacted).
The prototype map is in a 1:1 relation with the prototype.
In addition the prototype points to the constructor in most cases.
Bug: v8:11519
Change-Id: Ibc47e5870955d7721509be07fae7719a93da9a26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739646
Commit-Queue: Patrick Thier <pthier@chromium.org>
Auto-Submit: Patrick Thier <pthier@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73286}
... where TF doesn't see that the property is deleted and re-added.
Bug: chromium:1161847
Change-Id: I599a25fa8d29154b5bfede45f6655a1eac44a0f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739592
Auto-Submit: Georg Neis <neis@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73280}
- Adds some missing types, to appease the fuzzers.
Bug: chromium:1185464
Change-Id: I08c4ebe5f4ae0d036da9819b805aeac93be384fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742017
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73279}
Before dropping a value we should validate that there is indeed a value
on the stack.
R=jkummerow@chromium.org
Bug: chromium:1184964
Change-Id: Iec3ac061df2545717749e664b10c383765d67c9d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739588
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73263}
The recent change crrev.com/c/2712755 got a bounds check wrong,
causing an invalid use of the lookup iterator.
Bug: v8:1185072
Change-Id: I3138d266cb4b2482dcb5078fb025bbfc43dd2940
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742196
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73250}
Bump wasm-spec-tests version since the opcodes have also changed.
Also add missing opcodes to wasm-module-builder.js.
Bug: v8:6020
Change-Id: I60dcf1b300a5278aab5e1814c9ebf4ee85c60053
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2728432
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73233}
0x7b is the encoding for SIMD v128 types, so it will become valid when
we turn SIMD on by default. Use kWasmStmt (0x40) instead, it is not a
valid in the function signature position (which requires a value type).
Bug: v8:11511
Change-Id: Ife152e81d831a059a0122f9255897d97b5dc4fc9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739054
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73232}
... to different attributes or different property kind.
Bug: chromium:1161847, v8:9233
Change-Id: I5a6e1e012c6afcf09ed9da6bbf9f33c1007c3d99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727272
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73220}
This adds the possibility to define non-nullable function tables of heap
types kFunc and user-defined functions. When such table is defined, it
is obligatory to provide an initializer expression after its limits.
Currently, this can only be a function reference.
Changes:
- Change WasmTableObject::raw_type to encode the whole entry type.
- Restructure call_indirect to load the signature only if needed, and
do null checks only if needed.
- Add the requirement to provide an initializer expression for
non-nullable tables in module-decoder.
- Rename "global initializer" -> "initializer expression" everywhere.
- Add table initialization in module-instantiate.
- Edit both the C++ and JS WasmModuleBuilder.
- Add and slightly improve tests.
- Format wasm-module-builder.js.
Bug: v8:9495
Change-Id: I7453ee7d567afd5b5fe48a4f1653513787cfe99a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2732673
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73215}
This reverts commit a8b61ef521.
Reason for revert: Looks like it breaks GC stress bot - https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/35880/overview
Original change's description:
> [sparkplug] Change bytecode offset mapping and introduce iterator.
>
> Previously, we recorded pairs of (bytecode offset, sparkplug pc) to
> create a mapping of bytecode offset <-> sparkplug pc.
> These pairs were only recorded after builtin/runtime calls.
> In preparation for deoptimizing to Sparkplug, we need a more precise
> mapping.
> With this CL, we record positions for every bytecode. Instead of storing
> a pair of (bytecode offset, sparkplug pc), we store only the pc,
> calculating the bytecode offset from the index in the mapping table.
> For easier use an iterator to access the mapping is introduced.
>
> Drive-by: Reduce sampling interval in cpu-profiler cctest to get rid of
> flaky failures.
>
> Bug: v8:11420, v8:11429
> Change-Id: I36a9171f43a574eb67880cbca6cf9ff7ab291e60
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720189
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Auto-Submit: Patrick Thier <pthier@chromium.org>
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73186}
Bug: v8:11420
Bug: v8:11429
Change-Id: Ie71e7ce234e7b9ab9a2ec99a983e9900f35baa44
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2735397
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#73187}
Previously, we recorded pairs of (bytecode offset, sparkplug pc) to
create a mapping of bytecode offset <-> sparkplug pc.
These pairs were only recorded after builtin/runtime calls.
In preparation for deoptimizing to Sparkplug, we need a more precise
mapping.
With this CL, we record positions for every bytecode. Instead of storing
a pair of (bytecode offset, sparkplug pc), we store only the pc,
calculating the bytecode offset from the index in the mapping table.
For easier use an iterator to access the mapping is introduced.
Drive-by: Reduce sampling interval in cpu-profiler cctest to get rid of
flaky failures.
Bug: v8:11420, v8:11429
Change-Id: I36a9171f43a574eb67880cbca6cf9ff7ab291e60
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720189
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Patrick Thier <pthier@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73186}
Tail calls are connected to the end of the graph, so technically they
also constitute loop exits.
Additional Changes:
- In DoReturnCall, change the argument {Node* index_node} into
{Value index_or_caller_value}.
- Rename StackValueVector -> ValueVector.
- Add a test that reveals the bug.
Bug: chromium:1183622, v8:11298
Change-Id: I58f7877f2d03e94f6a281e566829897c3000b890
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727503
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73135}
For adding stack checks in optimized code, we compute a conservative
estimate of the frame size in the case of a deoptimization. Earlier we
included the size of arguments adaptor frames used when actual arguments
didn't match formal parameter count. Though we don't have an explicit
adaptor frame, we should still include the size of these additional
arguments when computing the frame size.
Bug: chromium:1181240
Change-Id: Ib977c5492bb824762fe62aac5e4ffb1c2c233b86
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2723252
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73094}
Fixes a problem with the inlining of JS-to-Wasm call wrappers into a
surrounding exception handler and re-enables this case.
Bug: v8:11092
Change-Id: I4937838c2b4a199e21f5ac90bee5b8e8de2470be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2678341
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73086}
When calling new WebAssembly.Table, the returned error message refers
accidentally to the WebAssembly.Module() constructor.
There will be a corresponding Chromium CL fixing expected error messages
in WPTs.
R=ahaas@chromium.org
Bug: v8:11356
Change-Id: I57f5e071d5c542615523345283d7c3613fb7a616
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2663155
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72998}
The flag should not be set after an exception is thrown in a runtime
function. The unwinder still runs after the destructor, and should take
care of setting the flag depending on the catching frame.
R=ahaas@chromium.org,jkummerow@chromium.org
Bug: chromium:1180690
Change-Id: I0013c90f759a5145309f6e08d61ed36aeecbac63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2713103
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72972}
After the runtime call for dynamic tiering, the instance cache is
invalidated. This was assumed to be done in {SpillAllRegisters}, but the
instance is still being accessed after that call, so the instance cache
register might still be set after the runtime call.
R=ahaas@chromium.org
Bug: chromium:1179065
Change-Id: I375e7c388e5a74789050e374db50d21c2efe27e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2714544
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72958}
.. which can return Undefined if reading out of bounds, so the return
type is ObjectRef and not StringRef (if we had torque-like union types
it'd be StringRef|OddballRef). Also change the function name to
GetCharAsStringOrUndefined.
Bug: v8:7790,chromium:1181246
Change-Id: Icf9e8fd03d11c3936e87a509b9117e547972d283
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712965
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72952}
Also fixes existing tests which were asserting the wrong behavior (that
setting writable=false won't have an effect).
The bug was introduced by https://chromium-review.googlesource.com/c/v8/v8/+/1442640 .
Bug: chromium:1158138
Change-Id: I2d85721848eb4e7d530a980a9ecef7f8693bb9a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2691050
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72948}
The v8_enable_webassembly=false configuration will not be a able to run
any wasm code, hence remove the whole asm to wasm translation from the
binary.
In order to skip specific unit tests in that configuration, we move the
definition of the v8_enable_webassembly gn argument from BUILD.gn to
v8.gni, such that it is available in all gn files.
R=ecmziegler@chromium.org, machenbach@chromium.org
Bug: v8:11238
Change-Id: Id4e290df3e42ffd2f05c377bdd3a368871815daf
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712562
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72945}
This moves all tests that construct a wasm module (and load
wasm-module-builder.js) from test/regress to the test/regress/wasm
directory. This will make it easier to skip them all in the
v8_enable_webassembly=false configuration.
R=ahaas@chromium.org
Bug: v8:11238
Change-Id: Ib22b0fb40a58f213182e68b78b34041651c436d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712243
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72942}
The experimental engine struggles to compile this large pattern.
Change-Id: I0abd5c7ed9f6f62b1c18b5c3dc1cb6a25e130c53
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712754
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72941}
This is a reland of 76a2ab06a1
Changes since the original CL:
- Handle unserialized elements (optional result in getter).
- Merge should_access_heap and --turbo-direct-heap-access paths.
- Slightly update the serialized path in GetOwnCowElement.
- Fix the cctest, add a regression test.
Atomic JSObject::elements/JSArray::length setters are addressed
in this CL: crrev.com/c/2704076.
Original change's description:
> [compiler] Direct heap reads for JSArrayRef
>
> There are two aspects to the non-JSObject parts of JSArrayRef:
>
> - JSArrayRef::length. Relevant only in two spots, 1. when reading
> (immutable) array boilerplates and 2. for GetOwnCowElement.
>
> - JSArrayRef::GetOwnCowElement. May read into a copy-on-write backing
> store. Relies on the invariant that cow backing stores are immutable.
>
> This CL renames the length accessor to length_unsafe to make the
> danger explicit at callsites.
>
> For GetOwnCowElement the refactor is slightly larger, since we now
> need to read into the backing store while keeping full control of
> object reads (e.g. JSArray::length and JSArray::elements_kind). We
> make all reads explicit at the call site by requiring that elements,
> elements kind, and length are passed in as arguments to
> GetOwnCowElement. Inside GetOwnCowElement, consistency between these
> is *not* guaranteed due to concurrency. At runtime, consistency *is*
> guaranteed through the reference-equality check on the elements seen
> during compilation. The actual elements read is implemented in
> ConcurrentLookupIterator::GetOwnCowElement.
>
> Bug: v8:7790
> Change-Id: I9aa169ce4f2b1e2bfe1e9232007669eb7654a995
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695403
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72834}
Bug: v8:7790
Change-Id: I7577ad554992cafff81099a28c34f27db9bd8042
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710431
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72904}
This moves all asm.js tests (tests that use "%IsAsmWasmCode") into a
separate directory. This will make it easier to skip them all in the
v8_enable_webassembly=false configuration.
R=ahaas@chromium.org
Bug: v8:11238
Change-Id: I805f222b7977f5508f7dbee1f1bd61a88ccd34aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710427
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72900}
This CL introduces a test runner flag to detect if webassembly has been
disabled. Since all tests that require wasm are alrady skipped in
lite mode, we introduce a has_webassembly flag for the test runner which
checks for v8_enable_webassembly=true and v8_enable_lite_mode=false.
As a drive-by, we also do not set the V8_ENABLE_WEBASSEMBLY
preprocessor flag if lite mode is enabled.
The status files are updated by splitting wasm tests from the
"lite_mode" section and checking for "not has_webassembly" instead.
Note that the v8_enable_webassembly=false configuration is not tested
on any bot currently, but I will make sure that all tests keep passing
on further changes in this configuration.
R=machenbach@chromium.org
Bug: v8:11238
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Change-Id: I1841eb1f1633cb47e0c079f4a4a4d769ca3a9cbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710425
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72898}
We always built a new Phi node for the delegate merge, which is
incorrect when the target block's exception is already a Phi. Use
CreateOrMergeIntoPhi instead.
R=clemensb@chromium.org
Bug: v8:11472
Change-Id: I8af3ab07d536ddfe247ace04cc844207d32adb99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707167
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72874}
This is the first part of exception handling support in Liftoff. For
now, the only supported instruction is throw, and only with empty
payload or only i32 values.
R=thibaudm@chromium.org
Bug: v8:11453
Change-Id: I9fdf1328ef46655674a05186fb93216518886d03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704659
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72871}
In {MergeFullStackWith}, we were accidentally looking at the cached
instance in the current {cache_state_} instead of the state passed as
{source}. This could lead to missing reload of the instance after a
conditional branch.
R=thibaudm@chromium.org
Bug: chromium:1179182
Change-Id: Ida3c06491f7973a183c43745159abbf6aa8a058b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704081
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72864}
This is a reland of cf93071c91
Original change's description:
> [interpreter] Short Star bytecode
>
> Design doc:
> https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
>
> This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
> that we can use a single byte to represent the common operation of
> storing to a low-numbered register. This generally reduces the quantity
> of bytecode generated on web sites by 8-9%.
>
> In order to not degrade speed, a couple of other changes are required:
>
> The existing lookahead logic to check for Star after certain other
> bytecode handlers is updated to check for these new short Star codes
> instead. Furthermore, that lookahead logic is updated to contain its own
> copy of the dispatch jump rather than merging control flow with the
> lookahead-failed case, to improve branch prediction.
>
> A bunch of constants use bytecode size in bytes as a proxy for the size
> or complexity of a function, and are adjusted downward proportionally to
> the decrease in generated bytecode size.
>
> Other small drive-by fix: update generate-bytecode-expectations to emit
> \n instead of \r\n on Windows.
>
> Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72773}
Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72821}
Move the CompileWithBaseline interface to the Compiler class, as
CompileBaseline, which will do the additional work of pre-compiling
to bytecode, ensuring there is a feedback vector, and setting the
code on the function closure.
As a drive-by, fix v8_enable_trace_unoptimized to have a blank default
value, so that v8_enable_trace_ignition/v8_enable_trace_baseline_exec
can set it.
Bug: v8:11420, v8:11429
Change-Id: If715161de71f7d9300f3fdcbb50cc678b1fcdfdf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697352
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72819}
Pinned registers were not considered correctly when taking a volatile
register. This CL refactors handling of the pinned registers list by
combining the candidates list and the pinned list early. This avoid
additional parameters on some functions and might save some redundant
masking.
As a side effect, it also fixes the DCHECK error on arm.
R=ahaas@chromium.org
Bug: chromium:1179025
Change-Id: Ib9193b209c5741ea97fd1d0dffeeb9e824639439
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2699254
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72812}
The expected exception in this regression test is thrown due to a
limitation in the IrRegExp engine.
The experimental engine is unaffected and won't throw.
Bug: v8:11363
Change-Id: If37d86f5d4494b40c47ecc5e5bc4f86fda30389c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2699251
Auto-Submit: 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@{#72806}
Implicitly rethrow the exception when we reach the end of a
try..unwind..end. Also make it a validation error to rethrow
an exception caught by an unwind block.
R=clemensb@chromium.org
Bug: v8:8091
Change-Id: Ia149d2e81b1fbfa9209047b35ff0c9fedc1b8895
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696662
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72785}
The origin trial for WebAssembly Threads is over for quite some time,
WebAssembly Threads are enabled by default. The API can therefore be
removed now.
Bug: v8:11384
Change-Id: I3dd65ff63c1ed31d39a76e5aea08b950ef420f54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690598
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72766}
Changes:
- In graph-builder-interface.cc, move loop exit utilities in the private
section.
- In the same functions, remove SsaEnv argument. Always use ssa_env_
instead.
- Introduce TerminateThrow, which introduces loop exits before inserting
a throw node.
- Introduce loop exits in the exception handling opcodes.
- Introduce control_depth_of_current_catch() helper.
- Drive-by: Add an optional missing 'break' in DoReturnCall.
- Add some tests, improve test flags in loop-unrolling.js test file.
Bug: v8:11298
Change-Id: I613352023e3e1c72a83cd389d98574758655abee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692820
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72765}
- Baseline is to be consider non-optimized code, so for consistency we rename these functions to DiscardBaselineCode.
- Move to debug/, since discarding baseline code is only used by the debugger.
- %DeoptimizeNow and %DeoptimizeFunction are not to be used to tier down from Sparkplug to Ignition
Change-Id: I050607d4d6978907c589e54c57e940979b0a9a15
Bug: v8:11429
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692699
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72732}
Add a .status file variable for the "v8_control_flow_integrity" gn arg,
and disable baseline tests for now in that configuration.
No-Tree-Checks: true
No-Try: true
Bug: v8:11439
Change-Id: I7274a168893cfd6619ce98fdd14a692217fd56c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692206
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72698}
This reverts commit 87df0b7ecc (thus
relands 42cd9eb78d), with fixes for
the discovered issues.
Original change's description:
> Revert "[compiler] Directly read PropertyCells"
>
> This reverts commit 42cd9eb78d.
>
> Reason for revert: Clusterfuzz issues, e.g.
> https://bugs.chromium.org/p/chromium/issues/detail?id=1176318
>
> Original change's description:
> > [compiler] Directly read PropertyCells
> >
> > Main changes:
> >
> > - Introduce a new broker data kind kBackgroundSerialized for objects
> > that can be serialized in the background (when direct reads are on).
> > (I'm planning to remove kPossiblyBackgroundSerialized in a followup,
> > in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
> > - Make PropertyCell use that new kind.
> > - Introduce a bottleneck in runtime code for changes to PropertyCells
> > and make sure that a certain protocol is followed that allows
> > concurrent reads from the background thread.
> > - Improve interface of PropertyCell in various ways.
> >
> > Bug: v8:7790
> > Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> > Commit-Queue: Georg Neis <neis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#72586}
>
> TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org
>
> Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180
> Bug: v8:7790
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72619}
Bug: v8:7790, chromium:1176509, chromium:1176318, chromium:1176504
Change-Id: Icaf285912bb948432a4a2d599cd174f6a5aa296e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685166
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72697}
Currently we sometimes refer to baseline code or the baseline compiler
by its codename (Sparkplug). The codename is fun, but we should be
consistent and call things by one name or the other. Following the
pattern of Ignition stuff being called "interpreter", we call Sparkplug
"baseline", and leave the codename only in flags and variants.
Bug: v8:11420
Change-Id: I432e5629518be7c7ad38b6acff024c91d4cfd6d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692186
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72696}
Following up on https://crrev.com/c/2689185, this CL significantly
simplifies the whole implementation of the stack trace capturing.
Before this CL, capturing any stack trace (for the purpose of the API or
Error.stack) would roughly work like this:
1. The CaptureStackTrace() function uses the StackFrameIterator to
walk the system stack. For each native frame it uses the
FrameSummary abstraction to get all (including potentially inlined)
frames. For each of those it appends a record consisting of six
elements to a FrameArray (this holds pointers to the actual
closures and receivers).
2. Afterwards the FrameArray is shrinked to the required size, and a
new FixedArray is allocated, and initialized with new
StackTraceFrame objects where each holds a reference to the
FrameArray, the index of the frame, and an initially uninitialized
StackFrameInfo reference. This new FixedArray is then returned from
CaptureStackTrace() and either stored on a message object or
provided to the API as v8::StackTrace.
The new approach removes a lot of the machinery in between and directly
creates a FixedArray of StackFrameInfo objects in CaptureStackTrace().
These StackFrameInfo objects are directly exposed as v8::StackFrame on
the public API, and they hold the six fields that were previously stored
flat in the FrameArray. This not only avoids a lot of copying around of
data and creation of temporary objects and handles, but most importantly
unifies and simplifies the stack frame function inside StackFrameInfo,
so you no longer need to wonder which function / object might be
responsible for a certain API.
There's still a lot of room for improvement. In particular we currently
don't cache the source position for a given StackFrameInfo (or
globally), but rather recompute it every time. This is still very fast,
significantly faster than the previous approach.
There are some notable (potentially user visible) changes:
- The CallSite#GetPosition() method now consistently returns the
Wasm module relative bytecode offset for all Wasm frames (previously
it'd return the function relative bytecode offset for non-asm.js
Wasm frames).
- The column and line numbers returned from StackFrameInfo methods are
consistently 1-based now, instead of sometimes being 0-based (Wasm)
and sometimes being 1-based (JS and asm.js Wasm). The only
potentially noticable difference is that for
CallSite#GetLineNumber() no longer returns 0 for Wasm frames, but
that was wrong and useless anyways.
- CallSite#GetThis() would sometimes return the_hole, another bug
flushed out by this CL.
The CL also contains some other not noteworthy drive-by-cleanups.
Fixed: chromium:1057211
Bug: chromium:1077657, chromium:1069425, v8:8742
Bug: chromium:1127391, chromium:1098530, chromium:981541
Change-Id: Iff12f6838a4d99080db8dd96bccc14440affc5a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689183
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72694}
Sparkplug is a new baseline, non-optimising second-tier compiler,
designed to fit in the compiler trade-off space between Ignition and
TurboProp/TurboFan.
Design doc:
https://docs.google.com/document/d/13c-xXmFOMcpUQNqo66XWQt3u46TsBjXrHrh4c045l-A/edit?usp=sharing
Bug: v8:11420
Change-Id: Ideb7270db3d6548eedd8337a3f596eb6f8fea6b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667514
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72686}
- Add a no-simd-sse flag to skip SIMD tests on bots with no
hardware support.
Change-Id: I4efdbb5ee39c2e10ea8776a1f1e536ac96823efe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2629465
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72682}
Currently %OptimizeFunctionOnNextCall returns if there is the function
is already optimized. This cl changes this function to allow tiering up
till we reach top tier. That allows us to tier up from Turboprop to
Turbofan using intrinsics. This cl also introduces a runtime-test
function to check if turboprop-as-toptier or turboprop-as-midtier is
enabled.
Bug: chromium:1172797, v8:9684
Change-Id: Idbd99b816d4b93e4e619be5d4ccdfe89fc561a9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2682638
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72668}
V8 implements a fast-path for RegExp.prototype.split which diverges
from the spec: instead of creating a new sticky regexp instance
`splitter` and running it in a loop, we reuse the existing non-sticky
regexp without looping through each character.
This works fine in most cases, but we run into issues when matching at
the very end of the string. According to the spec, matches at the end
of the string are impossible in @@split, but in our fast-path
implementation they can happen.
The obvious fix would be to remove our fast-path but this comes with
high performance costs. The fix implemented in this CL adds a special
flag to `exec` s.t. matches at the end of the string can be treated as
failures. This is only relevant for @@split.
Bug: chromium:1075514
Change-Id: Ifb790ed116793998d7aeb37e307f3f3f764023d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2681950
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72644}
With top-level await, when Evaluate is performed on an already-evaluated
synthetic module, Module::InnerEvaluate returns undefined. This breaks
top-level await's assumption that the returned value is always a
promise.
In order to make SyntheticModule's behavior consistent with
SourceTextModule, the top_level_capability field is moved up to Module
and SyntheticModule::Evaluate places the promise returned from the
host's evaluation steps in that field. Now SourceTextModule and
SyntheticModule can share the same code to handle the case where the
module is either kErrored or kEvaluated, so the code for this
is moved up to Module.
Thus, SyntheticModule is now guaranteed to return the
promise from the evaluation steps even on subsequent Evaluate() calls.
Unfortunately Node hasn't yet updated their EvaluationStepsCallback
to return a Promise, so we can't yet assume that the returned value
is a Promise without breaking Node. So, this change also adds a clause
to check for this condition and create a new resolved Promise if one
was not provided by the callback steps. This could eventually be
removed once Node's callback steps are updated for top-level await.
Change-Id: I2d6ae918abfeba9e3a757838502d4df92946edaa
Bug: v8:11398
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2673794
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72629}
Dropping the gpu:none dimension broadens the choice of Mac bots from
so far only 8-core VMs to also include 4-core and 12-core Mac Minis.
This CL adjusts the shard configs to account for adding
4-core Mac Minis to the choice.
We also skip a test that's slow only on 4-core bots.
No-Try: true
Bug: chromium:1174040,v8:11418
Change-Id: Ic0be0db197341b7b8f88eb30aa284c38b0e69609
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685164
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72623}
This reverts commit 42cd9eb78d.
Reason for revert: Clusterfuzz issues, e.g.
https://bugs.chromium.org/p/chromium/issues/detail?id=1176318
Original change's description:
> [compiler] Directly read PropertyCells
>
> Main changes:
>
> - Introduce a new broker data kind kBackgroundSerialized for objects
> that can be serialized in the background (when direct reads are on).
> (I'm planning to remove kPossiblyBackgroundSerialized in a followup,
> in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
> - Make PropertyCell use that new kind.
> - Introduce a bottleneck in runtime code for changes to PropertyCells
> and make sure that a certain protocol is followed that allows
> concurrent reads from the background thread.
> - Improve interface of PropertyCell in various ways.
>
> Bug: v8:7790
> Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72586}
TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org
Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180
Bug: v8:7790
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72619}
This very large changeset adds support for RISC-V.
Bug: v8:10991
Change-Id: Ic997c94cc12bba6881bc208e66526f423dd0679c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571344
Commit-Queue: Brice Dobry <brice.dobry@futurewei.com>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72598}
The is_awaiting bit on async generators distinguishes waiting on an
await. When the async generator resumes from an await, the is_awaiting
bit is cleared.
It is possible through overriding Promise#constructor that `await`
throws *after* setting is_awaiting. There is an implicit try-catch
around the body of the async generator such that, usually, caught
exceptions would clear the is_awaiting bit. However, the exception
thrown from a monkeypatched Promise#constructor can be caught by script,
and thus never clear the is_awaiting bit.
This CL sets the is_awaiting bit *after* `await` completes, with the
exception of the return resumption. It is not possible to have the
exception thrown by the await in the return resumption be caught by
script.
Bug: chromium:1171667
Change-Id: I0b615617a5c949f03350ab0f06c42920d43b5488
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2659508
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72593}
Turboprop doesn't use optimizations based on field constness to reduce
the number of deoptimizations. While this is safe for loads, for stores
if a different value is stored to a const field we should update the
constness of the field. This is needed so we can safely deopt any other
code that is relying on the constness of the field. Currently, turboprop
doesn't do this. So for now treat stores to constant fields similar to
TurboFan. In future, we may consider adding code to update the field
constness if necessary to reduce the number of deoptimizations.
Bug: chromium:1172797, v8:9684
Change-Id: I1d660457cb5d647e1283a495040a7e452fe1ac7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2673401
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72590}
Main changes:
- Introduce a new broker data kind kBackgroundSerialized for objects
that can be serialized in the background (when direct reads are on).
(I'm planning to remove kPossiblyBackgroundSerialized in a followup,
in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
- Make PropertyCell use that new kind.
- Introduce a bottleneck in runtime code for changes to PropertyCells
and make sure that a certain protocol is followed that allows
concurrent reads from the background thread.
- Improve interface of PropertyCell in various ways.
Bug: v8:7790
Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72586}
This fixes a false positive TSAN report where an object transitions to
a new map in StoreIC. The scenario:
1) Object a transitions from map1 to a newly created map2 in runtime.
The map is installed with a release-store.
2) Object b transitions from map1 to map2 in StoreIC in generated code
that is not visible to TSAN.
3) Concurrent marker visits object b and loads it map with an acquire
load.
Since TSAN does not see the store in step (2) it thinks that the map
loaded in (3) is freshly allocated and is not guarded by a release
store.
Bug: v8:11353
Change-Id: Ifcace9edff987761a4098d3fdfb98c6190f1ee1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2682641
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72578}
In JSStackFrame::GetMethodName() we try to infer a useful method name to
show for the closure to which the stack frame belongs. This is done by
first considering the functions name, and checking if the receiver has a
property with that name and if that property's value is the closure. In
case the function doesn't have a name or the property's value is not the
closure itself, we fall back to a reverse lookup of the closure within
the object (and its prototypes).
This CL speeds up this logic by attacking two problems:
1. The reverse lookup was performed by first using the KeyAccumulator to
extract the names of all enumerable properties, and afterwards using
the LookupIterator on each name, and testing the resulting property
value against the closure. This is fairly slow and creates a lot of
temporary objects and handles. We now look into the descriptor arrays
or dictionary backing stores of the objects directly instead, which
is easily 2-10x faster.
2. For the common case of `o.foo = function() { ... }` the parser already
places an "inferred name" of `o.foo` onto the SharedFunctionInfo,
which we can use as a hint to infer the name of the function instead
of immediately falling back to the expensive reverse lookup.
This repairs the regression reported in http://crbug.com/1069425 and
recovers most of the slowdown reported in http://crbug.com/1077657
(there's still some overhead left from the async stack trace tracking).
Fixed: chromium:1069425
Bug: chromium:1077657
Change-Id: I88d23ccad123906df70c5217e815493106e03ccf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676635
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72545}
This is a reland of 6ada6a90ee
- Fixed a GC issue
https://bugs.chromium.org/p/v8/issues/detail?id=11335:
GC expected all arguments on the stack from code with
CodeKind::TURBOFAN to be tagged objects. This is not the case now with
inlined Wasm calls, and this information can be passed in
SafepointEntry for each call site.
- Disabled JS-to-Wasm inlining for calls inside try/catch.
For more details, see updated doc:
https://docs.google.com/document/d/1mXxYnYN77tK-R1JOVo6tFG3jNpMzfueQN1Zp5h3r9aM/edit#
Bug: v8:11092
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
Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
Change-Id: Ie052634598754feab4ff36d10fd04e008b5227a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649777
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72541}
In the latest spec, catch_all is encoded as 0x05. This is the same
opcode as "else", but they do not conflict because "else" is not valid
in the context of a try block.
The 0x0a opcode now corresponds to the "unwind" instruction, which
currently has the same semantics as "catch_all".
R=clemensb@chromium.org
Bug: v8:11392
Change-Id: Ie9cd06c9a2001a02d8bea5be7a3c016e3a58ee3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2674007
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72531}
For dictionary mode objects, whether or not a property is constant was
not tracked before. This CL makes the required non-Turbofan changes,
guarded behind the new flag V8_DICT_PROPERTY_CONST_TRACKING.
In addition, prototypes are not converted to fast mode objects if this
flags is enabled.
Bug: v8:11247
Change-Id: Ia5942733239a97560b6efc015f0e25a35fea3d7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2566757
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72524}
There is a bug in the top-level await spec draft such that async
strongly connected components are not always evaluated before their
depending modules.
See https://github.com/tc39/proposal-top-level-await/pull/161 for full
discussion and spec fix.
Bug: v8:11376
Change-Id: I88bf06afb2e9a5d8d0b757de8276f1d1242a875e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667772
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72508}
When constant-folding the test based on static types in the function
body decoder, we have to ensure Liftoff's value stack is properly
updated.
Fixed: chromium:1172912
Change-Id: I618992608882b850a8a4bce0b267ce456e4c2a40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2664447
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72482}
Optional chain checks check if the object is null or undefined and
if it is we don't perform the load but just load accumulator with
undefined. For calls the value of the accumulator needs to be stored
in the callee register. We were doing this only when the object
isn't null or undefined. This cl fixes it by storing it to callee
always.
Bug: chromium:1171954
Change-Id: I391af18e783486fed70be561027bd8aba97b93cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2665466
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72475}
This is a reland of commit 9c09c227b0.
The fix for gc stress failure is merged: https://crrev.com/c/2656857.
Original change's description:
> 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}
Bug: v8:11331
Change-Id: I82f57b3fe5f0c456472aa7ce404703f34b73d17e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2659511
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@{#72465}
Bug: v8:11353
Change-Id: Iba5b6a2740a5fca55c5f4cee53367fb6413ba3d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2659635
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72441}
