filter creates an output array with the Array species constructor for
storing values from the input array that pass the user-supplied
predicate function. Our new array builtins are implemented such that
if we fall out of the fast path, we'll pick up where we left off
in a continuation function. It's important to pass the index of
where we left off appending to the output array, because otherwise
we will read it at the start of the continuation function.
That would be observable, and a spec violation.
BUG=
Review-Url: https://codereview.chromium.org/2771483002
Cr-Commit-Position: refs/heads/master@{#44023}
Second bulk of changes.
BUG=v8:6116
Change-Id: I6297c4e3e1c0230a96dc6197691a54c07cc61c88
Reviewed-on: https://chromium-review.googlesource.com/457320
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43995}
This is a first bulk of changes.
BUG=v8:6116
Change-Id: I9308129bd032c0bf5b60c8e0413ee2cb710891ea
Reviewed-on: https://chromium-review.googlesource.com/456556
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43930}
Previous to this CL, CSA-optimized Array builtins--like forEach, some, and
every--were written in a single, monolithic block of CSA code.
This CL teases the code for each of these builtins apart into two chunks, a main
body with optimizations for fast cases, and a "continuation" builtin that
performs a spec-compliant, but slower version of the main loop of the
builtin. The general idea is that when the "fast" main body builtin encounters
an unexpected condition that invalidates assumptions allowing fast-case code, it
tail calls to the slow, correct version of the loop that finishes the builtin
execution.
This separation currently doens't really provide any specific advantage over the
combined version. However, it paves the way to TF-optimized inlined Array
builtins. Inlined Array builtins may trigger deopts during the execution of the
builtin's loop, and those deopt must continue execution from the point at which
they failed. With some massaging of the deoptimizer, it will be possible to make
those deopt points create an extra frame on the top of the stack which resumes
execution in the slow-loop builtin created in this CL.
BUG=v8:1956
LOG=N
Review-Url: https://codereview.chromium.org/2753793002
Cr-Commit-Position: refs/heads/master@{#43867}
This is in preparation for linking the former only into mksnapshot.
Just shuffling code around, no changes in functionality.
BUG=v8:6055
Review-Url: https://codereview.chromium.org/2752143004
Cr-Commit-Position: refs/heads/master@{#43858}
