Now that we have no more do-expressions, we don't need to reparent variables
and declarations anymore. However, it's still possible that temporaries were
implicitly allocated. We still need to move those.
Bug: chromium:904255
Change-Id: Ia8a90eb822b9db123ffb0bad58e4b720c1452d9f
Reviewed-on: https://chromium-review.googlesource.com/c/1329685
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57424}
Split the Install methods into PrepareInstall and Install, such that
all heap mutations (besides the actual installation) are done in
PrepareInstall and only the actual installation in Install. This
ensures that the code object in question doesn't get deoptimized while
we're still installing its dependencies.
Bug: chromium:903697
Change-Id: I4da97d89d0707fa3c00c97c092af0d0faa7a4946
Reviewed-on: https://chromium-review.googlesource.com/c/1329162
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57419}
This test was adapted from a repro, and thus it's rather complex.
It takes over seven minutes to run on the arm64 sim debug bot,
and nearly five minutes on arm.
Given that it was originally accompanied by a very targeted fix in
Crankshaft, it strikes me that this probably isn't worth our CPU
time to continue running.
Bug: v8:7783, chromium:85177
Change-Id: Ibe85cc254aa754365404b5fbbf80bcb1f5a09c68
Reviewed-on: https://chromium-review.googlesource.com/c/1327188
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57408}
The flag is on by default, so we don't need to specify it. More
importantly, the tests are expected to work for any value of that flag.
So don't force the flag but use whatever the test variant chooses.
Note that in streaming-compile.js, the flag was accidentally specified
as '-async-compilation'. I also removed that one.
R=ahaas@chromium.org
Change-Id: Ifad31160d266dda38cdd9dd1d73dad69bd2c2f2c
Reviewed-on: https://chromium-review.googlesource.com/c/1325961
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57406}
Previously we'd check `x` for -0 by testing `(1.0 / x) == -Infinity`,
but this will yield the wrong results when `x` is a subnormal, i.e.
really close to 0.
In CSA we already perform bit checks to test for -0, so teach TurboFan
to do the same for comparisons to -0 (via `Object.is`). We introduce a
new NumberIsMinusZero simplified operator to handle the case where
SimplifiedLowering already knows that the input is a number.
Bug: chromium:903043, v8:6882
Change-Id: I0cb7c568029b461a92fc183104d5f359b4bfe7f4
Reviewed-on: https://chromium-review.googlesource.com/c/1328802
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57382}
Behavior in Release mode was correct; Debug mode triggered a DCHECK
failure that indicated an inefficiency: when a requested truncation
would be a no-op, we should return the original BigInt, rather than
creating a copy. In the special case of -2^(n-1), i.e. the smallest
negative n-bit integer, getting truncated to n bits, with n being a
multiple of kDigitBits, this shortcut was not taken.
Bug: v8:8426
Change-Id: I8e4595d9ac0dbef81aae06688f9a9636bd2d9cd9
Reviewed-on: https://chromium-review.googlesource.com/c/1325029
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57369}
Change the macros added in bf84766a2c to
only do the hard work if FLAG_unbox_double_fields is unset (otherwise,
they will attempt to dereference raw float64s, which is bad!)
Also adds a write barrier in CopyPropertyArrayValues for each store if
it's possible that a MutableHeapNumber is cloned.
BUG=chromium:901301, chromium:902965, chromium:903070, v8:7611
R=cbruni@chromium.org, jkummerow@chromium.org, ishell@chromium.org
Change-Id: I224d3c4e7b0a887684bff68985b4d97021ba4cfb
Reviewed-on: https://chromium-review.googlesource.com/c/1323911
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57368}
Since we use a ScopedPtrList to track cover grammar expressions we don't know
the position of the commas anymore. The position of the commas was used to
demark the initializer, which is needed to figure out whether we need hole
checks for variable references. (Typically only references within the
initializer need hole checks for the initialized variable.) Since we didn't
have the comma position, we simply used the position of the first expression as
the position of any subsequent comma, which would make it seem as if the
initializer body wasn't in the initializer. Now instead we simply use the
position of the subsequent parameter as the end of the initializer, which is
close enough.
Bug: chromium:902810
Change-Id: I8d2bc7a2dc9f59db16ce56ccef01e263a18a3b7a
Reviewed-on: https://chromium-review.googlesource.com/c/1326022
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57357}
The Ignition statement list visitor will skip the rest of the
statements in the list if it hits a jump statement (like a return
or break), as the rest of the code in the list can be considered
dead.
return;
dead_call(); // skipped
However, since this is at an AST node level, it does not take into
account condition shortcutting:
if(2.2) return;
dead_call(); // not skipped
There is also a second dead code elimination in Ignition compilation, at
the bytecode array writer level, where a bytecodes are not emitted if an
"exit" bytecode (Return, Jump, or a few others) has been written, until
the next basic block starts (i.e. a Bind).
This can cause an issue with statements that resurrect the bytecode
array writer part-way through their visit. An example is try-catch
statements, which save the context to a register, and then Bind to start
the try region.
For the case:
if (2.2) return;
try { // try statement not skipped
...
}
the bytecode writer is called with
OutputReturn() // exit bytecode seen
OutputMove(<context>, r1) // not emitted
Bind(&try_begin) // starts new basic block
// try body
So, the try is emitted, but without saving the context to a register.
This means that the liveness analysis sees the read of that register
(as the output liveness of throwing bytecodes), but does not have a
write to the register, which means that the liveness escapes.
This patch fixes this by using the bytecode array writer dead-code
elimination (i.e. "exit bytecode seen") to inform the statement list
visitor, so that in this example the try statement is not visited at
all.
Bug: chromium:902395
Change-Id: Ieb8e46a4318df3edbac0ae17235e0ce8fba12ee3
Reviewed-on: https://chromium-review.googlesource.com/c/1322951
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57350}
As opposed to the register.
For subtle reasons, this fixes a deoptimizer bug with handling return
values in lazy deopt. Since the return values can now only overwrite
the accumulator, there is no danger of overwriting a captured object
that might be later used (since there is no "later").
Bug: chromium:902608
Change-Id: I3a7a10bb1c7a6f4303a01d60f80680afcb7bc942
Reviewed-on: https://chromium-review.googlesource.com/c/1325901
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57349}
Installation of the PrototypePropertyDependency, as well as GC, can
invalidate dependencies.
Bug: chromium:902552
Change-Id: Iabcce026c7475c722d19ac0b80758b22d9fbcfda
Reviewed-on: https://chromium-review.googlesource.com/c/1322450
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57343}
regress-336820 is testing that joining a very sparse
array to create a too-big string results in a RangeError,
rather than a crash. Reducing the largest index by
two orders of magnitude speeds this up (on x64 debug)
by 8x (from 8 seconds down to 1). Given that this test
takes nearly 9 minutes on arm64 sim debug, I hope to
see big ones there too.
Bug: v8:7783, chromium:336820
Change-Id: I74c22cf451a892eb039efc7f1259152921bf8530
Reviewed-on: https://chromium-review.googlesource.com/c/1323915
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57335}
Recursion is really only useful for sloppy eval and with scopes, which are
uncommon.
Change-Id: I2560b600cab9b00a82d5837a3daa28c8d38c2959
Reviewed-on: https://chromium-review.googlesource.com/c/1322451
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57316}
Adds a helper macro "CloneIfMutablePrimitive", which tests if the
operand is a MutableHeapNumber, and if so, clones it, otherwise
returning the original value.
Also modifies the signature of "CopyPropertyArrayValues" to take a
"DestroySource" enum, indicating whether or not the resulting object is
supplanting the source object or not, and removes all default
parameters from that macro (which were not used anyways).
This corrects the issue reported in chromium:901301, where
StaNamedOwnProperty was replacing the value of a MutableHeapNumber
referenced by both the cloned object and the source object.
BUG=chromium:901301, v8:7611
R=cbruni@chromium.org, jkummerow@chromium.org
Change-Id: I43df1ddc84dfa4840e680b6affeba452ce0b6629
Reviewed-on: https://chromium-review.googlesource.com/c/1318096
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57304}
'simulator_run' is now used exclusively in test/*/*.status.
Change-Id: I501b7ffd19e2476f4c803ed3d25cba69d67039fa
Reviewed-on: https://chromium-review.googlesource.com/c/1318610
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57300}
This test currently takes nearly 10 minutes on the arm64 debug builder.
Bug: v8:7783
Change-Id: I500fc026b01873e666f32062d790eca3f34455b9
Reviewed-on: https://chromium-review.googlesource.com/c/1318495
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57298}
simulator takes too long to run.
Change-Id: I77f6e932129bfed7d1cdb7e9ccf78a4608554ff5
Reviewed-on: https://chromium-review.googlesource.com/c/1320389
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#57296}
Rename variables and flag names so that the classes can be reused
by private methods implementation.
In particular:
Rename "fields" to "members" in the initializer so that we can
initialize both fields and private methods/accessors there,
for example:
instance_fields_initializer -> instance_members_initializer
InitializeClassFieldsStatement -> InitializeClassMembersStatement
Rename "private field" to "private name" for the private symbols
used to implement private fields so that we can use them to
store private methods/accessors later as well, for example:
private_field_name_var -> private_name_var
NewPrivateFieldSymbol -> NewPrivateNameSymbol
The follow-on is in
https://chromium-review.googlesource.com/c/v8/v8/+/1301018
The design doc is in
https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit?usp=sharing
Bug: v8:8330
Change-Id: I1cdca8def711da879b6e4d67c5ff0a5a4a36abbe
Reviewed-on: https://chromium-review.googlesource.com/c/1312597
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#57289}
These tests are also used for streaming. This CL changes the test to
actually output the exception that unexpectedly happened.
R=ahaas@chromium.org
Bug: v8:7921
Change-Id: Ia9c91a7d3d9452f9c0180329a5434f049b56c3c8
Reviewed-on: https://chromium-review.googlesource.com/c/1319755
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57284}
The array length is modifiable by user code that is called as a
side-effect during the sorting algorithm. We thus cannot base any
guarantees on the current length, but must reference the initially-read
array length instead.
Note that even though the algorithm may read and write from beyond
the current array length value, this adheres to the spec, which only
requires accesses to be within the original array dimensions (i.e.: 0
<= i < original array length).
Bug: chromium:901633
Change-Id: Id765e80d4231ff6f2a73e040ec94c2b07f8c5b0f
Reviewed-on: https://chromium-review.googlesource.com/c/1317814
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57279}
This should allow for better parallelization when running these tests.
Change-Id: Ib3cae7d6e8f0d2608470ca616eeac7eecae3b7ab
Reviewed-on: https://chromium-review.googlesource.com/c/1318094
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57256}
- Add the WeakRef class and its deref() function.
- Add WeakFactory.prototype.makeRef
- Implement the "keep during job" behavior for WeakRef constructor and deref().
- Here we keep the targets alive longer than until the end of the job
(microtask), contradicting the spec. However, this is probably the indended
behavior, see https://github.com/tc39/proposal-weakrefs/issues/39 .
BUG=v8:8179
Change-Id: I41990d41ac1799e34f675d8431b9a7aa7ed3d48d
Reviewed-on: https://chromium-review.googlesource.com/c/1306435
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57242}
This is a reland of 7bd9eb7e1e. No changes
to that patch other than adding a test case. The bug that lead to the
revert has been fixed in 9bf8f72c5b.
Original change's description:
> Add fast paths to Array.from.
>
> This reuses the fast path from IterableToList for Array.from. The fast
> paths are taken when .from is called with the receiver Array and the only
> argument is the iterable (no mapping function or thisArg).
>
> Bug: v8:7980
> Change-Id: I975b0c5e3f838262d7b71ad4dec5111fb031d746
> Reviewed-on: https://chromium-review.googlesource.com/c/1297322
> Commit-Queue: Hai Dang <dhai@google.com>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56993}
Bug: v8:7980
Change-Id: Id081837946c0989ec2b31ce991f48d09e0219b09
Reviewed-on: https://chromium-review.googlesource.com/c/1317586
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57240}
The fast paths for sets and maps did not support allocation in
large object space, yet they were taken in these cases. This CL
adds support, simply by passing the kAllowLargeObjectAllocation
argument to AllocateJSArray.
It also changes the fast path for strings to use this argument
rather than take the slow path.
Bug: v8:7980, v8:8410
Change-Id: I18e88cb4ceb7ebeca250edd8b8b0eb401fdbd6e4
Reviewed-on: https://chromium-review.googlesource.com/c/1317507
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57232}
- Avoid allocating AstRawString in the preparser
- Use fast LiteralEquals to compare the directive.
Bug: chromium:901250
Change-Id: I178aca812f6c0ffa28d7f48b707316a5a99a2ac0
Reviewed-on: https://chromium-review.googlesource.com/c/1314570
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57217}
Restructure the code a little, and change how we detect sloppy block function
redeclaration so we don't dereference a possibly nullptr function.
Bug: chromium:900786
Change-Id: Ief124fe767603ca36f4dc8865c4aeb3e0635b4cf
Reviewed-on: https://chromium-review.googlesource.com/c/1314331
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57206}
The fast-path in the `ArrayPrototypeLastIndexOf` torque implementation
didn't check that the `fromIndex` is within the bounds of the JSArray
_AFTER_ the call to ToInteger, which can have arbitrary side-effects,
i.e. it can change the length of the array.
R=yangguo@chromium.org
Bug: chromium:898785
Change-Id: I7ef84143ec8c33148f6e9d451bd52769d5074fb4
Reviewed-on: https://chromium-review.googlesource.com/c/1314329
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57204}
CanCover is not transitive. The counter example are Nodes A,B,C such
that CanCover(A, B) and CanCover(B,C) and B is pure. In this case the
effect level of A and B might differ.
This CL adds a missing CanCover check to a case of shift reduction where
we assumed transitivity.
Change-Id: I9f368ffa6907d2af21bbc87b3e6570d0d422e125
Bug: v8:8384
Reviewed-on: https://chromium-review.googlesource.com/c/1307419
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57157}
We didn't check if the input typed array was neutered before going to
the fast path, so we hit a CHECK in this case.
Fix this by just checking if the buffer was neutered and then going to
the 'check iterator' case if it is. This will cause a TypeError via
IterableToList, which was the same as the behavior before the
optmization was landed.
Bug: chromium:899519
Change-Id: I09e6389ea2ab1e3bef01e616721b48a9b66c1b2a
Reviewed-on: https://chromium-review.googlesource.com/c/1307422
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57137}
For memory limit checks, we should use the minimum of the
--wasm-max-mem-pages flag and kV8MaxWasmMemoryPages. The former is a
limit set by the user, the latter is the maximum we can handle
internally.
R=titzer@chromium.org
Bug: chromium:898677
Change-Id: I3c549f4e90dd016b5d07475d9353f30134f76dcc
Reviewed-on: https://chromium-review.googlesource.com/c/1305274
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57127}
BinaryNumberOpTyper was not monotonic: if one input changes
from Number to Numeric, while the other input stays BigInt,
the result would change from Number to BigInt.
We have some fuzzing tests for monotonicity but unfortunately
they never generated the inputs required for triggering this bug.
We'll look into improving our tests.
Bug: v8:8380
Change-Id: I7320d9ae4b89ad8798bf9e97cc272edba2162a77
Reviewed-on: https://chromium-review.googlesource.com/c/1307418
Commit-Queue: Hai Dang <dhai@google.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57125}
These tests rely on dropping references to objects either explicitly ("o =
null;") or implicitly ("o goes out of scope") and then doing gc. It's essential
that we haven't already marked the WeakCell pointing to o and marked it alive
before dropping the reference.
BUG=v8:8179
Change-Id: Ie0b73f05c4baa937cf6f28325454ff9087a71a2c
Reviewed-on: https://chromium-review.googlesource.com/c/1306437
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57115}
This adds appropriate LoopExit nodes for the JSCallReducer lowerings of
the following higher order Array builtins:
- Array.prototype.every()
- Array.prototype.find()
- Array.prototype.findIndex()
- Array.prototype.some()
Loop peeling allows TurboFan to make loop invariant operations in the
callback passed to the higher order builtin fully redundant, and thus
completely eliminate the loop invariant code from the subsequent loop
iterations. This can have a huge performance impact, depending on what
kind of code runs inside of the callback. For example, on the micro-
benchmarks outlined in http://crbug.com/v8/8273 we go from
forLoop: 364 ms.
every: 443 ms.
some: 432 ms.
find: 522 ms.
findIndex: 437 ms.
to
forLoop: 369 ms.
every: 354 ms.
some: 348 ms.
find: 419 ms.
findIndex: 360 ms.
which is 20% improvement, and essentially brings the Array builtins (the
appropriate ones Array#some() and Array#every() in this case) on par
with the hand-written `for`-loop.
Bug: v8:1956, v8:8273
Change-Id: I9d32736e5402807b4ac79cd5ad15ceacd1945681
Reviewed-on: https://chromium-review.googlesource.com/c/1305935
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57110}
This introduces Word64 support for the CheckBounds operator, which now
lowers to either CheckedUint32Bounds or CheckedUint64Bounds after the
representation selection. The right hand side of CheckBounds can now
be any positive safe integer on 64-bit architectures, whereas it remains
Unsigned31 for 32-bit architectures. We only use the extended Word64
support when the right hand side is outside the Unsigned31 range, so
for everything except DataViews this means that the performance should
remain the same. The typing rule for the CheckBounds operator was
updated to reflect this new behavior.
The CheckBounds with a right hand side outside the Unsigned31 range will
pass a new Signed64 feedback kind, which is handled with newly introduced
CheckedFloat64ToInt64 and CheckedTaggedToInt64 operators in representation
selection.
The JSCallReducer lowering for DataView getType()/setType() methods was
updated to not smi-check the [[ByteLength]] and [[ByteOffset]] anymore,
but instead just use the raw uintptr_t values and operate on any value
(for 64-bit architectures these fields can hold any positive safe
integer, for 32-bit architectures it's limited to Unsigned31 range as
before). This means that V8 can now handle huge DataViews fully, without
falling off a performance cliff.
This refactoring even gave us some performance improvements, on a simple
micro-benchmark just exercising different DataView accesses we go from
testDataViewGetUint8: 796 ms.
testDataViewGetUint16: 997 ms.
testDataViewGetInt32: 994 ms.
testDataViewGetFloat64: 997 ms.
to
testDataViewGetUint8: 895 ms.
testDataViewGetUint16: 889 ms.
testDataViewGetInt32: 888 ms.
testDataViewGetFloat64: 890 ms.
meaning we lost around 10% on the single byte case, but gained 10% across
the board for all the other element sizes.
Design-Document: http://bit.ly/turbofan-word64
Bug: chromium:225811, v8:4153, v8:7881, v8:8171, v8:8383
Change-Id: Ic9d1bf152e47802c04dcfd679372e5c85e4abc83
Reviewed-on: https://chromium-review.googlesource.com/c/1303732
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57095}
For NumberMin and NumberMax we don't need to go to Float64 when the
inputs are known to be in SafeInteger range, instead we can go to
Word64 on 64-bit architectures. This is preliminary work for the
huge DataView support, since we'll utilize NumberMax in that case
to clamp the limit for the bounds check.
Bug: v8:8178, v8:8383
Change-Id: I414114229c5c86b92749d30d645cedc641541ae4
Reviewed-on: https://chromium-review.googlesource.com/c/1304535
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57090}
