A recent unrelated change caused these tests to get unlucky in
GC stress mode. Their "assertOptimized" expectations rely on
certain type feedback data not getting flushed at the wrong time.
Bug: v8:10846
Change-Id: I86d0b0c049539e4a69aa764cc6ec92465ca12beb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381458
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69617}
With conservative stack scanning enabled, a snapshot of the call stack
upon entry to GC will be used to determine part of the root-set. When
the collector walks the stack, it looks at each value and determines
whether it could be a potential on-heap object pointer. However, unlike
with Handles, these on-stack pointers aren't guaranteed to point to the
start of the object: the compiler may decide hide these pointers, and
create interior pointers in C++ frames which the GC doesn't know about.
The solution to this is to include an object start bitmap in the header
of each page. Each bit in the bitmap represents a word in the page
payload which is set when an object is allocated. This means that when
the collector finds an arbitrary potential pointer into the page, it can
walk backwards through the bitmap until it finds the relevant object's
base pointer. To prevent the bitmap becoming stale after compaction, it
is rebuilt during object sweeping.
This is experimental, and currently only works with inline allocation
disabled, and single generational collection.
Bug: v8:10614
Change-Id: I28ebd9562f58f335f8b3c2d1189cdf39feaa1f52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375195
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69615}
For SIMD instructions that use aligned moves (like movaps or movapd), we
don't have correct memory alignment for SIMD moves yet. Switch to to
movupd.
Bug: v8:9198
Bug: v8:10831
Change-Id: Ic60fba5d08dda9676f6091ce505ac7be54957d00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2380240
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69613}
This allows tests to be skipped on nosse41 builds. For SIMD, nosse41 means
that we need to scalar lower all SIMD instructions, which is not fully
implemented yet.
Bug: v8:10831
Change-Id: I27dd2840b376da672237fed764cbd2491c244627
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2380710
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69612}
Even though we provide a --wasm-max-code-space flag (defaulting to
{kMaxWasmCodeMB}, we still had checks in place that the actual committed
code space is not bigger than that constant.
This CL fixes that by always comparing against the value of the flag.
This will allow us to specify a code space limit which is larger than
the default. This is useful when debugging larger Wasm apps which exceed
the limit, but are not meant to be shipped that way.
Drive-by: Remove a dead use of the {kMaxWasmCodeMemory} constant.
R=ecmziegler@chromium.org
Bug: chromium:1117033, chromium:1114093, chromium:1107649, chromium:1111266
Change-Id: I2684446230a8a6f0a27ad963dd6f36e5764b25e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376810
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69611}
This CL adds a source code panel to display source code positions of
Map/IC log events.
* Clicking file positions on the Ic Panel emits FocusEvent with
SourcePositionLogEvent as entry to highlight code related with the
selected icLogEvent.
* Clicking map details on the Map Panel emits FocusEvent with
SourcePositionLogEvent as entry to highlight code related with the
selected mapLogEvent.
Bug: v8:10644
Change-Id: Icaf3e9e3f7fae485c50ad685f9ec5dc8ac28b3dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2358734
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69610}
Those globals must have type float instead of int to preserve the sign
bit.
R=ahaas@chromium.org
Bug: chromium:1069173
Change-Id: I9769f47f087aaba94a6172118be44f70adeded0c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379861
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69609}
These trace events can be used for triaging profiling issues.
We already have one event if code logging is triggered via an interrupt.
The new events will be emitted if called via the foreground task, or
just directly (e.g. after deserialization).
R=ecmziegler@chromium.org
Change-Id: I67ad9568f38d9a6eb98abf53ce5542ed56170c60
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376811
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69608}
LoadICParameters already has separate fields for receiver and holder,
though, in practice, they were always equal. Moreover, the holder didn't
mean holder, but the lookup start object.
This CL makes parts of the IC layer reusable for cases where they are
not equal, by clarifying whether we're accessing the receiver, the
lookup_start_object, or the holder.
List of changes:
StoreICParameters:
- Detached from LoadICParameters, now they are independent classes.
LoadICParameters:
- Renamed holder to lookup_start_object.
TryProbeStubCache:
- Renamed receiver to lookup_start_object.
LoadIC:
LoadIC_BytecodeHandler:
LoadIC_NoFeedback:
KeyedLoadIC:
KeyedLoadICGeneric:
KeyedLoadICPolymorphicName:
- These won't be reused in the receiver != lookup_start_object case,
so added asserts that receiver == lookup_start_object.
TryMonomorphicCase:
HandlePolymorphicCase:
LoadIC_Noninlined:
GenericElementLoad:
- Renamed receiver_map param to lookup_start_object_map. The callers
either assert receiver == lookup_start_object, or read the map from the
lookup start object.
GenericPropertyLoad:
- Renamed receiver param to lookup_start_object.
- Renamed receiver_map param to lookup_start_object_map. The callers
either assert receiver == lookup_start_object, or read the map from the
lookup start object.
CallGetterIfAccessor:
- Added the holder parameter and used it accordingly.
Bug: v8:9237
Change-Id: I27aca08f58bd66cc9bd1b1baf9f1ff5565d795eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362918
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69606}
This is the first step in a series of CLs. The goal is to make
super property access faster.
Design doc: https://docs.google.com/document/d/1b_wgtExmJDLb8206jpJol-g4vJAxPs1XjEx95hwRboI/edit?usp=sharing
This CL:
- Add bytecode LdaNamedPropertyFromSuper
- IGNITION_HANDLER just calls Runtime::LoadFromSuper
- JSGenericLowering::LowerJSLoadNamedFromSuper just replaces the node
with a runtime call to Runtime::LoadFromSuper
Bug: v8:9237
Change-Id: Id28e935294c5068dd6c54e6b860a77d61517fff5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2327912
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69604}
Explicit nullification aims to simplify migration to Oilpan, in the
case when unique_ptrs are converted to Member and user code relies on
source pointers to be in "empty" state.
Change-Id: Ia54137d53ca03f93932b3c1f2eaba439a416a06e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379857
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69603}
Schedule is simpler compared to the schedule in blink since it now
returns deadlines based on marked bytes instead of time.
If marking is ahead of schedule, return the minimum step size.
Otherwise, set step size to catch up to schedule (ignoring the time
passed while performing the step).
No more default initial step size (needed in blink since marking speed
was unknown).
If estimated schedule is exceeded (marking takes longer than 500ms), the
steps will try to mark all remaining objects but would still be capped
by the maximum step duration of 2ms.
Bug: chromium:1056170
Change-Id: I09857db161c621a12d064f9c8c21b646c34f9d71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375200
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69602}
Starting marking required Creating a Marker and calling StartMarking.
StartMarking should always have been called immediately after creating
the marker.
Since markers are not persisted between GC (a marker exists only while
marking is in progress), it makes sense to start marking implicitly when
a marker is created.
Calling StartMarking in MarkerBase ctor is inadvisable since subclasses
might still to initialize fields.
Using MarkerFactory instead guarantees that StartMarking is always
called immediately after creating a Marker.
Bug: chromium:1056170
Change-Id: Icbf11afd848e1618c204ca6bf951600b3ae9fef2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375199
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69601}
Changes:
* Transition edges on timeline-track with the same color of the map type.
* Log file reader loading background adapted to light theme.
* Support additional IC log event colors.
* Move theme switch button to top of the app.
Bug: v8:10644, v8:10673
Change-Id: Ib086b6f4a8bc5f86a4925b251112c640e37278ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379869
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Cr-Commit-Position: refs/heads/master@{#69600}
Bug fixes:
* Wrong time range selection of timeline chunks handled by mouse events.
* Consecutive file uploads does not create a new Model object causing
bugs on timeline-track start and end times.
Bug: v8:10644
Change-Id: I3d31ddda1ffca70c18c87dd103f2b788713c2911
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379863
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Cr-Commit-Position: refs/heads/master@{#69598}
This reverts commit 9eb090d261.
Reason for revert: breaks trybot android-pie-arm64-dbg, repro steps: build cctest with target_cpu="arm64" in the args.
See thread:
https://chromium.slack.com/archives/CGJ5WKRUH/p1598563610118900
Original change's description:
> [heap] Add concurrent typed slot recording
>
> Since the typed slot set is not thread-safe, each concurrent marking
> barrier collects typed slots locally and publishes them to the main
> typed slot set in safepoints.
> Bug: v8:10315
>
> Change-Id: If1f5c5df786df88aac7bc27088afe91a4173c826
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2370302
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69576}
TBR=ulan@chromium.org,dinfuehr@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:10315
Change-Id: Iade0443e5eccef06e3ea77913e18fd1f563995f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2380613
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69597}
Move fractionalSecondsDigits between second and timeZoneName
Change order of reading options.
To sync with the July 20 PR change in
ba085a9111
Latest ECMA402 PR https://github.com/tc39/ecma402/pull/347
Bug: v8:10836
Change-Id: Ia414e0c7cc18502ccabaf02abd19861410b87cae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2378460
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69591}
This CL fixes the bug related with chunk position initialisation.
The bug caused by not subtracting the timeline chunk start time from
chunk start time. Additionally, it corrects the offset being used while
detecting the chunk location.
Bug: v8:10644
Change-Id: Icf426a297402f87d2acda0b2aa747b90e91686c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377740
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Cr-Commit-Position: refs/heads/master@{#69589}
In certain situations (especially if the profiler is disabled) it can
happen that multiple isolates trigger tier-up at the same time. Each
recompilation would then identify the set of functions to recompile and
add compilation units for them. This creates lots of redundant
compilation, which takes time and can exceed the total wasm code space
limit (code would later get garbage-collected, but there is a high
peak).
This CL fixes that by always finishing a running recompilation before
starting a new one. Since typically concurrent recompilations all
recompile for the same tier, this would avoid do most compilation only
once, and later recompilations can skip most functions.
The only redundant compilation that can happen is via compilation units
that are still executing while the next recompilation starts, but those
should not create too much redundant code.
R=thibaudm@chromium.org
Bug: chromium:1114093
Change-Id: If8fa7d953f3ce77a9d146458bf5e17bb9bf97219
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379851
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69588}
Remove ParameterMode/Tnodify StoreFixedArrayOrPropertyArrayElement
which had the last uses of:
* ElementOffsetFromIndex
* MatchesParameterMode
So we can clean those methods too.
With all of this combined, we can remove the ParameterMode declaration
from the codebase.
Bug: v8:9708, v8:6949
Change-Id: I981608681cefafe910dd40d3b82f8252e4b8994d
Fixes: v8:9708
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379514
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69586}
In order to improve our tiering strategy, it is a good idea to start
by tiering up functions that will be used the most, as this is done in
most JavaScript engines.
To decide which function requires tiering, we use as a basic strategy
to define its compilation priority to 'func_size * number_of_calls',
this roughly approximates the time we spend in the function.
To handle prioritization, it seemed that using a concurrent
priority queue similar to BigUnits was causing concurrencies issues.
I then decided to use different priority queues for each worker thread.
R=clemensb@chromium.orgCC=thibaudm@chromium.org
Bug: v8:10728
Change-Id: I6f314468549000b2a9b51d3d470f04a0cb997879
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2367859
Commit-Queue: Arnaud Robin <arobin@google.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69585}
Reading the proper pc, fp and sp in a JSEntry frame is in a different
offset than in the regular frames.
Bug: v8:10779, v8:10833
Fixes: v8:10779
Change-Id: I9aec44276fba0aab95b761ab17a16ec3767f4eb8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2369173
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69582}
Replace two unnecessary compare-exchange operations by simpler fetch_add
or exchange. This makes it easier to read and potentially faster.
R=thibaudm@chromium.org
Change-Id: Id9347ce837863e62887619f905a646bf48c07347
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377687
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69581}
Use a Foreign pointer for the signature in the generic JS-to-Wasm wrapper.
Bug: v8:10701
Change-Id: I30d5894e8b8a48c258b7a6e003813c8403c1075e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2369178
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Eva Herencsárová <evih@google.com>
Cr-Commit-Position: refs/heads/master@{#69580}
The hight 32 bits of the result of MULHW/MULHWU are undefined
which could be set to any random bits. This CL adds a few
bits to the hight 32 bits of the result to simulate this behaviour.
Change-Id: Iaaaaf83f39e2f4c051071ebd68023dc5fd024595
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2378573
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#69578}
Now that 86 has branched, we can move bitmask into the SIMD MVP, it will
not affect the current OT. (We want any OT extension to include
bitmask.)
Bitmask was accepted into the proposal in
https://github.com/WebAssembly/simd/pull/201.
Bug: v8:10308
Change-Id: Ib61190fcea2bfc0ce7bf733086e1a81388216a59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2378290
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69577}
Since the typed slot set is not thread-safe, each concurrent marking
barrier collects typed slots locally and publishes them to the main
typed slot set in safepoints.
Bug: v8:10315
Change-Id: If1f5c5df786df88aac7bc27088afe91a4173c826
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2370302
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69576}
Fix Heap-use-after-free READ 2 in Intl.Segmenter
when the segments got free during the iteration
We need to keep a copy of the string in the iterator instead
of depending on the one referenced from the segments.
Bug: chromium:1121156, v8:6891
Change-Id: I26ef5baccaa470dc1bd8cc229c737f556d27160e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376173
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69575}
This is a partial reland of 7b9a0c20f3
Reason for reland: Reverted since the ScopeInfoData part was causing
issues. Relanding the macro structure, which shouldn't cause issues
and it is needed for other CLs.
Original changes description:
> [compiler] Replace ScopeInfoData with direct reads
>
> As part of this, introduce a new ObjectData kind for objects that we
> want to read directly from the background thread rather than serialize.
> ScopeInfoRef is the first user of that.
>
> For details, see:
> https://docs.google.com/document/d/1U6x6Q2bpylfxS55nxSe17yyBW0bQG-ycoBhVA82VmS0/edit?usp=sharing
>
> Bug: v8:7790
> Change-Id: Ia3cda4f67d3922367afa4a5da2aeaae7160cf1f2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346405
> Auto-Submit: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69473}
Bug: v8:7790
Change-Id: I8d13dc206bb319638e3f7209446c24d06a07c110
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377690
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69573}
It has several variants that might need to be simplified but this
CL focuses on removing ParameterMode.
Bug: v8:9708, v8:6949
Change-Id: I1c300b7abe0b698a9f3d063e0af1ed931dbf4af2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2376820
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69572}
The {priority_} field is being updated in {DefaultJobState::Join}, under
{mutex_}. In other places though, it is read unprotected (without
holding the mutex), leading to data races.
This CL fixes that by reading the field while holding the mutex and
using the read priority after releasing the mutex.
Note that the {priority_} field is documented to be protected by
{mutex_}, so the unprotected read was a bug.
R=ulan@chromium.orgCC=etiennep@chromium.org
Bug: v8:10822
Change-Id: I80079f3cb6689e26116ffeb33755c6938c4a2cf1
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377685
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69571}
The fuzzers were calling the compiled function without passing explicit
arguments. Thus all arguments were converted from the "undefined" value,
which typically results in a zero value, as expected.
For BigInt though, it's not allowed to pass "undefined". We have to pass
a proper BigInt.
This CL implements this by passing explicit parameter values for all
parameters.
This effectively unlocks testing BigInt parameters in all fuzzers, thus
may increase coverage and find new bugs.
R=ahaas@chromium.org
Bug: chromium:1120355
Change-Id: I4e451d2418eb73d460fa937d1cf95a1ab6c99cf5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377945
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69570}
I forgot to remove them when I removed the old API in
https://chromium-review.googlesource.com/c/v8/v8/+/2369174.
Bug: v8:8116
Change-Id: I74a9670f56d09b7907187d5abcf15d707c8100a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377688
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69569}
Partially TNodify the method just to get ParameterMode out of the
way. There is more TNodification needed but method is complicated
and we are now focusing on removing ParameterMode entirely.
Bug: v8:9708, v8:6949
Change-Id: I705c35e9665488a280111683c275b7292bc47576
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2374547
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69568}
