This avoids the ambiguous implicit conversion C++ compile
errors we had to fix with static_cast before.
Change-Id: I4247f617740f2b6d14d9588a902e0e25029a6726
Reviewed-on: https://chromium-review.googlesource.com/911629
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51217}
We don't need to generate TypedArraySpeciesCreate code for each type
case because TypedArraySpeciesCreate also handles each case, so it
generates duplicated codes. Thus, create a result object once before
switching to each type case. Also, replace ToNumber with
ToNumber_Inline.
This CL saves about 8000 bytes of generated code size.
Change-Id: I014535b0ef4b3d2a50a37cdc2b6cb4e83f6c2f17
Reviewed-on: https://chromium-review.googlesource.com/910755
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51213}
This removes the Javascript version of Array.from in js/array.js and
adds a CodeStubAssembler version in src/builtins/builtins-array-gen.cc.
Also modify IteratorBuiltinsAssembler to allow querying the existence
of the iterator method without calling it so we can fall back to the
array-like behavior.
BUG=v8:1956
Change-Id: Ibfb3cef002d72d70bd30b4de676fd22becde006c
Reviewed-on: https://chromium-review.googlesource.com/887066
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51208}
Cleanup CL that removes unnecessary builtins that were just wrapping
the throwing of errors. Use the ThrowTypeError and ThrowRangeError
helpers more consistently from CSA.
Change-Id: I2d0c3647340c88c457b27e16c0a81567869b7ec7
Reviewed-on: https://chromium-review.googlesource.com/906769
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51150}
We need a deopt point for the case when we fail to find an initial
element from which to begin the reduction step.
Bug: v8:7384
Change-Id: I5e476ddc433be690577677b018639c4c0c70809b
Reviewed-on: https://chromium-review.googlesource.com/906508
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51146}
Move the class declaration for SpeciesCreateByLength to a header file
so that we can share more TypedArray CSA code.
Delete the C++ implementation of species create for typed arrays
because it is no longer used.
Change-Id: I7c43b8ef144ba9a8ce12516f7cb8fb570491cb26
Reviewed-on: https://chromium-review.googlesource.com/904987
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51139}
This makes the ArrayBuiltinsAssembler consistent with the StringBuiltinsAssembler
and paves the way for tools that expect the assemblers to have a common structure.
Change-Id: I7470fc2cf144f9cc2fdbcee99b31daed267550be
Reviewed-on: https://chromium-review.googlesource.com/889933
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50920}
Before we can set the length of the created array in CSA, first check
that it's possible and will do what we want. I.e. check
a) that the length is writable
b) the backing store is not copy-on-write and
c) the old length is not greater than the new length (as otherwise later
insertion past the end could restore values from the original
constructor).
If not then fall back on Runtime::kSetProperty.
Bug: chromium:804177
Change-Id: Id0e452f9d160704bbd71e87a075ba4e3983729a7
Reviewed-on: https://chromium-review.googlesource.com/880922
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50818}
When the array created would exceed the maximum size for a regular heap
object, instead create it using Runtime::kNewArray directly rather than
via AllocateJSArray.
Bug: chromium:803750
Change-Id: I78cd82edf5a813a2ed69272361e0ca07f864c5ba
Reviewed-on: https://chromium-review.googlesource.com/876011
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50726}
This removes the Javascript version of Array.of in js/array.js and adds
a CodeStubAssembler version in src/builtins/builtins-array-gen.cc.
Mostly this change is for code-health reasons but it also gives
performance improvements for nearly all cases with the exception of
"transplanted" arrays. E.g.
function ArrayLike {}
ArrayLike.of = Array.of
ArrayLike.of(...) is now slower in the perf tests. Most of this change
can be attributed to using CallRuntime(kSetProperty,...) to set the
length. The JS version can do better due to inline caches trained on
the same datatype for 1000s of iterations, but this kind of workload is
unlikely.
Change-Id: I18e5b19b185257e9e0d553e1183b40ba4a5d3289
Reviewed-on: https://chromium-review.googlesource.com/863625
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50680}
This reduces reduces code size by 16 KB while keeping the fast path (in
which the given argument is already a smi) inlined and extracting
remaining logic to a stub call.
Change-Id: I531999c990519eef1247cc3785ad4b16164f7a5e
Reviewed-on: https://chromium-review.googlesource.com/833912
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50224}
Bug:
Change-Id: If86c51b428f254ffce68d295f9e8001cee27b9ce
Reviewed-on: https://chromium-review.googlesource.com/833236
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#50219}
Support inlining Array.prototype.findIndex in Turbofan.
Depending on array size, quick benchmarks show a >2x
improvement: https://github.com/peterwmwong/v8-perf/blob/master/array-find-findIndex-tf/README.md
Bug: chromium:791045, v8:1956, v8:7165
Change-Id: I250554885f924c97b0072e09ee289713df5cbe63
Reviewed-on: https://chromium-review.googlesource.com/824382
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50133}
- Removes JS implementation and InnerArrayFind/InnerArrayFindIndex
- Adds TFJ, with TFS for slow continuation path
Some quick benchmarks show ~2x improvement for unoptimized code
and up to 16% improvement against optimized code (diminishes with
larger arrays as iterating dominates).
https://github.com/peterwmwong/v8-perf/blob/master/array-find-findIndex/README.md
Bug: chromium:791045, v8:1956, v8:5049, v8:7165
Change-Id: Ie16252ed495bbd91fe548b16d5ef6764de791a50
Reviewed-on: https://chromium-review.googlesource.com/804704
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49851}
This reduces the overhead of calling the builtin.
Quick measurements show >5x improvement. As the
typed array's size grows, iterating dominates
and the performance gap closes.
https://github.com/peterwmwong/v8-perf/blob/master/typedarray-findIndex/README.md
Bug: v8:5929
Change-Id: I27d67776c83cbe28f4f9f5ef479a7eeabf594654
Reviewed-on: https://chromium-review.googlesource.com/792394
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49720}
This reduces the overhead of calling the builtin.
Quick measurements show >5x improvement. As the
typed array's size grows, iterating dominates
and the performance gap closes.
https://github.com/peterwmwong/v8-perf/blob/master/typedarray-find/README.md
Bug: v8:5929
Change-Id: Ia74546bb46d446c6161c8956e350d4b5cdc1b328
Reviewed-on: https://chromium-review.googlesource.com/792454
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49706}
The "array protector" now guards the Object.prototype, the
Array.prototype and the String.prototype, so the name was a
bit misleading nowadays. So the new name "no elements protector"
was chosen.
Bug: v8:6936, v8:7014, v8:7027
Change-Id: I9a9d7caa2caf0ac9e78cc6658de2f0506970dfa2
Reviewed-on: https://chromium-review.googlesource.com/778162
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49471}
This CL adds support for two byte string comparisons to the StringEqual
builtin, which so far was bailing out to the generic %StringEqual
runtime function whenever any two-byte string was involved. This made
comparisons that involved two-byte strings, either comparing them to
one-byte strings or comparing two two-byte strings, up to 3x slower than
if only one-byte strings were involved.
With this change, all direct string (SeqString or ExternalString)
equality checks are roughly on par now, and the weird performance cliff
is gone. On the micro-benchmark from the bug we go from
stringEqualBothOneByteSeqString: 162 ms.
stringEqualTwoByteAndOneByteSeqString: 446 ms.
stringEqualOneByteAndTwoByteSeqString: 438 ms.
stringEqualBothTwoByteSeqString: 472 ms.
to
stringEqualBothOneByteSeqString: 151 ms.
stringEqualTwoByteAndOneByteSeqString: 158 ms.
stringEqualOneByteAndTwoByteSeqString: 166 ms.
stringEqualBothTwoByteSeqString: 160 ms.
which is the desired result. On the esprima test of the
web-tooling-benchmark we seem to improve by 1-2%, which corresponds to
the savings of going to the runtime for many StringEqual comparisons.
Drive-by-cleanup: Introduce LoadAndUntagStringLength helper into the CSA
with proper typing to avoid the unnecessary shifts on 64-bit platforms
when keeping the length tagged initially in StringEqual.
Bug: v8:4913, v8:6365, v8:6371, v8:6936, v8:7022
Change-Id: I566f4b80e217513775ffbd35e0480154abf59b27
Reviewed-on: https://chromium-review.googlesource.com/749223
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49067}
and use a newly-introduced "enum class Operation" in all
other places that so far passed Token::Values around.
Also delete some related dead code along the way.
Bug: v8:6921
Change-Id: I062f396d304aa62298cfeff202e3132a4a5597c1
Reviewed-on: https://chromium-review.googlesource.com/736851
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48944}
E.g. use TrueConstant() instead of BooleanConstant(true) and
NullConstant() instead of HeapConstant(factory...null_value()).
R=jkummerow@chromium.org
Bug:
Change-Id: I0588d71940d8baf289eb8f8e6c8d20aa717d57f6
Reviewed-on: https://chromium-review.googlesource.com/735681
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48911}
Previously, V8's slice was implemented in a combination of C++ and a
Javascript fallback. The disadvantage of this approach was that the
fast-path required a call through the CEntryStub, which introduced
considerable overhead for small arrays with fast elements kinds.
Now the implementation primarily uses the CSA to generate both the
full spec-complaint implementation as well as fast paths for argument
objects and arrays with fast elements kinds. The CSA implementation
uses a C++ implementation fallback in select situations where the the
complexity of a CSA implementation would be too great and the
CEntryStub overhead is not decisive (e.g. slices of dictionary
elements arrays).
Performance results on semi-random arrays with small number of
elements (old vs. new):
smi copy: 48.7 ms vs. 12 ms
smi slice: 43.5 ms 14.8 ms
object copy: 35.5 ms 7.7 ms
object slice: 38.7 ms 8.8 ms
dictionary slice: 2398.3 ms vs. 5.4 ms
fast sloppy arguments slice: 9.6 ms vs. 7.2 ms
slow sloppy arguments slice: 28.9 ms vs. 8.5 ms
As a bonus, the new implementation is fully spec-compliant and fixes
at least one existing bug.
The design document for Array.prototype builtin rework can be found
at https://goo.gl/wFHe2n
Bug: v8:1956,v8:6601,v8:6710,v8:6978
Change-Id: Ia0155bedcf39b4577605ff754f416c2af938efb7
Reviewed-on: https://chromium-review.googlesource.com/574710
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48853}
Support inlining of Array.prototype.filter in TurboFan.
Bug: v8:1956
Change-Id: If50e230d14461063d378c0591dc27dea43371afa
Reviewed-on: https://chromium-review.googlesource.com/733089
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48846}
- Introduce the new union type UnionType<T1,T2>, used for Number and
Numeric. Similarly, PairType<T1,T2> is used for a Turbofan operation
with two results. Further details in the design doc:
https://docs.google.com/document/d/10foP3m7SDWyFfbda96iEJ_XYOLQdd32AeoP8SD1cTcs/edit#heading=h.bghdno28mr7u
- Allow to derive the MachineType from a static type.
This allows to select the right MachineType when performing a
load/store.
- Disallow casts (UncheckedCast() or CAST()) when the target and
origin type have no overlap.
New cast ReinterpretCast() is an UncheckedCast without this check.
- Caveat of this CL: Checked casts (CAST()) are not possible for
UnionType<T1,T2> with the exception of Number (due to the existence
of Number in OBJECT_TYPE_LIST and the existence of an IsNumber()
function in the runtime).
Bug: v8:6949
Change-Id: I21a683d1341f69cebd8a347f545b454b463c52ad
Reviewed-on: https://chromium-review.googlesource.com/723320
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48796}
If the input array is a JSArray with fast elements, it makes sense
to create an output array of the same ElementsKind when possible.
Bug: v8:1956
Change-Id: Ie9c937cf1751ccbbbe7cc76f40e1e1a0328ed37c
Reviewed-on: https://chromium-review.googlesource.com/730748
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48789}
This reverts commit 9fd029ef25.
Due to a ClusterFuzz issue.
TBR=mstarzinger@chromium.org
Bug: chromium:776511
Change-Id: I0f30e2e8de97f3c437a1756c82e645828358ad91
Reviewed-on: https://chromium-review.googlesource.com/730006
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48775}
Support inlining of Array.prototype.filter in TurboFan.
(relanding with fix for chromium:766635, visible in the
diff between patchsets 2 and 3)
Bug: v8:1956,chromium:766635
Change-Id: Ia50be6770602513e3d91d17e2b2ca9d3b0e8b42a
Reviewed-on: https://chromium-review.googlesource.com/721119
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48697}
The concurrent marker visits arrays with fast SMI elements because they
have the same visitor id as arrays with tagged elements.
Visiting concurrently with memmove can be unsafe depending on memmove
implementation.
Bug: chromium:694255
Change-Id: Ic6c2cae8761e5b1b042e4274d4f90ac59f32d91f
Reviewed-on: https://chromium-review.googlesource.com/712158
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48454}
