Array.prototype.reduce[Right] used a lazy deoptimization frame
state for an eager deopt point.
Bug: v8:7336, chromium:804096
Change-Id: I720f9e049bd6b396e025fa59192fdbc6b4f18647
Reviewed-on: https://chromium-review.googlesource.com/878120
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50752}
- Remove unused deoptimization reasons.
- Replace most uses of kNoReason with an actual reason (some are new).
- Rename kNoReason to kUnknown.
Bug:
Change-Id: Ia8df54fca0f0f4885ef0c3523ce8f67b557a635d
Reviewed-on: https://chromium-review.googlesource.com/839421
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50440}
This introduces a JSNegate operator and lowers it either to a
speculative multiplication with -1 (when we have Number feedback)
or to a stub call. The stub is also new.
R=jarin@chromium.org
Bug: v8:6791
Change-Id: I8e20333fe49cc6088d2d10777be982e42eed2412
Reviewed-on: https://chromium-review.googlesource.com/774718
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49538}
In the special case of KeyedLoadIC, where the key that is passed in is a
Name that is always the same we only checked for identity in both the
stub and the TurboFan case, which works fine for symbols and internalized
strings, but doesn't really work with non-internalized strings, where
the identity check will fail, the runtime will internalize the string,
and the IC will then see the original internalized string again and not
progress in the feedback lattice. This leads to tricky deoptimization
loops in TurboFan and constantly missing ICs.
This adds fixes the stub to always try to internalize strings first
when the identity check fails and then doing the check again. If the
name is not found in the string table we miss, since in that case the
string cannot match the previously recorded feedback name (which is
always a unique name).
In TurboFan we represent this checks with new CheckEqualsSymbol and
CheckEqualsInternalizedString operators, which validate the previously
recorded feedback, and the CheckEqualsInternalizedString operator does
the attempt to internalize the input.
Bug: v8:6936, v8:6948, v8:6969
Change-Id: I3f3b4a587c67f00f7c4b60d239eb98a9626fe04a
Reviewed-on: https://chromium-review.googlesource.com/730224
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48784}
CheckIf is lowered to DeoptimizeIfNot, but there is no deoptimization
reason given in the deopt if that check fails (the reason is hardcoded
to "no reason"). These deopts are annoying to track down.
This patch makes CheckIf an operator with a DeoptimizeReason parameter,
which is passed through to the DeoptimizeIfNot when lowered.
A couple of checks are converted to give good deoptimize reasons (some
new reasons are introduced), and the others are defaulted to kNoReason
until someone else finds a use for them.
Change-Id: I7e910cc9579ccf978dfe9d270ba7b98c8f6c2492
Reviewed-on: https://chromium-review.googlesource.com/716479
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48506}
In the BytecodeGraphBuilder we insert a SOFT deopt whenever we see an
IC whose state is UNINITIALIZED, i.e. a LOAD_IC or a STORE_IC. This
greatly reduces the size of the generated graphs (and also helps to
improve generated code quality). However for COMPARE_IC and BINARY_OP_IC
we used to stick in the generic JavaScript node instead, which does
generate code and might block optimizations because its sitting in
the effect chain. This is changed now to always SOFT deopt for
UNINITIALIZED instead, consistently with the other ICs.
Bug: v8:6760
Change-Id: I2ac7469fa86512a2fd909fdde2c6425977694811
Reviewed-on: https://chromium-review.googlesource.com/645858
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47771}
Optimize the common pattern
for (var i in o) {
if (Object.prototype.hasOwnProperty.call(o, i)) {
// do something
}
}
which is part of the guard-for-in style in ESLint (see the documentation
at https://eslint.org/docs/rules/guard-for-in for details). This pattern
also shows up in React and Ember applications quite a lot (and is tested
by the appropriate Speedometer benchmarks, although not dominating those
benchmarks, since they spent a lot of time in non-TurboFan'ed code).
This improves the forInHasOwnProperty and forInHasOwnPropertySafe micro-
benchmarks in v8:6702, which look like this
function forInHasOwnProperty(o) {
var result = 0;
for (var i in o) {
if (o.hasOwnProperty(i)) {
result += 1;
}
}
return result;
}
function forInHasOwnPropertySafe(o) {
var result = 0;
for (var i in o) {
if (Object.prototype.hasOwnProperty.call(o, i)) {
result += 1;
}
}
return result;
}
by around 4x and allows for additional optimizations in the future, by
also elimiating the megamorphic load when accessing the enumerated
properties.
This changes the interpreter ForInNext bytecode to collect more precise
feedback about the for-in state, which now consists of three individual
states: UNINITIALIZED, MEGAMORPHIC and GENERIC. The MEGAMORPHIC state
means that the ForInNext has only seen objects with a usable enum cache
thus far, whereas GENERIC means that we have seen some slow-mode for..in
objects as well.
R=jarin@chromium.org
Bug: v8:6702
Change-Id: Ibcd75ea9b58c3b4f9219f11bc37eb04a2b985604
Reviewed-on: https://chromium-review.googlesource.com/636964
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47632}
Similar to JSCall, we can also replace uninitialized JSConstruct nodes
with SOFT deopts to ensure that we don't generate unnecessary dead code.
This for example shows up in the hot parts of the Node event emitter
currently where the generic code for handling events with 4 or more
parameters might not have been run, but we still generate most of the
code because the new Array call in the beginning is not turned into
a SOFT deopt immediately.
Drive-by-fix: Also refactor the BytecodeGraphBuilder's handling of
Construct bytecodes a bit to reduce the amount of code duplication.
BUG=v8:4551, v8:5267
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2958253002
Cr-Commit-Position: refs/heads/master@{#46339}
Introduce a new Symbol comparison feedback bit in the lattice and
collect that feedback on Equal/StrictEqual in Ignition. Utilize this
feedback in TurboFan by adding a dedicated CheckSymbol operator to
check for symbol inputs. This way we can optimize Symbol comparison
where TurboFan doesn't know anything statically about either side, or
abstract equality comparisons where TurboFan doesn't statically know
anything about one side.
BUG=v8:6278,v8:6344,v8:6423
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2893263002
Cr-Commit-Position: refs/heads/master@{#45455}
For inputs to truncating binary operations like <<, | or >>>, support
all Oddballs not just undefined, true and false. This unifies treatment
of these truncations in Crankshaft and TurboFan, and is very easy
nowadays, since the memory layout of Oddball and HeapNumber is
compatible.
R=yangguo@chromium.org
BUG=v8:5400
Review-Url: https://codereview.chromium.org/2452193003
Cr-Commit-Position: refs/heads/master@{#40608}
If a JSCallFunction node doesn't have any callee information, either
from feedback taken on input nodes, i.e. on property loads, or from
the CallIC, we insert a soft deoptimization exit instead.
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2361773002
Cr-Commit-Position: refs/heads/master@{#39619}
So far TurboFan wasn't adding the deoptimization reasons for eager/soft
deoptimization exits that can be used by either the DevTools profiler or
the --trace-deopt flag. This adds basic support for deopt reasons on
Deoptimize, DeoptimizeIf and DeoptimizeUnless nodes and threads through
the reasons to the code generation.
Also moves the DeoptReason to it's own file (to resolve include cycles)
and drops unused reasons.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2161543002
Cr-Commit-Position: refs/heads/master@{#37823}
