When inlining based on SharedFunctionInfo rather than based on concrete
JSFunction, we weren't able to properly optimize array, object and
regexp literals inside the inlinee, because we didn't know the concrete
FeedbackVector for the inlinee inside JSCreateLowering. This was because
JSCreateLowering wasn't properly updated after the literals moved to the
FeedbackVector. Now with this CL we also have the VectorSlotPair on the
literal creation operators, just like we do for property accesses and
calls, and are thus able to always access the appropriate FeedbackVector
and optimize the literal creation.
The impact is illustrated by the micro-benchmark on the tracking bug,
which goes from
createEmptyArrayLiteral: 1846 ms.
createShallowArrayLiteral: 1868 ms.
createShallowObjectLiteral: 2246 ms.
to
createEmptyArrayLiteral: 1175 ms.
createShallowArrayLiteral: 1187 ms.
createShallowObjectLiteral: 1195 ms.
with this CL, so up to 2x faster now.
Drive-by-fix: Also remove the unused CreateEmptyObjectLiteral builtin
and cleanup the names of the other builtins to be consistent with the
names of the TurboFan operators and Ignition bytecodes.
Bug: v8:6856
Change-Id: I453828d019b27c9aa1344edac0dd84e91a457097
Reviewed-on: https://chromium-review.googlesource.com/680656
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48140}
This speeds up the baseline performance of Object by 20%.
With this change, the callViaObject when run with --noopt
goes from 10718ms to 8577ms on the benchmark from:
http://benediktmeurer.de/2017/08/31/object-constructor-calls-in-webpack-bundles
Bug: v8:6772
Change-Id: Id0e54ba44204a1700885185ec360e1c56834fb73
Reviewed-on: https://chromium-review.googlesource.com/654900
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47888}
This removes support for reconstructing stack frames for full-codegen
from the deoptimizer. We no longer deoptimize to such code. This also
allows us to remove the {DeoptimizationOutputData} data structure.
R=jarin@chromium.org
BUG=v8:6409
Change-Id: Id28ef05aa985b6877b5c91926a7d7d0d6d6e661d
Reviewed-on: https://chromium-review.googlesource.com/535537
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45943}
This introduces new maps to track whether we have created at most one
closure. If we have created just one closure, Turbofan will
specialize the code to its context.
Review-Url: https://codereview.chromium.org/2680313002
Cr-Commit-Position: refs/heads/master@{#43108}
... and TypeFeedbackMetadata to FeedbackMetadata.
BUG=
Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c
Reviewed-on: https://chromium-review.googlesource.com/439244
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42999}
This correctly marks the {JSCreate} operator as potentially throwing,
since it might trigger a property access of the 'prototype' property
during instantiation. This is observable, can throw (not kNoThrow),
might have side-effects (not kNoWrite), or even trigger a lazy deopt
event (not kNoDeopt). The inlining logic has been adapted to wire up
control projections accordingly.
Note that this does not yet take care of the "after" frame-state which
is associated with the {JSCreate} node introduced by the inliner. We
still might re-evaluate the property access upon lazy deoptimization.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-5638
BUG=v8:5638
Review-Url: https://codereview.chromium.org/2671203003
Cr-Commit-Position: refs/heads/master@{#42981}
They have the same lifetime. It's a match!
Both structures are native context dependent and dealt with (creation,
clearing, gathering feedback) at the same time. By treating the spaces used
for literal boilerplates as feedback vector slots, we no longer have to keep
track of the materialized literal count elsewhere.
A follow-on CL removes even more parser infrastructure related to this count.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2655853010
Cr-Commit-Position: refs/heads/master@{#42771}
This puts lowering of {JSCreateClosure} operations behind a flag. For
now the benefit of inline allocating such closures is negligible, it
does increase code size, and breaks in combination with inlining based
on {SharedFunctionInfo}.
R=jarin@chromium.org
BUG=v8:2206
Review-Url: https://codereview.chromium.org/2636493002
Cr-Commit-Position: refs/heads/master@{#42331}
This changes the NewClosure interface descriptor, but ignores
the additional vector/slot arguments for now. The feedback vector
gets larger, as it holds a space for each literal array. A follow-on
CL will constructively use this space.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2614373002
Cr-Commit-Position: refs/heads/master@{#42146}
Add a more efficient encoding for state values that have a large number of
optimized-out inputs.
Review-Url: https://codereview.chromium.org/2509623002
Cr-Commit-Position: refs/heads/master@{#42088}
Reason for revert:
Speculative revert because of blocked roll: https://codereview.chromium.org/2596013002/
Original issue's description:
> [TypeFeedbackVector] Root literal arrays in function literals slots
>
> Literal arrays and feedback vectors for a function can be garbage
> collected if we don't have a rooted closure for the function, which
> happens often. It's expensive to come back from this (recreating
> boilerplates and gathering feedback again), and the cost is
> disproportionate if the function was inlined into optimized code.
>
> To guard against losing these arrays when we need them, we'll now
> create literal arrays when creating the feedback vector for the outer
> closure, and root them strongly in that vector.
>
> BUG=v8:5456
>
> Review-Url: https://codereview.chromium.org/2504153002
> Cr-Commit-Position: refs/heads/master@{#41893}
> Committed: 93df094081TBR=bmeurer@chromium.org,mlippautz@chromium.org,mvstanton@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2597163002
Cr-Commit-Position: refs/heads/master@{#41917}
Literal arrays and feedback vectors for a function can be garbage
collected if we don't have a rooted closure for the function, which
happens often. It's expensive to come back from this (recreating
boilerplates and gathering feedback again), and the cost is
disproportionate if the function was inlined into optimized code.
To guard against losing these arrays when we need them, we'll now
create literal arrays when creating the feedback vector for the outer
closure, and root them strongly in that vector.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2504153002
Cr-Commit-Position: refs/heads/master@{#41893}
eval() may introduce a scope which needs to be represented as a context at
runtime, e.g.,
eval('var x; let y; ()=>y')
introduces a variable y which needs to have a context allocated for it. However,
when traversing upwards to find the declaration context for a variable which leaks,
as the declaration of x does above, this context has to be understood to not be
a declaration context in sloppy mode.
This patch makes that distinction by introducing a different map for eval-introduced
contexts. A dynamic search for the appropriate context will continue past an eval
context to find the appropriate context. Marking contexts as eval contexts rather
than function contexts required updates in each compiler backend.
BUG=v8:5295, chromium:648719
Review-Url: https://codereview.chromium.org/2435023002
Cr-Commit-Position: refs/heads/master@{#41869}
There were once plans to generate cross-context code with TurboFan,
however that doesn't fit into the model anymore, and so all of this
is essentially dead untested code (and thus most likely already broken
in subtle ways). With this mode still in place it would also be a lot
harder to make inlining based on SharedFunctionInfo work.
BUG=v8:2206,v8:5499
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2406803002
Cr-Commit-Position: refs/heads/master@{#40109}
With this CL, we devolve all Constants introduced as they are with an object handle into
* Range - for integers
* Nan
* MinusZero
* OtherNumberConstant - for doubles
* HeapConstant
We reduce the amount we have to inspect an object handle during optimization. Also, simplifications result. For example, you never have to check if a Range contains a HeapConstant.
BUG=
Review-Url: https://codereview.chromium.org/2381523002
Cr-Commit-Position: refs/heads/master@{#40041}
If possible, take the constant map from the (known) native context for
JSCreateIterResultObject, so that subsequent map checks can be
eliminated in case of iterator inlining.
R=jarin@chromium.org
BUG=v8:3822
Review-Url: https://codereview.chromium.org/2394783002
Cr-Commit-Position: refs/heads/master@{#39974}
This will allow for chaining ScopeInfos together to form the same chains
as contexts chains currently do.
BUG=v8:5215
R=mstarzinger@chromium.org,marja@chromium.org,bmeurer@chromium.org,rmcilroy@chromium.org
Review-Url: https://codereview.chromium.org/2314483002
Cr-Commit-Position: refs/heads/master@{#39192}
Since the extension field is already used for the catch name, store a
ContextExtension there instead.
In the future, this will allow for chaining ScopeInfos together, so we
no longer need a context chain for lazy parsing / compilation.
BUG=v8:5215
R=bmeurer@chromium.org,neis@chromium.org,marja@chromium.org
Review-Url: https://codereview.chromium.org/2302013002
Cr-Commit-Position: refs/heads/master@{#39164}
Rebuilding (after touching certain files) is crazy slow because
includes are out of control.
Fixing it:
- Don't include stuff in headers unless necessary.
- Include the stuff you need, not some other stuff that happens to include the
stuff you need.
BUG=v8:5294
Review-Url: https://codereview.chromium.org/2268303002
Cr-Commit-Position: refs/heads/master@{#38818}
This fixes the SharedFunctionInfo::num_literals field for global builtin
functions (e.g. {Object} and friends) to be accurate. The field was not
being updated by Runtime_SetCode. It also removes the dangerous and by
now obsolete JSFunction::NumberOfLiterals accessor.
R=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2007943002
Cr-Commit-Position: refs/heads/master@{#36480}
Make JSCreateArguments eliminatable, and remove the need for frame
states on JSCreateArguments nodes being lowered to (optimized) stub
calls. Only the runtime fallback needs a frame state, because in that
case we need to ask the deoptimizer for arguments to inlined functions.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/1965013005
Cr-Commit-Position: refs/heads/master@{#36154}
This changes closure creation to lower to inline allocations when
possible instead of going through the FastNewClosureStub. It allows us
to leverage all advantages of inline allocations on closures. Note that
it is only safe to embed the raw entry point of the compile lazy stub
into the code, because that stub is immortal and immovable.
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/1573153002
Cr-Commit-Position: refs/heads/master@{#35499}
This reducer doesn't really add value, because:
(a) it is only concerned with JSCallFunction and JSToNumber, but when
we get to it, all JSCallFunction nodes will have been replaced by
Call nodes, and in the not so far future, we will also have
replaced almost all JSToNumber nodes with better code,
(b) and the reducer tries to be smart and use one of the outermost
contexts, but that might not be beneficial always; actually it
might even create longer live ranges and lead to more spilling
in some cases.
But most importantly, the JSContextRelaxation currently blocks inlining
based on SharedFunctionInfo, because it requires the inliner to check
the native context, which in turn requires JSFunction knowledge. So I'm
removing this reducer for now to unblock the more important inliner
changes.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1715633002
Cr-Commit-Position: refs/heads/master@{#34139}
This adds initial support for inline allocation of object and array
literals to the JSCreateLowering pass. It's basically identical to
what Crankshaft does.
This also unstages the TurboFan escape analysis, as the lowering seems
to trigger a bunch of bugs in it; those bugs will be fixed separately,
and we will re-enable escape analysis afterwards.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1698783002
Cr-Commit-Position: refs/heads/master@{#33972}
The FastNewStrictArgumentsStub is very similar to the recently added
FastNewRestParameterStub, it's actually almost a copy of it, except that
it doesn't have the fast case we have for the empty rest parameter. This
patch improves strict arguments in TurboFan and fullcodegen by up to 10x
compared to the previous version.
Also introduce proper JSSloppyArgumentsObject and JSStrictArgumentsObject
for the in-object properties instead of having them as constants in the
Heap class.
Drive-by-fix: Use this stub and the FastNewRestParameterStub in the
interpreter to avoid the runtime call overhead for strict arguments
and rest parameter creation.
R=jarin@chromium.orgTBR=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1693513002
Cr-Commit-Position: refs/heads/master@{#33925}
This moves the JSCreate related functionality from JSTypedLowering into
a dedicated JSCreateLowering reducer. This is in preparation of landing
the support for optimized literals in TurboFan, which would blow up
JSTypedLowering quite seriously otherwise.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1678833002
Cr-Commit-Position: refs/heads/master@{#33813}
