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}
Support inlining of Array.prototype.filter in TurboFan.
Bug: v8:1956
Change-Id: Iba4d683aaa86c6104e8a1cf4d0f549a0c516576a
Reviewed-on: https://chromium-review.googlesource.com/657021
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48040}
Given that the index we use is checked to be in array index range there is no
need for a costly ToString conversion. All involved helpers for lookup up
properties directly support Smi/HeapNumber indices directly.
Cleanup: Rename GotoUnlessNumberLessThan => GotoIfNumberGreaterThanOrEqual
Change-Id: Iaddc4940f5d984572aa218d568ca71bf694cee74
Reviewed-on: https://chromium-review.googlesource.com/640388
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48039}
BigInt is a new primitive type of arbitrary precision integers,
proposed in https://tc39.github.io/proposal-bigint.
This CL introduces a corresponding instance type, map, and C++
class to V8 and adds BigInt support to a few operations (see the
test file). Much more is to come. Also, the concrete representation
of BigInts is not yet fixed, currently a BigInt is simply a wrapped
Smi.
Bug: v8:6791
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia2901948efd7808f17cfc945f0d56e23e8ae0b45
Reviewed-on: https://chromium-review.googlesource.com/657022
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47956}
We can avoid the ToString conversion before doing the HasProperty check.
This avoid a costly Smi to String conversion which is unecessary for the
following lookups.
For very large dictionary elements this is a significant slow down as we
will no longer hit the GetNumberStringCache.
Change-Id: I5a0eb13470ab3d3d8a87ee36d28ce7be5cbc2b2e
Reviewed-on: https://chromium-review.googlesource.com/626056
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47574}
The code accidentally jumped over the actual left-shift part when the
head of the array was the hole.
Bug: chromium:752722
Change-Id: I300a3ebcfafb07d6ecebc01fa57c66eb26f349ac
Reviewed-on: https://chromium-review.googlesource.com/603717
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47204}
This fixes a missing fast-path check in the code-stub implementation of
the {Array.prototype.filter} method. Appending to the target JSArray is
only correct if the underlying length did not change.
R=jgruber@chromium.org
TEST=mjsunit/regress/regress-6657
BUG=v8:6657
Change-Id: Ida8d3511485b649b70d9a4b161742d494ebe4dac
Reviewed-on: https://chromium-review.googlesource.com/600467
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47156}
If the input array is small, then the cost of a trip to the
runtime to transition the ElementsKind is too expensive.
Bug:
Change-Id: Ib04f8567674a6f1f66f4c7263eba5fb4c58987aa
Reviewed-on: https://chromium-review.googlesource.com/544866
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46417}
The `FAST_` prefix doesn’t make much sense — they’re all just different cases
with their own optimizations. Packedness being implicit (e.g. `FAST_ELEMENTS`
vs. `FAST_HOLEY_ELEMENTS`) is not ideal, either.
This patch renames the FAST elements kinds as follows:
- e.g. FAST_ELEMENTS => PACKED_ELEMENTS
- e.g. FAST_HOLEY_ELEMENTS => HOLEY_ELEMENTS
The following exceptions are left intact, for lack of a better name:
- FAST_SLOPPY_ARGUMENTS_ELEMENTS
- SLOW_SLOPPY_ARGUMENTS_ELEMENTS
- FAST_STRING_WRAPPER_ELEMENTS
- SLOW_STRING_WRAPPER_ELEMENTS
This makes it easier to reason about elements kinds, and less confusing to
explain how they’re used.
R=jkummerow@chromium.org, cbruni@chromium.org
BUG=v8:6548
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ie7c6bee85583c3d84b730f7aebbd70c1efa38af9
Reviewed-on: https://chromium-review.googlesource.com/556032
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46361}
To be able to use this in optimized code dependency relationships.
Bug:
Change-Id: Ia099a68994b1252de3c72c8d688862ca17ca76d9
Reviewed-on: https://chromium-review.googlesource.com/548716
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46277}
This CL contains a few pieces:
- A new mechanism to create "BuiltinContinuation" checkpoints in TurboFan
graphs, which--when triggered--swizzle the values in the the FrameState to be
parameters to a typically TF-generated builtin that resumes execution to finish
the slow-case functionality.
- Continuation builtins that have special handling in the deoptimizer and their own
new frame type to ensure that the values they need to begin executing can be stashed
away and restored immediately before the builtin is called via a trampoline that runs
when the continuation builtin's frame execution resumes.
- An implementation of Array.prototype.forEach in TurboFan that can be used to
inline it. The inlined forEach implementation uses the checkpoints mechanism
described above to deopt in the middle of the forEach in the cases that optimization
invariants are violated. There is a slightly different continuation stub for each
deopt point in the forEach implementation to ensure the correct side-effects, i.e.
that the deopt of the builtin isn't programmatically observable.
Review-Url: https://codereview.chromium.org/2803853005
Cr-Commit-Position: refs/heads/master@{#45764}
The assertion was too strict, not matching the check in JSTypedArray::Create.
Delete the TODO because the code does not actually rely on the assertion for safety: EmitElementStore always performs a length check.
Drive-by-fix: KeyedAccessStoreMode::STANDARD_STORE is equally safe and does one comparison less.
Bug: chromium:724889
Change-Id: I988a4eb6ad36d35143a008f7289b075f5c05e7ed
Reviewed-on: https://chromium-review.googlesource.com/517102
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45617}
This CL enforces passing an AssemblerDebugInfo object to Bind, most convently
acheived by the BIND macro.
Change-Id: I092714f10803f529d01d2fe716b96275b2bee806
Reviewed-on: https://chromium-review.googlesource.com/508729
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45433}
