- 20 Oct, 2017 2 commits
-
-
Mike Stanton authored
JSClassOf may lower to a call to a builtin, and needs to be modeled in a way that the effect chain can be maintained. Bug: v8:6929 Change-Id: Ida332e6d85e2eb8b33fcad810d195ef3e897ccb0 Reviewed-on: https://chromium-review.googlesource.com/727204Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#48786}
-
Benedikt Meurer authored
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/730224Reviewed-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}
-
- 19 Oct, 2017 3 commits
-
-
Tobias Tebbi authored
This revert is manual, but almost completely automatic. It was just blocked by a single-line irrelevant refactoring change. This reverts commit 1cee0e01. Reason for revert: chromium:776256 Original change's description: > Reland^4 "[turbofan] eagerly prune None types and deadness from the graph" > > This fixes https://bugs.chromium.org/p/chromium/issues/detail?id=773954. > The issue was that in the EffectControlLinearizer, the effect input of an > {Unreachable} node was not updated, leaving a {Checkpoint} behind. > > This is a reland of 4cf47645 > Original change's description: > > Reland^3 "[turbofan] eagerly prune None types and deadness from the graph" > > > > This fixes the issues > > https://bugs.chromium.org/p/chromium/issues/detail?id=772873 > > and https://bugs.chromium.org/p/chromium/issues/detail?id=772872. > > > > One problem was that mutating an effect node into Unreachable confused > > the LoadElimination sidetables, so I just always create a new node now. > > > > The other problem was that UpdateBlockControl() was executed after > > UpdateEffectPhi() in the lazy case. This reverted the update to the Merge input. > > So now I make sure that UpdateEffectPhi() is always executed last. > > > > This is a reland of 6ddb5e7d > > Original change's description: > > > Reland^2 "[turbofan] eagerly prune None types and deadness from the graph" > > > > > > Now, the EffectControlLinearizer connects all occurrences of Unreachable to the > > > graph end. This fixes issues with later phases running DeadCodeElimination and > > > introducing new DeadValue nodes when processing uses of Unreachable. > > > > > > This is a reland of 3c4bc27f > > > Original change's description: > > > > Reland "[turbofan] eagerly prune None types and deadness from the graph" > > > > > > > > This is a reland of e1cdda25 > > > > Original change's description: > > > > > [turbofan] eagerly prune None types and deadness from the graph > > > > > > > > > > In addition to using the {Dead} node to prune dead control nodes and nodes that > > > > > depend on them, we introduce a {DeadValue} node representing an impossible value > > > > > that can occur at any position in the graph. The extended {DeadCodeElimination} > > > > > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into > > > > > the effect chain when possible. The remaining uses of {DeadValue} are handled > > > > > in {EffectControlLinearizer}, where we always have access to the effect chain. > > > > > In addition to explicitly introduced {DeadValue} nodes, we consider any value use > > > > > of a node with type {None} as dead. > > > > > > > > > > Bug: chromium:741225 > > > > > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655 > > > > > Reviewed-on: https://chromium-review.googlesource.com/641250 > > > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > > > Cr-Commit-Position: refs/heads/master@{#48208} > > > > > > > > Bug: chromium:741225 > > > > Change-Id: I21316913dae02864f7a6d7c9269405a79f054138 > > > > Reviewed-on: https://chromium-review.googlesource.com/692034 > > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > > Cr-Commit-Position: refs/heads/master@{#48232} > > > > > > Bug: chromium:741225 > > > Change-Id: I5702ec34856c075717162153adc765774453c45f > > > Reviewed-on: https://chromium-review.googlesource.com/702264 > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#48366} > > > > Bug: chromium:741225 > > Change-Id: I4054a694d2521c2e1f0c4a3ad0f3cf100b5c536f > > Reviewed-on: https://chromium-review.googlesource.com/709214 > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48469} > > Bug: chromium:741225 > Change-Id: Id9d4f3a3ae36cb3e38f80edcdba88efa7922ca24 > Reviewed-on: https://chromium-review.googlesource.com/715716 > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48660} TBR=jarin@chromium.org,tebbi@chromium.org,bmeurer@chromium.org Bug: chromium:741225 chromium:776256 Change-Id: Iaf2af3cb6dea5fdece43297cb9d987e7decc726d Reviewed-on: https://chromium-review.googlesource.com/727804 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#48749}
-
Mike Stanton authored
If we have good lower bound type information in simplified lowering that the input to PlainPrimitiveToNumber is a string, then we'd like to introduce a call to the StringToNumber builtin. However, this requires more careful management of the effect chain than we had previously. To fix this, introduce a StringToNumber opcode which defers the graph alteration until effect-control-linearization, when the effect chain is available for careful wiring. Bug: v8:6929 Change-Id: I4f0e43fe474a44d0dfa095a3a01caece649d82db Reviewed-on: https://chromium-review.googlesource.com/727934Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#48741}
-
Mike Stanton authored
Because the toboolean operator may lower to a builtin call (which is effectful in turbofan parlance after effect control linearization), it really should be encoded as a simplified operator, which can be optimized with respect for the effect chain in linearization. No new functionality here, rather a furniture rearrangement in the TurboFan node structure. Bug: v8:6929 Change-Id: I371fd22941397d5c28d13bded2738161d8da8275 Reviewed-on: https://chromium-review.googlesource.com/725721Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#48727}
-
- 18 Oct, 2017 1 commit
-
-
Tobias Tebbi authored
This fixes https://bugs.chromium.org/p/chromium/issues/detail?id=773954. The issue was that in the EffectControlLinearizer, the effect input of an {Unreachable} node was not updated, leaving a {Checkpoint} behind. This is a reland of 4cf47645 Original change's description: > Reland^3 "[turbofan] eagerly prune None types and deadness from the graph" > > This fixes the issues > https://bugs.chromium.org/p/chromium/issues/detail?id=772873 > and https://bugs.chromium.org/p/chromium/issues/detail?id=772872. > > One problem was that mutating an effect node into Unreachable confused > the LoadElimination sidetables, so I just always create a new node now. > > The other problem was that UpdateBlockControl() was executed after > UpdateEffectPhi() in the lazy case. This reverted the update to the Merge input. > So now I make sure that UpdateEffectPhi() is always executed last. > > This is a reland of 6ddb5e7d > Original change's description: > > Reland^2 "[turbofan] eagerly prune None types and deadness from the graph" > > > > Now, the EffectControlLinearizer connects all occurrences of Unreachable to the > > graph end. This fixes issues with later phases running DeadCodeElimination and > > introducing new DeadValue nodes when processing uses of Unreachable. > > > > This is a reland of 3c4bc27f > > Original change's description: > > > Reland "[turbofan] eagerly prune None types and deadness from the graph" > > > > > > This is a reland of e1cdda25 > > > Original change's description: > > > > [turbofan] eagerly prune None types and deadness from the graph > > > > > > > > In addition to using the {Dead} node to prune dead control nodes and nodes that > > > > depend on them, we introduce a {DeadValue} node representing an impossible value > > > > that can occur at any position in the graph. The extended {DeadCodeElimination} > > > > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into > > > > the effect chain when possible. The remaining uses of {DeadValue} are handled > > > > in {EffectControlLinearizer}, where we always have access to the effect chain. > > > > In addition to explicitly introduced {DeadValue} nodes, we consider any value use > > > > of a node with type {None} as dead. > > > > > > > > Bug: chromium:741225 > > > > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655 > > > > Reviewed-on: https://chromium-review.googlesource.com/641250 > > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > > Cr-Commit-Position: refs/heads/master@{#48208} > > > > > > Bug: chromium:741225 > > > Change-Id: I21316913dae02864f7a6d7c9269405a79f054138 > > > Reviewed-on: https://chromium-review.googlesource.com/692034 > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#48232} > > > > Bug: chromium:741225 > > Change-Id: I5702ec34856c075717162153adc765774453c45f > > Reviewed-on: https://chromium-review.googlesource.com/702264 > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48366} > > Bug: chromium:741225 > Change-Id: I4054a694d2521c2e1f0c4a3ad0f3cf100b5c536f > Reviewed-on: https://chromium-review.googlesource.com/709214 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48469} Bug: chromium:741225 Change-Id: Id9d4f3a3ae36cb3e38f80edcdba88efa7922ca24 Reviewed-on: https://chromium-review.googlesource.com/715716Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#48660}
-
- 17 Oct, 2017 1 commit
-
-
Benedikt Meurer authored
So far the inlining of Function#bind into TurboFan optimized code was limited to cases where TurboFan could infer the constant JSFunction that was bound. However we can easily extend that to cover JSBoundFunction as well, and obviously also take the LOAD_IC feedback if we don't have a known JSFunction or JSBoundFunction. This adds a new operator JSCreateBoundFunction that contains the logic for the creation of the bound function object and the arguments. On the micro-benchmarks we go from functionBindParameter0: 1239 ms. functionBindConstant0: 478 ms. functionBindBoundConstant0: 1256 ms. functionBindParameter1: 1278 ms. functionBindConstant1: 475 ms. functionBindBoundConstant1: 1253 ms. functionBindParameter2: 1431 ms. functionBindConstant2: 616 ms. functionBindBoundConstant2: 1437 ms. to functionBindParameter0: 462 ms. functionBindConstant0: 485 ms. functionBindBoundConstant0: 474 ms. functionBindParameter1: 478 ms. functionBindConstant1: 474 ms. functionBindBoundConstant1: 474 ms. functionBindParameter2: 617 ms. functionBindConstant2: 614 ms. functionBindBoundConstant2: 616 ms. which is a ~2.5x improvement. On the jshint benchmark in the web-tooling-benchmark we observe a 2-3% improvement, which corresponds to the time we had seen it running in the generic version. Bug: v8:6936, v8:6946 Change-Id: I940d13220ff35ae602dbaa33349ba4bbe0c9a9d3 Reviewed-on: https://chromium-review.googlesource.com/723080Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48639}
-
- 16 Oct, 2017 2 commits
-
-
Mike Stanton authored
Because the typeof operator may lower to a builtin call (which is effectful in turbofan parlance after effect control linearization), it really should be encoded as a simplified operator, which can be optimized with respect for the effect chain in linearization. No new functionality here, rather a furniture rearrangement in the TurboFan node structure. BUG=v8:6929 Change-Id: I38593e10956ebd57cecdd606c35f3f73efb1327e Reviewed-on: https://chromium-review.googlesource.com/718745Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#48613}
-
Mike Stanton authored
In Array.prototype.map, we have to store the map result in an output array. If we know we are storing objects, or special objects like boolean, rather than a number, then we can reduce the amount of checks we have to do to transition the output array to the appropriate ElementsKind. Likewise, if we know we've got floating point values, we can specialize appropriately to a double array. Bug: v8:6896 Change-Id: I375daf604562b53638ea749945c1a4c907e33547 Reviewed-on: https://chromium-review.googlesource.com/711845 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48579}
-
- 13 Oct, 2017 1 commit
-
-
Michael Starzinger authored
This adds and explicit check for the constructability of the new.target value in the lowering of {JSCall} nodes known to call Reflect.construct. The {JSConstruct} operator does not perform this check and relies on the implicit validity of new.target in all other use cases. R=jarin@chromium.org TEST=mjsunit/regress/regress-crbug-768080 BUG=chromium:768080 Change-Id: I7c1921e787bae64ba83de3eb08aa00fc5523e251 Reviewed-on: https://chromium-review.googlesource.com/718100Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48543}
-
- 12 Oct, 2017 1 commit
-
-
Benedikt Meurer authored
This reverts commit 4cf47645. Reason for revert: Broken effect chains detected by Clusterfuzz. Playing it safe for the 63 branch. Original change's description: > Reland^3 "[turbofan] eagerly prune None types and deadness from the graph" > > This fixes the issues > https://bugs.chromium.org/p/chromium/issues/detail?id=772873 > and https://bugs.chromium.org/p/chromium/issues/detail?id=772872. > > One problem was that mutating an effect node into Unreachable confused > the LoadElimination sidetables, so I just always create a new node now. > > The other problem was that UpdateBlockControl() was executed after > UpdateEffectPhi() in the lazy case. This reverted the update to the Merge input. > So now I make sure that UpdateEffectPhi() is always executed last. > > This is a reland of 6ddb5e7d > Original change's description: > > Reland^2 "[turbofan] eagerly prune None types and deadness from the graph" > > > > Now, the EffectControlLinearizer connects all occurrences of Unreachable to the > > graph end. This fixes issues with later phases running DeadCodeElimination and > > introducing new DeadValue nodes when processing uses of Unreachable. > > > > This is a reland of 3c4bc27f > > Original change's description: > > > Reland "[turbofan] eagerly prune None types and deadness from the graph" > > > > > > This is a reland of e1cdda25 > > > Original change's description: > > > > [turbofan] eagerly prune None types and deadness from the graph > > > > > > > > In addition to using the {Dead} node to prune dead control nodes and nodes that > > > > depend on them, we introduce a {DeadValue} node representing an impossible value > > > > that can occur at any position in the graph. The extended {DeadCodeElimination} > > > > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into > > > > the effect chain when possible. The remaining uses of {DeadValue} are handled > > > > in {EffectControlLinearizer}, where we always have access to the effect chain. > > > > In addition to explicitly introduced {DeadValue} nodes, we consider any value use > > > > of a node with type {None} as dead. > > > > > > > > Bug: chromium:741225 > > > > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655 > > > > Reviewed-on: https://chromium-review.googlesource.com/641250 > > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > > Cr-Commit-Position: refs/heads/master@{#48208} > > > > > > Bug: chromium:741225 > > > Change-Id: I21316913dae02864f7a6d7c9269405a79f054138 > > > Reviewed-on: https://chromium-review.googlesource.com/692034 > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#48232} > > > > Bug: chromium:741225 > > Change-Id: I5702ec34856c075717162153adc765774453c45f > > Reviewed-on: https://chromium-review.googlesource.com/702264 > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48366} > > Bug: chromium:741225 > Change-Id: I4054a694d2521c2e1f0c4a3ad0f3cf100b5c536f > Reviewed-on: https://chromium-review.googlesource.com/709214 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48469} TBR=jarin@chromium.org,tebbi@chromium.org Change-Id: Icf6a6af4feaafd4bde28cb7b996735ff91bb3810 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:741225 Reviewed-on: https://chromium-review.googlesource.com/715096Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48482}
-
- 11 Oct, 2017 1 commit
-
-
Tobias Tebbi authored
This fixes the issues https://bugs.chromium.org/p/chromium/issues/detail?id=772873 and https://bugs.chromium.org/p/chromium/issues/detail?id=772872. One problem was that mutating an effect node into Unreachable confused the LoadElimination sidetables, so I just always create a new node now. The other problem was that UpdateBlockControl() was executed after UpdateEffectPhi() in the lazy case. This reverted the update to the Merge input. So now I make sure that UpdateEffectPhi() is always executed last. This is a reland of 6ddb5e7d Original change's description: > Reland^2 "[turbofan] eagerly prune None types and deadness from the graph" > > Now, the EffectControlLinearizer connects all occurrences of Unreachable to the > graph end. This fixes issues with later phases running DeadCodeElimination and > introducing new DeadValue nodes when processing uses of Unreachable. > > This is a reland of 3c4bc27f > Original change's description: > > Reland "[turbofan] eagerly prune None types and deadness from the graph" > > > > This is a reland of e1cdda25 > > Original change's description: > > > [turbofan] eagerly prune None types and deadness from the graph > > > > > > In addition to using the {Dead} node to prune dead control nodes and nodes that > > > depend on them, we introduce a {DeadValue} node representing an impossible value > > > that can occur at any position in the graph. The extended {DeadCodeElimination} > > > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into > > > the effect chain when possible. The remaining uses of {DeadValue} are handled > > > in {EffectControlLinearizer}, where we always have access to the effect chain. > > > In addition to explicitly introduced {DeadValue} nodes, we consider any value use > > > of a node with type {None} as dead. > > > > > > Bug: chromium:741225 > > > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655 > > > Reviewed-on: https://chromium-review.googlesource.com/641250 > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#48208} > > > > Bug: chromium:741225 > > Change-Id: I21316913dae02864f7a6d7c9269405a79f054138 > > Reviewed-on: https://chromium-review.googlesource.com/692034 > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48232} > > Bug: chromium:741225 > Change-Id: I5702ec34856c075717162153adc765774453c45f > Reviewed-on: https://chromium-review.googlesource.com/702264 > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48366} Bug: chromium:741225 Change-Id: I4054a694d2521c2e1f0c4a3ad0f3cf100b5c536f Reviewed-on: https://chromium-review.googlesource.com/709214 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48469}
-
- 09 Oct, 2017 7 commits
-
-
Tobias Tebbi authored
This reverts commit 6ddb5e7d. Reason for revert: chromium:772873 chromium:772872 Original change's description: > Reland^2 "[turbofan] eagerly prune None types and deadness from the graph" > > Now, the EffectControlLinearizer connects all occurrences of Unreachable to the > graph end. This fixes issues with later phases running DeadCodeElimination and > introducing new DeadValue nodes when processing uses of Unreachable. > > This is a reland of 3c4bc27f > Original change's description: > > Reland "[turbofan] eagerly prune None types and deadness from the graph" > > > > This is a reland of e1cdda25 > > Original change's description: > > > [turbofan] eagerly prune None types and deadness from the graph > > > > > > In addition to using the {Dead} node to prune dead control nodes and nodes that > > > depend on them, we introduce a {DeadValue} node representing an impossible value > > > that can occur at any position in the graph. The extended {DeadCodeElimination} > > > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into > > > the effect chain when possible. The remaining uses of {DeadValue} are handled > > > in {EffectControlLinearizer}, where we always have access to the effect chain. > > > In addition to explicitly introduced {DeadValue} nodes, we consider any value use > > > of a node with type {None} as dead. > > > > > > Bug: chromium:741225 > > > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655 > > > Reviewed-on: https://chromium-review.googlesource.com/641250 > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#48208} > > > > Bug: chromium:741225 > > Change-Id: I21316913dae02864f7a6d7c9269405a79f054138 > > Reviewed-on: https://chromium-review.googlesource.com/692034 > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48232} > > Bug: chromium:741225 > Change-Id: I5702ec34856c075717162153adc765774453c45f > Reviewed-on: https://chromium-review.googlesource.com/702264 > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48366} TBR=jarin@chromium.org,tebbi@chromium.org Change-Id: Ib0f59b8463681abf6a9158112515aefae3c76b5f No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:741225 Reviewed-on: https://chromium-review.googlesource.com/707275Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#48407}
-
Benedikt Meurer authored
Rename the MapLookupHashIndex builtin to FindOrderedHashMapEntry and also rename the TurboFan operators LookupHashStorageIndex and LookupSigned32HashStorageIndex to FindOrderedHashMapEntry and FindOrderedHashMapEntryForInt32Key respectively. This way the naming is more consistent and it's immediately obvious from the operator name that this operator deals with OrderedHashMaps, which wasn't clear before. Also fix the result of the operation to be either -1 or the index of the entry relative to the hash table start (that is, no longer eagerly add hash table start plus value offset to the entry index). This removes this non-foldable integer additon from TurboFan code for both Map#get and Map#has. Drive-by-fix: Also provide more concrete types for the FindOrderedHashMapEntry operators. Bug: v8:5049 Change-Id: I418d107b806f3031a52a525cffc20456dc2342db Reviewed-on: https://chromium-review.googlesource.com/707414Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48404}
-
Benedikt Meurer authored
We no longer use the terminology "fast elements", so drop the "Fast" from both NewFastSmiOrObjectElements and NewFastDoubleElements operator names. Bug: v8:6399, v8:6901 Tbr: jarin@chromium.org Change-Id: Icc204623f2b459b0d0e172e26ddd73e29fe6c884 Reviewed-on: https://chromium-review.googlesource.com/707246Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48399}
-
Mike Stanton authored
We can improve performance of inlined Array.prototype.map if we statically know the type of the callback return result is a SignedSmall. Indeed, we no longer need bother with transitioning the output array, because we can store a SignedSmall (aka "Smi") anywhere. Bug: v8:6896 Change-Id: I140ce9a7c15ff77d05afeda6cda58f0560d922c8 Reviewed-on: https://chromium-review.googlesource.com/707139Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#48387}
-
Tobias Tebbi authored
Now, the EffectControlLinearizer connects all occurrences of Unreachable to the graph end. This fixes issues with later phases running DeadCodeElimination and introducing new DeadValue nodes when processing uses of Unreachable. This is a reland of 3c4bc27f Original change's description: > Reland "[turbofan] eagerly prune None types and deadness from the graph" > > This is a reland of e1cdda25 > Original change's description: > > [turbofan] eagerly prune None types and deadness from the graph > > > > In addition to using the {Dead} node to prune dead control nodes and nodes that > > depend on them, we introduce a {DeadValue} node representing an impossible value > > that can occur at any position in the graph. The extended {DeadCodeElimination} > > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into > > the effect chain when possible. The remaining uses of {DeadValue} are handled > > in {EffectControlLinearizer}, where we always have access to the effect chain. > > In addition to explicitly introduced {DeadValue} nodes, we consider any value use > > of a node with type {None} as dead. > > > > Bug: chromium:741225 > > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655 > > Reviewed-on: https://chromium-review.googlesource.com/641250 > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48208} > > Bug: chromium:741225 > Change-Id: I21316913dae02864f7a6d7c9269405a79f054138 > Reviewed-on: https://chromium-review.googlesource.com/692034 > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48232} Bug: chromium:741225 Change-Id: I5702ec34856c075717162153adc765774453c45f Reviewed-on: https://chromium-review.googlesource.com/702264Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#48366}
-
Benedikt Meurer authored
Change-Id: I22bf46718ef14450bf5c18948f70f1b9b58ae949 Reviewed-on: https://chromium-review.googlesource.com/706791Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48363}
-
Benedikt Meurer authored
This adds a new operator LookupSigned32HashStorageIndex, which is a specialization of the general LookupHashStorageIndex for Map#get that is used when TurboFan knows that the key is in Signed32 range. This improves the execution time of the ARES6 Basic test locally by around 5% and seems to make sense in general. Bug: v8:6410, v8:6354, v8:6278, v8:6344 Change-Id: I78dcbc9cc855a4109e1690d8cd14fbc88fd89861 Reviewed-on: https://chromium-review.googlesource.com/706787Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48361}
-
- 06 Oct, 2017 1 commit
-
-
Benedikt Meurer authored
Make calls like new Array(n) new A(n) (where A is a subclass of Array) inlinable into TurboFan. We do this by speculatively checking that n is an unsigned integer that is not greater than JSArray::kInitialMaxFastElementArray, and then lowering the backing store allocation to a builtin call. The speculative optimization is either protected by the AllocationSite for the Array constructor invocation (if we have one), or by a newly introduced global protector cell that is used for Array constructor invocations that don't have an AllocationSite, i.e. the ones from Array#map, Array#filter, or from subclasses of Array. Next step will be to implement the backing store allocations inline in TurboFan, but that requires Loop support in the GraphAssembler, so it's done as a separate CL. This should further boost the performance. This boosts the ARES6 ML benchmark by up to 8% on the steady state, and also improves monomorphic Array#map calls by around 20-25% on the initial setup. Bug: v8:6399 Tbr: ulan@chromium.org Change-Id: I7c8bdecf7c814ce52db6ee3051c3206a4f7d4bb6 Reviewed-on: https://chromium-review.googlesource.com/704639 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#48348}
-
- 04 Oct, 2017 1 commit
-
-
Benedikt Meurer authored
The Object.is builtin provides an entry point to the abstract operation SameValue, which properly distinguishes -0 and 0, and also identifies NaNs. Most of the time you don't need these, but rather just regular strict equality, but when you do, Object.is(o, -0) is the most readable way to check for minus zero. This is for example used in Node.js by formatNumber to properly print -0 for negative zero. However since the builtin thus far implemented as C++ builtin and TurboFan didn't know anything about it, Node.js considering to go with a more performant, less readable version (which also makes assumptions about the input value) in https://github.com/nodejs/node/pull/15726 until the performance of Object.is will be on par (so hopefully we can go back to Object.is in Node 9). This CL ports the baseline implementation of Object.is to CSA, which is pretty straight-forward since SameValue is already available in CodeStubAssembler, and inlines a few interesting cases into TurboFan, i.e. comparing same SSA node, and checking for -0 and NaN explicitly. On the micro-benchmarks we go from testNumberIsMinusZero: 1000 ms. testObjectIsMinusZero: 929 ms. testObjectIsNaN: 954 ms. testObjectIsSame: 793 ms. testStrictEqualSame: 104 ms. to testNumberIsMinusZero: 89 ms. testObjectIsMinusZero: 88 ms. testObjectIsNaN: 88 ms. testObjectIsSame: 86 ms. testStrictEqualSame: 105 ms. which is a nice 10x to 11x improvement and brings Object.is on par with strict equality for most cases. Drive-by-fix: Also refactor and optimize the SameValue check in the CodeStubAssembler to avoid code bloat (by not inlining StrictEqual into every user of SameValue, and also avoiding useless checks). Bug: v8:6882 Change-Id: Ibffd8c36511f219fcce0d89ed4e1073f5d6c6344 Reviewed-on: https://chromium-review.googlesource.com/700254Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48275}
-
- 30 Sep, 2017 2 commits
-
-
Benedikt Meurer authored
This improves performance of ArrayBuffer.isView by roughly 2.5x itself, and enables optimizations across ArrayBuffer.isView calls, i.e. map checks can be eliminated across. This was discovered in a related Node pull request (https://github.com/nodejs/node/pull/15663). Bug: v8:6868 Change-Id: I1d56ec385f8daa0e1d44d3bc4d6c9a5558ba4522 Reviewed-on: https://chromium-review.googlesource.com/691660Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48247}
-
Tobias Tebbi authored
This reverts commit 3c4bc27f. Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=770257 Original change's description: > Reland "[turbofan] eagerly prune None types and deadness from the graph" > > This is a reland of e1cdda25 > Original change's description: > > [turbofan] eagerly prune None types and deadness from the graph > > > > In addition to using the {Dead} node to prune dead control nodes and nodes that > > depend on them, we introduce a {DeadValue} node representing an impossible value > > that can occur at any position in the graph. The extended {DeadCodeElimination} > > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into > > the effect chain when possible. The remaining uses of {DeadValue} are handled > > in {EffectControlLinearizer}, where we always have access to the effect chain. > > In addition to explicitly introduced {DeadValue} nodes, we consider any value use > > of a node with type {None} as dead. > > > > Bug: chromium:741225 > > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655 > > Reviewed-on: https://chromium-review.googlesource.com/641250 > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48208} > > Bug: chromium:741225 > Change-Id: I21316913dae02864f7a6d7c9269405a79f054138 > Reviewed-on: https://chromium-review.googlesource.com/692034 > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48232} TBR=jarin@chromium.org,tebbi@chromium.org Change-Id: Ied8da411a9c8cbe4ed2e1d3e98a76162c2834c97 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:741225 chromium:770257 Reviewed-on: https://chromium-review.googlesource.com/693235Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#48246}
-
- 29 Sep, 2017 1 commit
-
-
Tobias Tebbi authored
This is a reland of e1cdda25 Original change's description: > [turbofan] eagerly prune None types and deadness from the graph > > In addition to using the {Dead} node to prune dead control nodes and nodes that > depend on them, we introduce a {DeadValue} node representing an impossible value > that can occur at any position in the graph. The extended {DeadCodeElimination} > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into > the effect chain when possible. The remaining uses of {DeadValue} are handled > in {EffectControlLinearizer}, where we always have access to the effect chain. > In addition to explicitly introduced {DeadValue} nodes, we consider any value use > of a node with type {None} as dead. > > Bug: chromium:741225 > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655 > Reviewed-on: https://chromium-review.googlesource.com/641250 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48208} Bug: chromium:741225 Change-Id: I21316913dae02864f7a6d7c9269405a79f054138 Reviewed-on: https://chromium-review.googlesource.com/692034Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#48232}
-
- 28 Sep, 2017 2 commits
-
-
Clemens Hammacher authored
This reverts commit e1cdda25. Reason for revert: Fails 'constructor-inlining' on GC-Stress bot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15270 Original change's description: > [turbofan] eagerly prune None types and deadness from the graph > > In addition to using the {Dead} node to prune dead control nodes and nodes that > depend on them, we introduce a {DeadValue} node representing an impossible value > that can occur at any position in the graph. The extended {DeadCodeElimination} > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into > the effect chain when possible. The remaining uses of {DeadValue} are handled > in {EffectControlLinearizer}, where we always have access to the effect chain. > In addition to explicitly introduced {DeadValue} nodes, we consider any value use > of a node with type {None} as dead. > > Bug: chromium:741225 > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655 > Reviewed-on: https://chromium-review.googlesource.com/641250 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48208} TBR=jarin@chromium.org,tebbi@chromium.org Change-Id: I9c175d47e2ee4b11a36ed90421202f2354610398 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:741225 Reviewed-on: https://chromium-review.googlesource.com/690080Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48210}
-
Tobias Tebbi authored
In addition to using the {Dead} node to prune dead control nodes and nodes that depend on them, we introduce a {DeadValue} node representing an impossible value that can occur at any position in the graph. The extended {DeadCodeElimination} prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into the effect chain when possible. The remaining uses of {DeadValue} are handled in {EffectControlLinearizer}, where we always have access to the effect chain. In addition to explicitly introduced {DeadValue} nodes, we consider any value use of a node with type {None} as dead. Bug: chromium:741225 Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655 Reviewed-on: https://chromium-review.googlesource.com/641250 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48208}
-
- 08 Sep, 2017 1 commit
-
-
Jaroslav Sevcik authored
The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
-
- 04 Sep, 2017 1 commit
-
-
Michael Starzinger authored
This adds support for the backing store of mapped arguments objects to escape analysis. It also unifies two simplified operators representing allocations of these backing stores into a single {NewArgumentsElements} operator and threads through the "mapped count" to the deoptimizer. R=tebbi@chromium.org Change-Id: I1864e29a5703348597b7b2e41deaf5fab73e2c93 Reviewed-on: https://chromium-review.googlesource.com/643208 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47800}
-
- 01 Sep, 2017 2 commits
-
-
Benedikt Meurer authored
This CL adds support to optimize for..in in fast enum-cache mode to the same degree that it was optimized in Crankshaft, without adding the same deoptimization loop that Crankshaft had with missing enum cache indices. That means code like for (var k in o) { var v = o[k]; // ... } and code like for (var k in o) { if (Object.prototype.hasOwnProperty.call(o, k)) { var v = o[k]; // ... } } which follows the https://eslint.org/docs/rules/guard-for-in linter rule, can now utilize the enum cache indices if o has only fast properties on the receiver, which speeds up the access o[k] significantly and reduces the pollution of the global megamorphic stub cache. For example the micro-benchmark in the tracking bug v8:6702 now runs faster than ever before: forIn: 1516 ms. forInHasOwnProperty: 1674 ms. forInHasOwnPropertySafe: 1595 ms. forInSum: 2051 ms. forInSumSafe: 2215 ms. Compared to numbers from V8 5.8 which is the last version running with Crankshaft forIn: 1641 ms. forInHasOwnProperty: 1719 ms. forInHasOwnPropertySafe: 1802 ms. forInSum: 2226 ms. forInSumSafe: 2409 ms. and V8 6.0 which is the current stable version with TurboFan: forIn: 1713 ms. forInHasOwnProperty: 5417 ms. forInHasOwnPropertySafe: 5324 ms. forInSum: 7556 ms. forInSumSafe: 11067 ms. It also improves the throughput on the string-fasta benchmark by around 7-10%, and there seems to be a ~5% improvement on the Speedometer/React benchmark locally. For this to work, the ForInPrepare bytecode was split into ForInEnumerate and ForInPrepare, which is very similar to how it was handled in Fullcodegen initially. In TurboFan we introduce a new operator LoadFieldByIndex that does the dynamic property load. This also removes the CheckMapValue operator again in favor of just using LoadField, ReferenceEqual and CheckIf, which work automatically with the EscapeAnalysis and the BranchConditionElimination. Bug: v8:6702 Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a Reviewed-on: https://chromium-review.googlesource.com/645949 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47768}
-
Michael Starzinger authored
This adds support for lowering {JSCreateArguments} within outermost frames of type {CreateArgumentsType::kMappedArguments}. It will hence enable escape analysis to work with such objects and allow for further optimization. This also adds a new {NewMappedArgumentsElements} simplfied operator. Note that escape analysis support for this new operator will be done as a follow-up. R=tebbi@chromium.org Change-Id: I0e2fac25c654f796433f57b116964053b6b68635 Reviewed-on: https://chromium-review.googlesource.com/641454 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#47761}
-
- 28 Aug, 2017 3 commits
-
-
Jaroslav Sevcik authored
This is just a refactoring in preparation for typing the speculative integer operation as safe integers. Bug: v8:5267 Change-Id: I56da91a72655a0733b2cf04afcf33cb1d2aa1415 Reviewed-on: https://chromium-review.googlesource.com/637830Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47640}
-
Benedikt Meurer authored
Instead of introducing a lot of explicit branching in the JSNativeContextSpecialization for polymorphic property accesses that cannot be folded into a single LoadField/StoreField, and which are mostly invisible and not optimizable for later passes, we now have a single CompareMaps operator that takes a set of maps (like the CheckMaps operator) and produces a boolean indicating the result of the comparison. R=jarin@chromium.org Bug: v8:6761 Change-Id: Iee8788e915b762d542acb54feb9931346e442dc0 Reviewed-on: https://chromium-review.googlesource.com/636365Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47635}
-
Benedikt Meurer authored
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}
-
- 24 Aug, 2017 1 commit
-
-
Michael Starzinger authored
This introduces a {DebugAbort} machine-level operator as well as the corresponding {ArchDebugAbort} backend instruction. The goal of this is to speed up snapshot generation due to cheaper "CSA-asserts". R=jgruber@chromium.org BUG=v8:6688 Bug: v8:6688 Change-Id: If45f7da0652d4bb920c51ab7a7c41f9670434bbb Also-By: jgruber@chromium.org Reviewed-on: https://chromium-review.googlesource.com/628560Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47568}
-
- 21 Aug, 2017 2 commits
-
-
Albert Mingkun Yang authored
The new node behave the same as its counterpart, CallCFunction, with the additional saving and restoring caller saved registers before and after the function call. Bug: chromium:749486 Change-Id: I0a1dfb2e4e55f7720541a00e6d16fd20220f39ed Reviewed-on: https://chromium-review.googlesource.com/620709 Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#47479}
-
Camillo Bruni authored
The quite common empty object literal doesn't need an AllocationSite since it starts off with the general ElementsKind. By using a separate bytecode we can directly instantiate the empty object without jumping to the runtime first. Note: this experimentally disables pretenuring for empty object literals. Depending on the outcome of our benchmarks pretenuring will be enabled again or fully removed for empty object literals. Bug: v8:6211 Change-Id: I2fee81cbefc70865fc436dbd3bc5fc8de04db91c Reviewed-on: https://chromium-review.googlesource.com/577555 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47467}
-
- 18 Aug, 2017 1 commit
-
-
Benedikt Meurer authored
The MapGuard node sits in the effect chain as a hint for other optimization passes that a certain value has a certain (set of) map(s) guarded by checks on the control chain. This is useful to learn from explicit control flow inserted for polymorphic property accesses, and then used as part of the polymorphic inlining. This change improves the score on the Octane/DeltaBlue benchmark by around 7-8% and the score on the Octane/Richards benchmark by like 3% on average. Bug: v8:5267 Change-Id: Id0b0b2c72e6a9342d5750a0d62cf6be6fb8c5916 Also-By: jarin@chromium.org Reviewed-on: https://chromium-review.googlesource.com/620586 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47417}
-
- 11 Aug, 2017 1 commit
-
-
Benedikt Meurer authored
These operators were only used by the old asm.js pipeline (with fullcodegen and the AstGraphBuilder). When going through the new pipeline, accesses to TypedArrays are handled by the native context specialization during inlining. Bug: v8:6409 Change-Id: Ib9b888c0b96f297a335580ee42dfa951bde566be Reviewed-on: https://chromium-review.googlesource.com/612347Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47322}
-
- 31 Jul, 2017 1 commit
-
-
Tobias Tebbi authored
Reland of https://chromium-review.googlesource.com/c/591667/, removing thread-local variable Bug: Change-Id: Ia9bc73be4a46a6bf052220726193c8b6634eb73e Reviewed-on: https://chromium-review.googlesource.com/593559Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#47001}
-
- 28 Jul, 2017 1 commit
-
-
Tobias Tebbi authored
This reverts commit ccd8bb69. Reason for revert: https://build.chromium.org/p/client.v8.fyi/builders/Mac%20Release%20%28Intel%29/builds/2643 Original change's description: > Reland: [turbofan] staging new implementation of escape analysis > > Reland of https://chromium-review.googlesource.com/c/565720, fixing compilation issues on the waterfall. > > Bug: > Change-Id: Ide4f1ea4470e946820edc990c9bf027f04844efe > Reviewed-on: https://chromium-review.googlesource.com/591667 > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#46975} TBR=jarin@chromium.org,tebbi@chromium.org Change-Id: I30016fd8d71535c02bab8678b02147195c3e97a6 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/591672Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#46980}
-