... until after the main bulk of code generation, which will soon run on a
different thread.
R=jarin@chromium.org
Bug: v8:6048
Change-Id: I12aaaf2725e2422f588c29f50084eb77b56ad9a5
Reviewed-on: https://chromium-review.googlesource.com/505616
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45340}
Reland d8bfdb7a99
Original commit message:
If alignment parameter is set, the memory returned by the
StackSlot operator will be aligned according to the parameter.
The implementation goes like this. If alignment parameter is set
we allocate a bit more memory than actually needed and so we
can move the beginning of the StackSlot in order to have it aligned.
BUG=
Review-Url: https://codereview.chromium.org/2874713003
Cr-Commit-Position: refs/heads/master@{#45339}
JSFunctions should no longer be materialized on deopt, and the code doing
the materialization doesn't keep track of clearing the optimized code slot
if the function is marked for deopt, so just remove it.
BUG=chromium:718891
Change-Id: I8a1abfd2a1b810017c06fa6f889a85b428cb9dbd
Reviewed-on: https://chromium-review.googlesource.com/498628
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45338}
Unify, simplify logic, reduce UTF8 specific handling.
Intend of this is also to have stream views.
Stream views can be used concurrently by multiple threads, but
only one thread may fetch new data from the underlying source.
This together with unified stream view creation is intended to be
used for parse tasks.
BUG=v8:6093
Change-Id: Ied8e93090c506d4735080298f0fdaeed32043915
Reviewed-on: https://chromium-review.googlesource.com/501789
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45336}
This is in preparation for running code generation off the main thread.
Bug: v8:6048
Change-Id: Ic1ddcbbb8995d49dfcef1ffbf135117291a00ea7
Reviewed-on: https://chromium-review.googlesource.com/505513
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45334}
... by only looking at the handle.
This is in preparation for running code generation off the main thread.
Bug: v8:6048
Change-Id: I19b105c13278a2821a0b2395033e54abf5552a43
Reviewed-on: https://chromium-review.googlesource.com/506190
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45333}
When most elements of an object are deleted, we want to normalize its
elements backing store to a dictionary in order to save space. Finding
the right time to do so should not incur a linear cost on each delete
operation. This patch changes the heuristic to an amortized-constant
approach based on a global counter and the current backing store
capacity.
BUG=chromium:542978
Change-Id: Ifdf29ab2211fdde1df9078f63be4118627d6a67e
Reviewed-on: https://chromium-review.googlesource.com/506191
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45330}
Now that the optimized code hangs off the feedback vector, it is possible
to check whether a function has optimized code available every time it's
called in the interpreter entry trampoline. If optimized code exists, the
interpreter entry trampoline 'self-heals' the closure to point to the
optimized code and links the closure into the optimized code list.
BUG=v8:6246
Change-Id: I53b095db2a75ae4824c8195faf8649d766c86118
Reviewed-on: https://chromium-review.googlesource.com/501967
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45328}
Only use recursion for objects with more than
kMinRangeForMarkingRecursion (8) pointers.
Bug: chromium:651354
Change-Id: Ic71967ef535f6a32268c7097301a313db2335bf8
Reviewed-on: https://chromium-review.googlesource.com/505615
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45326}
When turning a JSCallWithSpread into a JSCall or a JSConstructWithSpread
into a JSConstruct, we need to (manually) invoke the JSCallReducer logic
again on the changed node to make sure that optimizations that are now
possible for the JSCall or JSConstruct operator are properly applied.
BUG=v8:5932,v8:5895,v8:6344,v8:6399,v8:6400
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2882153003
Cr-Commit-Position: refs/heads/master@{#45325}
We currently grow the backing store to (old_capacity*1.5)+16 if we exceed capacity,
but shrink the capacity to the current length when 2*length <= capacity.
For short arrays (up to length 32), this can lead to a copy on every operation when using push/pop or push/shift.
Example:
Array of length 32, capacity 32
push
Array grown to length 33, capacity 32*1.5+16 = 64
pop
Array trimmed to length 32, capacity 32 because 2*32 <= 64
...
This CL leaves additional slag space when calling pop and restricts the trimming to backing stores with at least 16 elements to prevent excessive re-trimming on short arrays.
Bug:
Change-Id: I9dd13e5e2550c7ac819294c8e29f04c8855e02a4
Reviewed-on: https://chromium-review.googlesource.com/502911
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45324}
Depending on the input elements, we can allocate a FAST_{SMI_,DOUBLE_,}KIND
backing store.
BUG=v8:6398
Review-Url: https://codereview.chromium.org/2887653002
Cr-Commit-Position: refs/heads/master@{#45323}
This reverts commit 98927ea51b.
Reason for revert: Breaks Mac GC Stress bot.
https://uberchromegw.corp.google.com/i/client.v8/builders/V8%20Mac%20GC%20Stress/builds/13299/steps/Mjsunit/logs/for-await-of
Original change's description:
> [ignition] Be smarter about register allocation in VisitSuspend
>
> Split BytecodeGenerator::VisitSuspend into two pieces, one for
> building the suspension code and one for resumption (these
> are split into separate Build methods for convenience).
> Each gets its own RegisterAllocationScope, which allows us to
> reduce the register file size of the empty generator by 1.
>
> For consistency, rename VisitGeneratorPrologue() to
> BuildGeneratorPrologue() to match the names of the two
> newly-created methods.
>
> Bug: v8:6379
> Change-Id: I08a617a44f99706cfff09bf86fb0a25a9cd6e032
> Reviewed-on: https://chromium-review.googlesource.com/503593
> Commit-Queue: Adam Klein <adamk@chromium.org>
> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45318}
TBR=rmcilroy@chromium.org,adamk@chromium.org,neis@chromium.org,kozyatinskiy@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Bug: v8:6379
Change-Id: I787fc3811c4f33a8021cf9170d43a74ed9b55d1c
Reviewed-on: https://chromium-review.googlesource.com/506548
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45319}
Split BytecodeGenerator::VisitSuspend into two pieces, one for
building the suspension code and one for resumption (these
are split into separate Build methods for convenience).
Each gets its own RegisterAllocationScope, which allows us to
reduce the register file size of the empty generator by 1.
For consistency, rename VisitGeneratorPrologue() to
BuildGeneratorPrologue() to match the names of the two
newly-created methods.
Bug: v8:6379
Change-Id: I08a617a44f99706cfff09bf86fb0a25a9cd6e032
Reviewed-on: https://chromium-review.googlesource.com/503593
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45318}
The output of disassemblers was changed to display instruction offsets as
hexadecimal numbers instead of a decimal numbers. Reflect this change in
turbolizer.
BUG=
Review-Url: https://codereview.chromium.org/2885453002
Cr-Commit-Position: refs/heads/master@{#45315}
Introduce a new SwitchSmiTable bytecode for generators, which does a
table lookup for the accumulator value in a jump table stored in the
constant array pool. This removes the if-else chains at resumable
function/loop headers.
As a drive-by, add a scoped environment saving struct to the bytecode
graph builder.
Bug: v8:6351
Bug: v8:6366
Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0
Reviewed-on: https://chromium-review.googlesource.com/500271
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45314}
This reverts commit 7ef1df858a.
Reason for revert: Breaks inspector/debugger/get-possible-breakpoints-restrict-to-function: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/13191/steps/Check/logs/get-possible-breakpoi..
Original change's description:
> [builtins] port Promise.all to CSA
>
> Introduces CodeStubAssembler helpers for common Iterator operations
> (GetIterator, IteratorStep, IteratorClose).
>
> Moves the Promise.all resolveElement closure and it's caller to
> builtins-promise-gen.cc.
>
> Instead of creating an internal array (and copying its elements into a result
> array), a single JSArray is allocated, and appended with BuildAppendJSArray(),
> falling back to %CreateDataProperty(), and elements are updated in the resolve
> closure the same way. This should always be unobservable.
>
> This CL increases the size of snapshot_blob.bin on an x64.debug build by 11.44kb
>
> BUG=v8:5343
> R=cbruni@chromium.org, gsathysa@chromium.org, jgruber@chromium.org
>
> Change-Id: Id69b7f76866b29caccd97f35870154c4be85f418
> Reviewed-on: https://chromium-review.googlesource.com/497974
> Commit-Queue: Caitlin Potter <caitp@igalia.com>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45306}
TBR=adamk@chromium.org,cbruni@chromium.org,gsathya@chromium.org,caitp@igalia.com,jgruber@chromium.org,ishell@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5343
Change-Id: I831738003643561fa628266af2bcebbb18000e55
Reviewed-on: https://chromium-review.googlesource.com/506014
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45313}
DEPS.chromium allows the Chromium build system's DEPS to recurse into V8's own
dependencies. Initially, this is populated with some tests files for the ARM64
simulator.
BUG=chromium:718439
Review-Url: https://codereview.chromium.org/2880293002
Cr-Commit-Position: refs/heads/master@{#45310}
Speed up LEB decoding by forcing the decoding loop to be unrolled.
Even though the compiler was free to unroll the loop before, clang did
not do so. We now manually unroll by using a template function which
calls itself recursively, passing the byte index to be decoded next.
For efficient execution, we still depend on the compiler to inline the
recursive calls (which clang does).
This optimization speeds up interpreted execution of the Jetstream
benchmarks by 15 percent.
Speedup on module decoding is negligible though.
Drive-by: Change "unsigned" to "uint32_t".
R=ahaas@chromium.org
BUG=v8:5822
Change-Id: I06d4230f92bfb2a80cdc5029d965fc3bf84ca1cc
Reviewed-on: https://chromium-review.googlesource.com/506188
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45308}
Introduces CodeStubAssembler helpers for common Iterator operations
(GetIterator, IteratorStep, IteratorClose).
Moves the Promise.all resolveElement closure and it's caller to
builtins-promise-gen.cc.
Instead of creating an internal array (and copying its elements into a result
array), a single JSArray is allocated, and appended with BuildAppendJSArray(),
falling back to %CreateDataProperty(), and elements are updated in the resolve
closure the same way. This should always be unobservable.
This CL increases the size of snapshot_blob.bin on an x64.debug build by 11.44kb
BUG=v8:5343
R=cbruni@chromium.org, gsathysa@chromium.org, jgruber@chromium.org
Change-Id: Id69b7f76866b29caccd97f35870154c4be85f418
Reviewed-on: https://chromium-review.googlesource.com/497974
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45306}
- Default constructor scopes won't need the scope data for deciding the scope
allocation of variables inside them. Also, PreParser doesn't construct them. So
they should be just skipped when applying the scope data.
- PreParser needs to declare the class name + have a proper end position for
the class scope.
- This makes all mjsunit tests pass with --experimental-preparser-scope-analysis.
- Also added several DCHECKs which were useful for debugging.
BUG=v8:5516
Change-Id: I5b3e6c60ed79efe25f33576a3547d707c700c6dd
Reviewed-on: https://chromium-review.googlesource.com/503208
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45303}
This timer is disabled since the switch to the new validator.
This CL brings it back.
R=mstarzinger@chromium.org
Change-Id: Ie454af72205564d6fec05dd4b7b44c1e3d0c37d6
Reviewed-on: https://chromium-review.googlesource.com/505610
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45300}
This makes sure that the evaluation result of the first expression in
for-statements is properly dropped, to leave the stack in a balanced
state after the statement. It also makes sure validation failures in
said expression are handled correctly.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-crbug-721835
BUG=chromium:721835
Change-Id: I7e6cff4cea0bbf5aad6a3459e27a08ea814dbdbe
Reviewed-on: https://chromium-review.googlesource.com/506148
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45299}
Crankshaft flag and opt flag mostly serve the same purpose. Using
crankshaft to mean use optimizing compiler is a bit confusing.
This cl: https://chromium-review.googlesource.com/c/490206/ fixes
the tests to use opt instead of crankshaft flag.
One difference between --no-crankshaft and --no-opt would be that
--no-opt would mean no optimizations at all where as with --no-crankshaft
would mean we can force optimizations using %OptimizeFunctionOnNextCall.
Bug: v8:6325
Change-Id: If17393ac5b6af4ea6e9a98e092f0261c2e0899c5
Reviewed-on: https://chromium-review.googlesource.com/490307
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45298}
This is the last in the series of simplifying the logic to collect feedback
in compare bytecode handlers. This cl inlines the type feedback collection
for the relational compare (lessthan, lessthan or equal, greater than,
gerater than or equal) bytecode handlers.
Bug: v8:4280
Change-Id: I4a896c9cbe5628c76785882c0632bfa07b18b099
Reviewed-on: https://chromium-review.googlesource.com/500309
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45296}
For a polymorphic access to o.x we would only merge it into a single
PropertyAccessInfo so far, if x is at the same offset in all maps and
the property index of x (in the descriptor arrays) is the same. But that
doesn't matter for code generation and blocks optimizations even.
BUG=v8:6278,v8:6344,v8:6396
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2883883002
Cr-Commit-Position: refs/heads/master@{#45294}
