AuroraMiddleware/v8
1
0
Fork 0
Code Issues 2 Pull Requests Releases Wiki Activity
4cb88e3ab4
v8/src/deoptimize-reason.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

100 lines
6.2 KiB
C
Raw Normal View History

[turbofan] Add support for eager/soft deoptimization reasons. 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}
2016-07-18 09:23:28 +00:00
// Copyright 2016 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
#ifndef V8_DEOPTIMIZE_REASON_H_
#define V8_DEOPTIMIZE_REASON_H_
#include "src/globals.h"
namespace v8 {
namespace internal {
[turbofan] Optimize O.p.hasOwnProperty inside for-in. 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}
2017-08-28 05:26:15 +00:00
#define DEOPTIMIZE_REASON_LIST(V) \
V(AccessCheck, "Access check needed") \
V(NoReason, "no reason") \
[turbofan] Add deopt reason to CheckIf 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}
2017-10-12 15:28:53 +00:00
V(ArrayBufferWasNeutered, "array buffer was neutered") \
[turbofan] Optimize O.p.hasOwnProperty inside for-in. 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}
2017-08-28 05:26:15 +00:00
V(ConstantGlobalVariableAssignment, "Constant global variable assignment") \
V(ConversionOverflow, "conversion overflow") \
[turbofan] Add deopt reason to CheckIf 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}
2017-10-12 15:28:53 +00:00
V(CowArrayElementsChanged, "copy-on-write array's elements changed") \
[turbofan] Optimize O.p.hasOwnProperty inside for-in. 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}
2017-08-28 05:26:15 +00:00
V(DivisionByZero, "division by zero") \
V(ExpectedHeapNumber, "Expected heap number") \
V(ExpectedSmi, "Expected smi") \
V(ForcedDeoptToRuntime, "Forced deopt to runtime") \
V(Hole, "hole") \
[turbofan] Add deopt reason to CheckIf 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}
2017-10-12 15:28:53 +00:00
V(IndexNameMismatch, "index and name do not match in access") \
[turbofan] Optimize O.p.hasOwnProperty inside for-in. 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}
2017-08-28 05:26:15 +00:00
V(InstanceMigrationFailed, "instance migration failed") \
V(InsufficientTypeFeedbackForCall, "Insufficient type feedback for call") \
V(InsufficientTypeFeedbackForCallWithArguments, \
"Insufficient type feedback for call with arguments") \
V(InsufficientTypeFeedbackForConstruct, \
"Insufficient type feedback for construct") \
V(FastPathFailed, "Falling off the fast path") \
V(InsufficientTypeFeedbackForForIn, "Insufficient type feedback for for-in") \
[turbofan] Utilize UNINITIALIZED state of CompareIC and BinaryOpIC. 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}
2017-09-01 10:29:50 +00:00
V(InsufficientTypeFeedbackForBinaryOperation, \
"Insufficient type feedback for binary operation") \
V(InsufficientTypeFeedbackForCompareOperation, \
"Insufficient type feedback for compare operation") \
[turbofan] Optimize O.p.hasOwnProperty inside for-in. 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}
2017-08-28 05:26:15 +00:00
V(InsufficientTypeFeedbackForGenericNamedAccess, \
"Insufficient type feedback for generic named access") \
V(InsufficientTypeFeedbackForGenericKeyedAccess, \
"Insufficient type feedback for generic keyed access") \
V(KeyIsNegative, "key is negative") \
V(LostPrecision, "lost precision") \
V(LostPrecisionOrNaN, "lost precision or NaN") \
V(MementoFound, "memento found") \
V(MinusZero, "minus zero") \
V(NaN, "NaN") \
V(NegativeKeyEncountered, "Negative key encountered") \
V(NegativeValue, "negative value") \
V(NoCache, "no cache") \
V(NotAHeapNumber, "not a heap number") \
V(NotAHeapNumberUndefined, "not a heap number/undefined") \
V(NotAJavaScriptObject, "not a JavaScript object") \
V(NotANumberOrOddball, "not a Number or Oddball") \
V(NotASmi, "not a Smi") \
V(NotASymbol, "not a Symbol") \
V(OutOfBounds, "out of bounds") \
V(OutsideOfRange, "Outside of range") \
V(Overflow, "overflow") \
V(Proxy, "proxy") \
[turbofan] Add deopt reason to CheckIf 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}
2017-10-12 15:28:53 +00:00
V(ReceiverNotAGlobalProxy, "receiver was not a global proxy") \
[turbofan] Optimize O.p.hasOwnProperty inside for-in. 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}
2017-08-28 05:26:15 +00:00
V(ReceiverWasAGlobalObject, "receiver was a global object") \
V(Smi, "Smi") \
V(TooManyArguments, "too many arguments") \
V(TracingElementsTransitions, "Tracing elements transitions") \
V(TypeMismatchBetweenFeedbackAndConstant, \
"Type mismatch between feedback and constant") \
V(UnexpectedCellContentsInConstantGlobalStore, \
"Unexpected cell contents in constant global store") \
V(UnexpectedCellContentsInGlobalStore, \
"Unexpected cell contents in global store") \
V(UnexpectedObject, "unexpected object") \
V(UnknownMapInPolymorphicAccess, "Unknown map in polymorphic access") \
V(UnknownMapInPolymorphicCall, "Unknown map in polymorphic call") \
V(UnknownMapInPolymorphicElementAccess, \
"Unknown map in polymorphic element access") \
V(UnknownMap, "Unknown map") \
V(ValueMismatch, "value mismatch") \
V(WrongInstanceType, "wrong instance type") \
V(WrongMap, "wrong map") \
V(UndefinedOrNullInForIn, "null or undefined in for-in") \
[turbofan] Add support for eager/soft deoptimization reasons. 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}
2016-07-18 09:23:28 +00:00
V(UndefinedOrNullInToObject, "null or undefined in ToObject")
enum class DeoptimizeReason : uint8_t {
#define DEOPTIMIZE_REASON(Name, message) k##Name,
DEOPTIMIZE_REASON_LIST(DEOPTIMIZE_REASON)
#undef DEOPTIMIZE_REASON
};
std::ostream& operator<<(std::ostream&, DeoptimizeReason);
size_t hash_value(DeoptimizeReason reason);
Reland of Fix compiler warnings on "make android_arm" (patchset #1 id:1 of https://codereview.chromium.org/2286163002/ ) Reason for revert: Roll was unstuck before the revert landed => reland Original issue's description: > Revert of Fix compiler warnings on "make android_arm" (patchset #1 id:1 of https://codereview.chromium.org/2264283007/ ) > > Reason for revert: > Speculative revert because of roll blocker https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/2241 > > Original issue's description: > > Fix compiler warnings on "make android_arm" > > > > Committed: https://crrev.com/3e809a6129d0097529c885579ac46e4acf4e99f6 > > Cr-Commit-Position: refs/heads/master@{#38937} > > TBR=bmeurer@chromium.org,jkummerow@chromium.org > # Not skipping CQ checks because original CL landed more than 1 days ago. > > Committed: https://crrev.com/d992c1f52f116930239ed90cc033442047e789b4 > Cr-Commit-Position: refs/heads/master@{#38961} TBR=bmeurer@chromium.org,jkummerow@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2285113002 Cr-Commit-Position: refs/heads/master@{#38962}
2016-08-28 21:03:07 +00:00
char const* DeoptimizeReasonToString(DeoptimizeReason reason);
[turbofan] Add support for eager/soft deoptimization reasons. 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}
2016-07-18 09:23:28 +00:00
} // namespace internal
} // namespace v8
#endif // V8_DEOPTIMIZE_REASON_H_
Reference in New Issue Copy Permalink