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}
Change-Id: Ia25cc038c09a900d906bd8e724244418a5708675
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2610511
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71963}
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}
This is a reland of 2d5f981a04
The fix is in liftoff-assembler-x64, to call S128Select with dst
as the mask when AVX is not supported and dst != mask.
Original change's description:
> [wasm-simd][liftoff][x64] Move v128.select into macro-assembler
>
> This allows us to reuse this optimized code sequence in Liftoff.
>
> We can't do the same thing in IA32 yet, there is no kScratchDoubleReg
> defined in the macro-assembler-ia32.cc, it is defined in code-generator-ia32
> as xmm0 but I'm not sure if it is safe to just use that in the macro assembler.
>
> Change-Id: I6c761857c49d2518fbc82cd0796c62fc86665cb5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596581
> 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@{#71915}
Change-Id: Ib96ce0e1d5762f6513ef87f240b25ef3ae59441f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2612324
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71961}
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}
Instead of always using v8::ConstructorBehavior::kAllow and then
immediately calling FunctionTemplate::RemovePrototype, this patch
changes FunctionTemplateInfo::New to pass in the correct value for
v8::ConstructorBehavior.
There is no change in observable behavior with this patch.
Bug: v8:11288
Change-Id: Ia7dd8a0c1ac6d081bc0d9b73d7c7cb4164638144
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2612990
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71957}
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}
When bytecode gets flushed from SFI and we generate the bytecode again,
we expect that the generated bytecode is exactly the same as the earlier
bytecode. We reuse the same closure feedback cell array allocated
earlier and hence it is required that number of closure feedback slots
remain the same. This cl just adds a CHECK for that, so we fail when
this is not the case.
Bug: chromium:1147917
Change-Id: I4b09ce3f741bc15c3b141b1fe057a667496c925d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2613037
Commit-Queue: Mythri Alle <mythria@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71954}
When --single-threaded is set, and therefore
--wasm-num-compilation-tasks=0, the compilation job for JSToWasm
wrapper compilation is executed directly instead of first posted and
then joined on the main thread.
R=clemensb@chromium.org
Bug: v8:11279
Change-Id: Idba150cf9d32a6a6b12b322f46c0ba36fd220c5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595441
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71953}
P9 has vector insert and extract instructions which can be
used instead of doing memory load/stores.
Change-Id: Ida8dd6c43441f1a5c04406688f8c86a656dc63eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2613027
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#71951}
Note that the `wasm` type and it's subtypes will be removed soon, so we
don't need to synchronize them.
Fixed: chromium:1162930
Change-Id: I8549679cbe53a1e50e98acedf8547dc09c20ad27
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2613036
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@{#71950}
Prepare the system analyzer to be able to select events related to a
a single code log entry.
- Rename source-panel to script-script panel
- Update main index.css to support selects in the panel selection
header
Bug: v8:10644
Change-Id: Ie8dd1839294687cb9e25995bcb7ef246a7d7f48d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2604707
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71948}
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}
Bug: chromium:1161357
Change-Id: I7a4237fd682689742e67cd1f35e6ef91815386e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2611249
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71943}
No need to return anything here as the return value doesn't need to be
checked. This is a purely side effecting function.
Change-Id: I5484086e289d9f5104a17c93950c25f656d5a44b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2605185
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71940}
The FastTemplateCache gets filled with undefiend when created and then
with holes when it grows causing a mismatch.
This hasn't been a problem so far as the FastTemplateCache is always
initialized to the max size but it could cause problems in the future
if this is changed.
Bug: v8:11289
Change-Id: I8dabce101b25d9f0057183c88f507873d973f2a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2608472
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71939}
Loop analysis never visited nodes whose marks happened to not change
when visiting their outputs in backwards propagation. This CL ensures
that each reachable node is visited at least once.
Change-Id: I70cd73737c0abe8151d5e23bc50525599fa3ea6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2581538
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71938}
Rolling v8/build: dc0b854..e4c5e3e
Rolling v8/third_party/aemu-linux-x64: eNKL3iFnDydKoCyqA9rVhylE7ud5a_9wRt0b0HFtLvIC..LanwSa4qZkDJRxK05Ym26IRV6bksO-9CZE-3jrgCbV8C
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/3f5c581..ae206b8
Rolling v8/third_party/depot_tools: 81098e5..b34cd6d
Rolling v8/third_party/googletest/src: 4fe0180..1b0cdaa
Rolling v8/tools/clang: 1283870..e8d041dTBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com
Change-Id: I62cfd8a388b9980b458ff001e5604d704b0332bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2614110
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#71934}
movaps is 1 byte shorter than movapd and is equivalent.
Fixed: v8:11116
Change-Id: Ibf32ad5428ac3d55d055f8725fbf2e96433fb97a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2601878
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71933}
Port bbb1b3457b
Original Commit Message:
Adds support for emitting data with a reloc info to enable support
for HeapObjects for immediate deopt args, required by dynamic check maps.
In order to do this, a new DATA_EMBEDDED_OBJECT relocinfo type is added.
This represents a raw object inserted into the instruction stream. For
x64/ia32 it is treated the same as FULL_EMBEDDED_OBJECT, but on
Arm/Arm64 this behaves differently since it points directly to the
embedded object pointer rather than to an instruction that loads it.
R=rmcilroy@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=v8:10582
LOG=N
Change-Id: I949acb69ca6f6a377102eb0ac5f44919d4f7d25b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2612930
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#71931}
xxspltib takes in an immediate value of up to 8 bits.
We need to make sure input values are not bigger in size.
Change-Id: I3574028d43752870564e4690b22bf2e87813ab76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2613031
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#71930}
P9 has vector insert instructions which could be used
for splatting 64bit inputs.
Change-Id: I16165271fd70848699430e1f77a1603d1023da49
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2611044
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#71929}
Adds support for emitting data with a reloc info to enable support
for HeapObjects for immediate deopt args, required by dynamic check maps.
In order to do this, a new DATA_EMBEDDED_OBJECT relocinfo type is added.
This represents a raw object inserted into the instruction stream. For
x64/ia32 it is treated the same as FULL_EMBEDDED_OBJECT, but on
Arm/Arm64 this behaves differently since it points directly to the
embedded object pointer rather than to an instruction that loads it.
BUG=v8:10582
Change-Id: I384e88af032b832742447482ae7af5c599097ec1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595295
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71926}
For i64x2.ext_mul and i16x8.ext_mul, we can simply call the
macro-assembler functions.
For i32x4.ext_mul, the macro-assembler requires that dst == src1 if AVX
is not supported, so we add a helper function to do that check, and make
sure dst == src1 before calling into macro-assembler.
This is the same implementation as x64 (https://crrev.com/c/2603765).
Bug: v8:11262
Change-Id: I85ebe3e033903aa1cb6a7a0840f2e93210cce65a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2610506
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71921}
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}
Design doc:
https://docs.google.com/document/d/1xkXj94iExFgLWc_OszTNyNGi523ARaKMWPZTeomhI4U
A lot has changed since the last patchset! I recommend revisiting this
design doc and reading the parts in green. I explain the roadmap for
what changes to expect from ETW instrumentation as well as the
instrumentation of this particular CL.
I'll do my best to answer any further questions anyone has about my
particular instrumentation or ETW in general :)
---
This is the first of a series of changelists to round out ETW
instrumentation for V8.
This changelist represents the most minimal change needed to instrument
ETW in V8. In particular, it:
- defines and registers the ETW provider,
- interacts minimally with the rest of V8, by hooking into the
existing TracingController::AddTraceEvent function,
- is designed with a platform-agnostic layer, so that event tracers
for other platforms can be instrumented in teh future.
Some notes on instrumentation (aka I copied stuff from the design doc):
We make heavy use of the TraceLogging API to log events. It differs from
previous methods of emitting ETW events in that it doesn<E2><80><99>t
require the overhead of a separate manifest file to keep track of
metadata; rather, events using this API are self-descriptive.
Here are the five major steps to instrument the TraceLogging API:
- Forward declare the provider (from provider-win.h)
- Define the provider in a .cc file (from provider-win.cc)
- Register the provider (called from v8.cc).
- Write events (called from libplatform/tracing-controller.cc)
- Unregister the provider (called from v8.cc)
At the base, we have an abstract provider class that encapsulates the
functionality of an event provider. These are things like registering
and unregistering the provider, and the actual event-logging.
The provider class is split into provider-win and provider-mac
(currently not instantiated) classes, with OS-dependent implementations
of the above functions.
In particular, the TraceLogging API is used only in provider-win. It is
here that we forward declare and define the provider, as well as write
ETW events.
Finally, there is a v8-provider class that serves as a top-level API and
is exposed to the rest of V8. It acts as a wrapper for the
platform-specific providers.
The .wprp file is needed so that Windows Performance Recorder knows how
to capture our events.
Some considerations:
- Is TracingController::AddTraceEvent the best place from which to
write my events?
- Is src/libplatform/tracing the best place to put my instrumentation?
- Right now, I fail the preupload because of this, which tells me my
files are probably not in the best location:
You added one or more #includes that violate checkdeps rules.
src\init\v8.cc Illegal include: "src/libplatform/tracing/v8-provider.h"
Because of "-src/libplatform" from src's include_rules.
Change-Id: Id53e4a034c9e526524a17000da0a647a95d93edf
Bug: v8:11043
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2233407
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Sara Tang <sartang@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#71918}
The negative implication from --single-threaded to --liftoff was
introduced because with --single-threaded, no tier-up to TurboFan is
possible, and TurboFan provides faster code and smaller code
This CL removes this implication. The reason is that this implication
does not only define the default compiler for --single-threaded to
TurboFan, and also completely disables the option to use Liftoff
instead. By removing the implication, and embedder who uses
--single-threaded can decide by themselves if they want to use Liftoff
by setting --liftoff, or if they don't want to use Liftoff by setting
--no-liftoff.
R=clemensb@chromium.org
Bug: v8:11279
Change-Id: Ie6e64a42823b87484135364ecb4589cfd188db5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2599548
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71917}
This reverts commit 2d5f981a04.
Reason for revert: Fails on noavx: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20debug/35318
Original change's description:
> [wasm-simd][liftoff][x64] Move v128.select into macro-assembler
>
> This allows us to reuse this optimized code sequence in Liftoff.
>
> We can't do the same thing in IA32 yet, there is no kScratchDoubleReg
> defined in the macro-assembler-ia32.cc, it is defined in code-generator-ia32
> as xmm0 but I'm not sure if it is safe to just use that in the macro assembler.
>
> Change-Id: I6c761857c49d2518fbc82cd0796c62fc86665cb5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596581
> 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@{#71915}
TBR=bbudge@chromium.org,clemensb@chromium.org,zhin@chromium.org
Change-Id: I2aacee02c89a16516a9cd6686d8cc6180362f78e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2610730
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71916}
This allows us to reuse this optimized code sequence in Liftoff.
We can't do the same thing in IA32 yet, there is no kScratchDoubleReg
defined in the macro-assembler-ia32.cc, it is defined in code-generator-ia32
as xmm0 but I'm not sure if it is safe to just use that in the macro assembler.
Change-Id: I6c761857c49d2518fbc82cd0796c62fc86665cb5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2596581
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@{#71915}
