Dividing by first computing a multiplicative inverse is faster than
Burnikel-Ziegler division for very large inputs.
Bug: v8:11515
Change-Id: Ice45690c3fa4eef7102d418cdd3d82a942a076c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015573
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75743}
This removes the low-level {SwitchMemoryPermissionsToWritable()} and
{SwitchMemoryPermissionsToExecutable()} functions. They are only used in
tests and can be replaced by {CodeSpaceWriteScope} objects that we also
use in production.
R=jkummerow@chromium.org
Change-Id: I7ba702c836f3ac2dd7c7a81d6362040b28e8bef4
Cq-Include-Trybots: luci.v8.try:v8_mac_arm64_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_mac_arm64_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3024150
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75739}
This test is only testing a d8-specific feature, so there's no need to
test it under a wide variety of conditions. And at the moment its
flakiness in the arm64/debug/simulator config are blocking the v8 roll.
Change-Id: I35456989f7875331a415ca3ff478c67a8e7e79bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3027743
Commit-Queue: Adam Klein <adamk@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Auto-Submit: Adam Klein <adamk@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75728}
This reverts commit 0b091e9bd3.
Reason for revert: Causes Web Platform Test failures, blocking roll
E.g., https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Blink%20Linux/12616/overview
Original change's description:
> [wasm][eh] Rename Exception to Tag in the JS API
>
> See:
> https://github.com/WebAssembly/exception-handling/issues/159
>
> This change only does the rename where it's observable. This should also
> be renamed throughout the codebase for consistency and will be done
> separately.
>
> R=ahaas@chromium.org
>
> Bug: v8:8091
> Change-Id: Iec1118194981dfd33be6e30256b6e72d12143e1f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021172
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75718}
Bug: v8:8091
Change-Id: Id2067e1cdc33fa657ef738ef5fafad84057f7209
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3027261
Auto-Submit: Adam Klein <adamk@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@{#75725}
Also, copying hints can be removed from literals. Shallow
copying wasn't used for some time, because of the
way we treat mutable heap numbers.
Change-Id: Ieeba44a9f8e80c4183af8f4751f68dd3a542532e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009230
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75717}
This avoids a DCHECK failure if we continue using the Assembler after
code generation abortion. Even though it might not be the best style to
still call methods on the Assembler after abortion, it's not a problem
apart from the firing DCHECK, so we apply this simple fix instead of
making sure to really abort everything immediately.
R=leszeks@chromium.org
Bug: chromium:1228720, chromium:1217074
Change-Id: Iac3a652f21e34534dd28fb1ab580ab2ee6df06dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3024157
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75716}
This is a reland of dcdaf42fa8. It adds
CPU time metrics to the WasmModuleDecoded (except for streaming),
WasmModuleCompiled and WasmModuleTieredUp events. This can later be used
to provide this information as UKMs or UMAs.
Bug: v8:11611
Change-Id: I813fc8de36d1445c6a887abf496ec10e1a803815
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953296
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75715}
Added a parameter to Object::FitsRepresentation() to disallow coercion.
Normally, when we ask if a Smi can "fit" into a Double representation
we'd answer yes, because the Smi can be converted to a HeapNumber.
However, from the compilers perspective, the object is found in a
field with a particular representation. In this case, finding a
Smi in a field with representation Double means something is awry.
Therefore, it's useful for the compiler to be able to ask if
the object fits the field without coercion.
Bug: chromium:1227324, v8:7790
Change-Id: I12033736030d904ef9c29516c07999600a5f508a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015570
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75706}
Mark --turbo-fast-api-calls flag as incompatible with stress_snapshot
variant to avoid listing all related tests in the status file.
Change-Id: If130780461e50e72ea6a43d750b2f7ad7764db2e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3024147
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75705}
When there are multiple entries into a deferred block region, ensure
that we freeze the set of deferred spill virtual registers when we have
processed the first entry point to that deferred block. This ensures
that we don't add another vreg into the set of deferred spills, and
then specify that that deferred spill slot is live across the whole
deferred block, when it is only live from certain entry points.
BUG=chromium:1227568,v8:9684
Change-Id: I647851be9a00fba262768e4f1a7846669b585a2e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021178
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75704}
- Implement f32/f64 fcopysign
- Implement f32/f64 type conversion
- enable some test cases that now pass.
Change-Id: Ia36299484adac885349df25d7c233dd7e43dded4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992914
Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ji Qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/master@{#75690}
Now that code entries outlive our CodeMap, it's safe to avoid storing
CodeMap metadata after the last active profiler stops. This simplifies
lifecycle logic, and avoids retaining stale data.
Bug: v8:11054
Change-Id: If30fc0835e2033b5bcca204565e05a5cba7823ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3000526
Commit-Queue: Andrew Comminos <acomminos@fb.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75689}
Port fb28cfe603
Original Commit Message:
So far, discarded size was maintained by the sweeper but not wired up
anywere.
Changes in this patch:
- Wire up resident size in heap statistics collection.
- Fix bugs in reporting committed and resident size.
- Sweeper test: Enforce some internal details. The details should not
not be checked broadly but be kept as a detail to the sweeper
itself.
- Stats collection: Test that committed and resident set size are
reported and differ after discarding GCs.
R=mlippautz@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: I19be251596ccc955f5c4cd43a46e566001a36ac4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021468
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#75688}
So far, discarded size was maintained by the sweeper but not wired up
anywere.
Changes in this patch:
- Wire up resident size in heap statistics collection.
- Fix bugs in reporting committed and resident size.
- Sweeper test: Enforce some internal details. The details should not
not be checked broadly but be kept as a detail to the sweeper
itself.
- Stats collection: Test that committed and resident set size are
reported and differ after discarding GCs.
Bug: chromium:1056170
Change-Id: Icf8871c7ea3b28253233485c736b2ca4816fd6f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3020971
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75684}
Monotonicity of typing of arithmetic operations could fail in the
presence of optimized_out Oddball inputs, which can arise in dead code
in resumable functions. The CL fixes these with a small change to
BinaryNumberOpTyper.
Bug: chromium:1227677
Change-Id: I1e1d2e174b757e839d776685f52f7c4ac900844b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3020972
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75683}
This reverts commit ea55438a53.
Reason for revert: Likely culprit for these failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20NumFuzz/15494/overview
Original change's description:
> [sparkplug] Support bytecode / baseline code flushing with sparkplug
>
> Currently with sparkplug we don't flush bytecode / baseline code of
> functions that were tiered up to sparkplug. This CL adds the support to
> flush baseline code / bytecode of functions that have baseline code too.
> This CL:
> 1. Updates the BodyDescriptor of JSFunction to treat the Code field of
> JSFunction as a custom weak pointer where the code is treated as weak if
> the bytecode corresponding to this function is old.
> 2. Updates GC to handle the functions that had a weak code object during
> the atomic phase of GC.
> 3. Updates the check for old bytecode to also consider when there is
> baseline code on the function.
>
> This CL doesn't change any heuristics for flushing. The baseline code
> will be flushed at the same time as bytecode.
>
> Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a
> Bug: v8:11947
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75674}
Bug: v8:11947
Change-Id: I50535b9a6c6fc39eceb4f6c0e0c84c55bb92f30a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017811
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75679}
A single ClusterFuzz report flushed out two minor issues in the
bit fiddling routines.
Bug: chromium:1227752,v8:11515
Change-Id: I16ab914b7c3859f55aa141ced371dd80171d0cb5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017809
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75678}
Currently with sparkplug we don't flush bytecode / baseline code of
functions that were tiered up to sparkplug. This CL adds the support to
flush baseline code / bytecode of functions that have baseline code too.
This CL:
1. Updates the BodyDescriptor of JSFunction to treat the Code field of
JSFunction as a custom weak pointer where the code is treated as weak if
the bytecode corresponding to this function is old.
2. Updates GC to handle the functions that had a weak code object during
the atomic phase of GC.
3. Updates the check for old bytecode to also consider when there is
baseline code on the function.
This CL doesn't change any heuristics for flushing. The baseline code
will be flushed at the same time as bytecode.
Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a
Bug: v8:11947
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75674}
Instantiation was inside a DCHECK and therefore did not happen in
non-debug modes. Turn the DCHECK into a CHECK.
R=clemensb@chromium.org
Bug: chromium:1227685
Change-Id: I13240109326a2c94576f6651963543187d96ad3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017806
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75673}
This CL implements the resolution of function overloads based on
run-time checks of the type of arguments passed to the JS function.
For the moment, the only supported overload resolution is between
JSArrays and TypedArrays.
Bug: v8:11739
Change-Id: Iabb79149f021037470a3adf071d1cccb6f00acd1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2987599
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#75664}
The Schönhage-Strassen method for *very* large inputs.
This is a reland of 347ba35716,
with added zero-initialization to pacify MSan (spurious report).
Originally:
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3000742
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75659}
Bug: v8:11515
Change-Id: Ieac6e174bde6eb09af0a9a9a49969feabca79e81
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3018081
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75663}
Reset the instance before the test run, to ensure it runs with the
same initial state as the reference run.
R=clemensb@chromium.org
Bug: chromium:1227591
Change-Id: Ie78b4b84e3df37ab8955c240f1d41e2f5e89a5de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015572
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75658}
We cannot emit the constant pool within the safepoint table data. It
seems like we also don't do that, but the forgotten
{BlockConstPoolScope} triggered a DCHECK.
R=leszeks@chromium.org
Bug: chromium:1227351, chromium:1217074
Change-Id: I187004c83e05002c651a15643bddea5b02cb00c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015559
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75657}
This is a reland of 819c3ae2f8
Original change's description:
> Reland "Reland "Improve error messages for property access on null/undefined""
>
> This is a reland of 8b18c5e6a5
>
> Original change's description:
> > Reland "Improve error messages for property access on null/undefined"
> >
> > This is a reland of 24c626c1f7
> >
> > Original change's description:
> > > Improve error messages for property access on null/undefined
> > >
> > > Only print the property name when accessing null/undefined if we can
> > > convert it to a string without causing side effects.
> > > If we can't, omit the property name in the error message.
> > > This should avoid confusion when the key is an object with toString().
> > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
> > > Object]' anymore, which was misleading since the property accessed would
> > > be 'a', but we can't evaluate the key without side effects.
> > >
> > > Bug: v8:11365
> > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > > Commit-Queue: Patrick Thier <pthier@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#75250}
> >
> > Bug: v8:11365
> > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Commit-Queue: Patrick Thier <pthier@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#75571}
>
> Bug: v8:11365
> Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219
> Auto-Submit: Patrick Thier <pthier@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75604}
Bug: v8:11365
Change-Id: I002b537144f328ccbbdcd655e26e5dc87c49c6f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013935
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75645}
The stack overflow used to occur when too many bound functions
are nested. The CL also adds a regression test.
Bug: chromium:1226264
Change-Id: I34329d8392d2385207dbd9a8d3188ad4f7cb3c2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3011161
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75640}
The JSCallWithArraylike can be replaced with a JSCall if its probable arguments list is empty literal array. This replacement will introduce a deoptimization check to make sure the length of arguments list is 0 at runtime.
This CL change this optimization to a diamond speculation which may help avoid deoptimization once and keep the fast path. This change may benefit a following usecase,
function calcMax(testArray) {
Array.max = function(array) {
return Math.max.apply(Math, array);
};
var result = [];
for (var i = 0; i < testArray.length - 3; i++) {
var positiveNumbers = [];
for (var j = 0; j < 3; j++) {
if (testArray[i + j] > 0) {
positiveNumbers.push(testArray[i + j]);
}
}
result.push(Array.max(positiveNumbers));
}
return result;
}
testArray = [-1, 2, 3, -4, -5, -6, -7, -8, -9, 10];
for (var i = 0; i < 1000000; i++) {
calcMax(testArray);
}
Bug: v8:9974
Change-Id: I595627e2fd937527350c8f8652d701c791b41dd3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2967757
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75636}
Add an option to use Liftoff instead of the interpreter as the reference
tier for fuzzing. The tier to use is chosen based on the input data
before generating the module. This way, the module can use features
depending on what is available in the reference tier, and we still get a
chance to find correctness issues that would only be detected by the
interpreter.
R=clemensb@chromium.org
Bug: v8:11856
Change-Id: I2e9878345355a37caec5fdb338dda42a84e8e63a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008645
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75633}
Trap handling is not implemented yet for memory64. Make sure that no
code tries to use it, by setting {NativeModule::bounds_checks_}
accordingly.
This requires some changes to tests to make sure that the
{WasmModule::is_memory64} field is set before creating the corresponding
{NativeModule}.
R=ahaas@chromium.org
Bug: v8:10949
Change-Id: I11d9544b603fc471e3368bb4e7487da4711293a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3011167
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75632}
This reverts commit 819c3ae2f8.
Reason for revert: Sorry Patrick, still failing on some layout tests :( https://test-results.appspot.com/data/layout_results/mac-rel/726365/blink_web_tests%20%28retry%20shards%20with%20patch%29/layout-test-results/results.html
Original change's description:
> Reland "Reland "Improve error messages for property access on null/undefined""
>
> This is a reland of 8b18c5e6a5
>
> Original change's description:
> > Reland "Improve error messages for property access on null/undefined"
> >
> > This is a reland of 24c626c1f7
> >
> > Original change's description:
> > > Improve error messages for property access on null/undefined
> > >
> > > Only print the property name when accessing null/undefined if we can
> > > convert it to a string without causing side effects.
> > > If we can't, omit the property name in the error message.
> > > This should avoid confusion when the key is an object with toString().
> > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
> > > Object]' anymore, which was misleading since the property accessed would
> > > be 'a', but we can't evaluate the key without side effects.
> > >
> > > Bug: v8:11365
> > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > > Commit-Queue: Patrick Thier <pthier@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#75250}
> >
> > Bug: v8:11365
> > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Commit-Queue: Patrick Thier <pthier@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#75571}
>
> Bug: v8:11365
> Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219
> Auto-Submit: Patrick Thier <pthier@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75604}
Bug: v8:11365
Change-Id: I7d7c0f201288384c2aa38a51418b582a64213ae0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013352
Auto-Submit: Leszek Swirski <leszeks@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@{#75626}
We had some (dead) logic to create different parameter values pending on
the position of the parameter. As it was not used any more, it got
removed in https://crrev.com/c/3003464.
This CL changes the existing logic for creating default parameter values
to use a similar logic, which matches what --wasm-fuzzer-gen-test
creates and has a slightly higher chance of triggering interesting
behaviour.
R=ahaas@chromium.org
Change-Id: Ibb4394c1978f25d70166a03002e084211bfe7e1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3003465
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75619}
The bugfix yesterday missed a case (CL
758816f438).
A better approach is to compute the ideal representation of the
value, then check if it can be in-place changed to the
recorded representation.
Bug: chromium:1226988, v8:7790
Change-Id: I90e58b8efb83892c033693a1a0f946b3059a330c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3011162
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75615}
Behind a new --experimental-wasm-nn-locals flag.
The checking policy implemented here is that locals count as
initialized until the end of the current control structure,
as described here:
https://github.com/WebAssembly/function-references/issues/44#issuecomment-801977331
Bug: v8:7748
Change-Id: I954fdf1b4e02ed4b45ef61b8379b7c0bbe802400
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3010283
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75613}
This CL implements GC in a shared heap. A shared GC is started from
an attached client isolate that fails to allocate a shared object. In
order to perform a shared GC all other running client isolates need
to be stopped and their roots need to be scanned.
Bug: v8:11708
Change-Id: I45ac50e6b4a1e9270f9e39b69f9b8ee5e6e14134
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964816
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75606}
This is a reland of 8b18c5e6a5
Original change's description:
> Reland "Improve error messages for property access on null/undefined"
>
> This is a reland of 24c626c1f7
>
> Original change's description:
> > Improve error messages for property access on null/undefined
> >
> > Only print the property name when accessing null/undefined if we can
> > convert it to a string without causing side effects.
> > If we can't, omit the property name in the error message.
> > This should avoid confusion when the key is an object with toString().
> > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
> > Object]' anymore, which was misleading since the property accessed would
> > be 'a', but we can't evaluate the key without side effects.
> >
> > Bug: v8:11365
> > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Commit-Queue: Patrick Thier <pthier@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#75250}
>
> Bug: v8:11365
> Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75571}
Bug: v8:11365
Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219
Auto-Submit: Patrick Thier <pthier@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75604}
We did not handle conflicts between regular register moves and the
cached instance / cached memory start correctly. This could lead to us
overwriting a regular register when restoring the cached instance, which
results in either crashes or miscalculations afterwards.
R=ahaas@chromium.org
Bug: chromium:1217064
Change-Id: Icd4b08b97a47726108a50d51b3a7ba410d132f98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3003158
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75602}
The {TestingModuleBuilder} had separate logic to compute the bounds
checking strategy. This can lead to compiled code that does not match
the bounds checking strategy stored in the NativeModule. Hence, tests
should use {NativeModule::bounds_checks_} for initializing their
compilation environment.
R=ahaas@chromium.org
Change-Id: I366c2ea5d06062273fa21e388871fc1adab54fef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009222
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75601}
A generalization of Karatsuba's idea for even larger inputs.
Bug: v8:11515
Change-Id: I50eac2d313bf4217bf2f55ca2e64b5f120f40206
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999870
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75598}
In GetOwnFastDataPropertyFromHeap, we read a property value
then compare it with the expected representation. We already
had code to bail out of that particular optimization if there
was a mismatch, however it missed the case of expected
representation being a HeapObject, and when a Smi value was found.
The fix is to use the excellent pre-existing method
Object::FitsRepresentation() to make this check. Thusly, all
cases are handled.
Bug: chromium:1225607, v8:7790
Change-Id: I7d9b1b7722d9691cf5427f8456a6deb466dda0d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008218
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75587}
TurboFan reads the value in HeapNumber, and TSAN detects a data
race between this read and sets on the main thread elsewhere.
We mark this as relaxed atomic (meaning, correct value of the read
is not guaranteed). The compiler uses the dependency mechanism
to re-read the value safely on the main thread later, and aborts
compilation if a change is detected.
Bug: chromium:1224277, v8:7790
Change-Id: I8931d8989812550c0c57b6bd27aa796f6f5e779d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2996201
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75586}
