The change is made since for switch statements with lots of cases,
where each case is a constant integer, the emitted bytecode is still
a series of jumps, when we can instead use a jump table.
If there are 6 or more cases (similar to GCC) of Smi literals, and
if the max Smi case minus the min Smi case is not more than 3 times
the number of cases, we use a jump table up front to handle Smi's,
and then use traditional if-else logic for the rest of the cases.
We then use the jump table in interpreter/bytecode-jump-table to
do the optimization.
This tries to go off issue 9738 in v8's issue tracker. It is not
exactly the same, since that recommends doing the work at JIT-time,
but has similar ideas. It also partially goes off issue 10764.
Bug: v8:9738
Change-Id: Ic805682ee3abf9ce464bb733b427fa0c83a6e10c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2904926
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75323}
Change-Id: I86b0d01ed283f97cde2f3d71df68c3a75107c61d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712906
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73051}
- Add tests comparing super property access to normal property access
- Shift the work so that the framework takes less time and the thing
we're trying to measure takes more time.
- Optimize / disable the optimization for the target function, not the
whole test framework.
- Reduce the amount of boilerplate code in the tests.
Bug: v8:9237
Change-Id: Idde133298c9b8ffb3d49945ef9c67f5039634598
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2536635
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71196}
The goal is to have one graph per test case, and inside the graph,
4 different lines:
- baseline
- baseline noopt
- super-ic
- super-ic noopt
Bug: v8:9237
Change-Id: I511b5555487a3d96698a3fb648abf76a13f76858
No-Try: True
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384770
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69618}
This slows down promise benchmarks since we process all unhandled promises.
Bug: vu:1099632
Change-Id: I2188a2842ec0a69ca93e5d406f10371ceff60f9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2270235
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68575}
We were calling setup for both the setup and the run.
Bug: v8:10155
Change-Id: Id60df16ad8c98f443dc1b1a9a2155000999ab815
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039431
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66234}
BigInt performance benchmarks are restructured in JSTest1.json
in such a way that it is easier to run meaningful subsets of
BigInt test cases.
Bug: v8:9213
Change-Id: Ibf94bfb0f14cf8afa890927d97f920659e8b28d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872390
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64468}
This will be used to test InterpreterEntryTrampoline
Change-Id: I2ee2cffea0741e15597a7e31f70e156e9aaa1c2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1688890
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62527}
crrev.com/c/1656852 Added an Array.reduce microbenchmark for frozen objects. On
Android devices, resources need to be whitelisted for loading.
This CL whitelists the missing resource file
R=bmeurer@chromium.org,verwaest@chromium.org
CC=duongn@microsoft.com
Bug: v8:9417
Change-Id: I0a2caca2eaaa769b085f28c3fede3a0c62d64754
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683994
Auto-Submit: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62468}
crrev.com/c/1653733 Added an Array.map microbenchmark for frozen objects. The
micro-benchmark is missing from the resource files. On Android devices,
resources need to be whitelisted for loading. The missing resource file is
causing the error in
https://chrome-swarming.appspot.com/task?id=45c1664eaeefd410
This CL adds the missing resource file
R=bmeurer@chromium.org,verwaest@chromium.org,duongn@microsoft.com
Bug: v8:9417
Change-Id: I66f8d989a1fafe5b2a357bdae7b3abd58ae54223
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1682576
Commit-Queue: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62463}
Measure speed regression of a range of char in complex regexp
The measurement is using the code from chromium:977003
To measure
python -u tools/run_perf.py --binary-override-path out/x64.release/d8 \
test/js-perf-test/RegExp.json
Run on three setting:
a. m74 based on tag 7.4.301
b. trunk (m77)
c. apply cl 1674851 on trunk
ComplexCaseInsensitiveTest-RegExp
Score is better if higher
Score imp % comp to m74
m74 22910
23430
23360
Trunk (m77) 15190 66.30%
15710 67.05%
15570 66.65%
CL 1674851 24590 161.88% 107.33%
24690 157.16% 105.38%
24200 155.43% 103.60%
Bug: chromium:977003
Change-Id: I7756f4739c44a07949103650565d1ca902e1b7ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1679651
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62449}
We have a global test/OWNERS that has "file://COMMON_OWNERS".
This CL removes redundant OWNERS files in test/ subdirectories and
removes redundant entries from OWNERS files we need to keep for
special per-file entries.
R=yangguo@chromium.org, machenbach@chromium.org
CC=jkummerow@chromium.org
Bug: v8:9247
Change-Id: Ic2e8cbe8e379d7d23c86c6164305e65807f28ed3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1674024
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62336}
Bug: v8:9247
Change-Id: Id6860e7b0f932990ac3cda39e369b0809e4f6a2b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632072
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61928}
This is a reland of 2b0ac2fb9f
The layout test that caused this revert was fixed with:
https://crrev.com/c/1627386
Original change's description:
> [array] Move Array#sort pre-processing to Torque
>
> This CL removes the "PrepareElementsForSort" runtime function, and
> replaces it with a simpler version in Torque. The biggest difference
> is that certain sparse configurations no longer have a fast-path.
>
> The Torque pre-processing step replaces the existing Torque mechanism that
> copied already pre-processed elements into the "work" FixedArray. The Torque
> compacting works as follows:
> - Iterate all elements from 0 to {length}
> - If the element is the hole: Do nothing.
> - If the element is "undefined": Increment undefined counter.
> - In all other cases, push the element into the "work" FixedArray.
>
> Then the "work" FixedArray is sorted as before. Writing the elements from
> the "work" array back into the receiver, after sorting, has three steps:
> 1. Copy the sorted elements from the "work" FixedArray to the receiver.
> 2. Add previously counted number of "undefined" to the receiver.
> 3. Depending on the backing store either delete properties or
> set them to the Hole up to {length}.
>
> Bug: v8:8714
> Change-Id: I14eccb7cfd2e4618bce2a85cba0689d7e0380ad2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619756
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61812}
TBR: jgruber@chromium.org
Bug: v8:8714
Change-Id: If7613f6e5f37c5e0d649e8192195594bc6c32100
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627977
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61827}
This reverts commit 2b0ac2fb9f.
Reason for revert: Breaks scrollingcoordinator/non-fast-scrollable-region-nested.html layout test on https://ci.chromium.org/p/v8/builders/ci/V8-Blink%20Linux%2064/32241
Original change's description:
> [array] Move Array#sort pre-processing to Torque
>
> This CL removes the "PrepareElementsForSort" runtime function, and
> replaces it with a simpler version in Torque. The biggest difference
> is that certain sparse configurations no longer have a fast-path.
>
> The Torque pre-processing step replaces the existing Torque mechanism that
> copied already pre-processed elements into the "work" FixedArray. The Torque
> compacting works as follows:
> - Iterate all elements from 0 to {length}
> - If the element is the hole: Do nothing.
> - If the element is "undefined": Increment undefined counter.
> - In all other cases, push the element into the "work" FixedArray.
>
> Then the "work" FixedArray is sorted as before. Writing the elements from
> the "work" array back into the receiver, after sorting, has three steps:
> 1. Copy the sorted elements from the "work" FixedArray to the receiver.
> 2. Add previously counted number of "undefined" to the receiver.
> 3. Depending on the backing store either delete properties or
> set them to the Hole up to {length}.
>
> Bug: v8:8714
> Change-Id: I14eccb7cfd2e4618bce2a85cba0689d7e0380ad2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619756
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61812}
TBR=peter.wm.wong@gmail.com,jgruber@chromium.org,tebbi@chromium.org,szuend@chromium.org
Change-Id: If1c1bc07f38dfbd4bf6b6ce8f9d70714e7526877
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8714
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627976
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61814}
This CL removes the "PrepareElementsForSort" runtime function, and
replaces it with a simpler version in Torque. The biggest difference
is that certain sparse configurations no longer have a fast-path.
The Torque pre-processing step replaces the existing Torque mechanism that
copied already pre-processed elements into the "work" FixedArray. The Torque
compacting works as follows:
- Iterate all elements from 0 to {length}
- If the element is the hole: Do nothing.
- If the element is "undefined": Increment undefined counter.
- In all other cases, push the element into the "work" FixedArray.
Then the "work" FixedArray is sorted as before. Writing the elements from
the "work" array back into the receiver, after sorting, has three steps:
1. Copy the sorted elements from the "work" FixedArray to the receiver.
2. Add previously counted number of "undefined" to the receiver.
3. Depending on the backing store either delete properties or
set them to the Hole up to {length}.
Bug: v8:8714
Change-Id: I14eccb7cfd2e4618bce2a85cba0689d7e0380ad2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619756
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61812}
These were leftover in another directory and can be incorporated into
our standard benchmark runner. We already had some Array slice cases
in js-perf-test so just add some of the important cases from the other
directory to the existing implementation.
Bug: v8:9254
Change-Id: I4cc235b8d3719ecd729f23fe9705ea36d445c340
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617258
Auto-Submit: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61640}
This cl also adds a separate test suite for BigInts
Bug: v8:9213
Change-Id: I57271eed0f9c33a543fe15550964d55e3df3e963
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1596728
Commit-Queue: Nico Hartmann <nicohartmann@google.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61282}
Overall, total test runtime that was wasted due to timeouts is 3420 seconds in
the last 2 weeks. Even with 4 retries, assuming all of them time out, needed
additional capacity is under 2 hours per week. Based on this analysis, I think
it's safe to land this CL.
Note that this is not intended as a long-term solution of the timeout problem,
but rather a temporary solution to prevent ongoing errors. Proper investigation
and correct long-term solution are still needed and tracked in the bug.
R=machenbach@chromium.org, tmrts@chromium.org
Bug: chromium:841700
Change-Id: Id16e6b784fa85bb9e28ed8c6b267b583636e2dc1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593342
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Sergiy Belozorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61224}
With bytecode flushing and lazy feedback allocation, we need to call
%PrepareForOptimization before we call %OptimizeFunctionOnNextCall
Bug: v8:8801, v8:8394
Change-Id: I81918f174b2f97cbaa8b8ef2e459080c2581f535
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588415
Commit-Queue: Mythri Alle <mythria@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61122}
It shipped in Chrome 73.
Bug: v8:6890
Change-Id: Idd8c98cf05a0d6e8fa58c5b0a34d079631f68b1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1582879
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#61005}
The test is currently passing at over 90% of its timeout both on desktop and
Android devices and already occasionally failing due to timeouts on Android.
R=jarin@chromium.org, mvstanton@chromium.org
No-Try: true
No-Tree-Checks: true
Bug: chromium:841700
Change-Id: Id1ba078d6a730d304935407426bdbfd0588a138b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1569429
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Sergiy Belozorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60868}
This is not fixing the root cause of the flakiness, but prevents us from loosing
data in the short to medium term as investigation proved to be difficult and
will likely take even more time.
R=machenbach@chromium.org, tmrts@chromium.org
Bug: chromium:872257
Change-Id: Id5fbd0a00058f8612089ee4d6a858193924bd868
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564204
Commit-Queue: Sergiy Belozorov <sergiyb@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60814}
