1. 20 Oct, 2017 2 commits
    • Mike Stanton's avatar
      [Turbofan] Model ClassOf as a simplified operator · c877c779
      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: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48786}
      c877c779
    • Benedikt Meurer's avatar
      [ic] Ensure that we make progress on KeyedLoadIC polymorphic name. · d5c19aa9
      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: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48784}
      d5c19aa9
  2. 19 Oct, 2017 3 commits
    • Tobias Tebbi's avatar
      Revert "Reland^4 "[turbofan] eagerly prune None types and deadness from the graph"" · 2bf01995
      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: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48749}
      2bf01995
    • Mike Stanton's avatar
      [Turbofan] Introduce StringToNumber opcode · d3797add
      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: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48741}
      d3797add
    • Mike Stanton's avatar
      [Turbofan] Model JSToBoolean as a simplified operator · 78fc6668
      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: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48727}
      78fc6668
  3. 18 Oct, 2017 1 commit
    • Tobias Tebbi's avatar
      Reland^4 "[turbofan] eagerly prune None types and deadness from the graph" · 1cee0e01
      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: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48660}
      1cee0e01
  4. 17 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Inline Function#bind in more cases. · 594803c9
      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: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48639}
      594803c9
  5. 16 Oct, 2017 2 commits
    • Mike Stanton's avatar
      [TurboFan] Model TypeOf as a simplified operator · 9b2a8c22
      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: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48613}
      9b2a8c22
    • Mike Stanton's avatar
      [Turbofan] Introduce TransitionAndStore[Non]NumberElement · c7990226
      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: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48579}
      c7990226
  6. 13 Oct, 2017 1 commit
  7. 12 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      Revert "Reland^3 "[turbofan] eagerly prune None types and deadness from the graph"" · e29fd74c
      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: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48482}
      e29fd74c
  8. 11 Oct, 2017 1 commit
    • Tobias Tebbi's avatar
      Reland^3 "[turbofan] eagerly prune None types and deadness from the graph" · 4cf47645
      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: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48469}
      4cf47645
  9. 09 Oct, 2017 7 commits
    • Tobias Tebbi's avatar
      Revert "Reland^2 "[turbofan] eagerly prune None types and deadness from the graph"" · 738e773b
      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: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48407}
      738e773b
    • Benedikt Meurer's avatar
      [collections] Refactor map entry lookup and make naming more consistent. · 130cee39
      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: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48404}
      130cee39
    • Benedikt Meurer's avatar
      [turbofan] Make New*Elements operator naming consistent. · 4fc7d17b
      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: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48399}
      4fc7d17b
    • Mike Stanton's avatar
      [Turbofan] Specialize TransitionAndStoreElement · b4f249e4
      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: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48387}
      b4f249e4
    • Tobias Tebbi's avatar
      Reland^2 "[turbofan] eagerly prune None types and deadness from the graph" · 6ddb5e7d
      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: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48366}
      6ddb5e7d
    • Benedikt Meurer's avatar
      [turbofan] Remove unused LoadHashMapValue operator. · bb793c28
      Benedikt Meurer authored
      Change-Id: I22bf46718ef14450bf5c18948f70f1b9b58ae949
      Reviewed-on: https://chromium-review.googlesource.com/706791Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48363}
      bb793c28
    • Benedikt Meurer's avatar
      [turbofan] Introduce LookupSigned32HashStorageIndex specialization of Map#get. · 1aa09302
      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: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48361}
      1aa09302
  10. 06 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Add support to inline new Array(n) calls. · 34de39bf
      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: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48348}
      34de39bf
  11. 04 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [es2015] Optimize Object.is baseline and interesting cases. · d4da17c6
      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: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48275}
      d4da17c6
  12. 30 Sep, 2017 2 commits
    • Benedikt Meurer's avatar
      [turbofan] Inline ArrayBuffer.isView into optimized code. · a953c6f1
      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: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48247}
      a953c6f1
    • Tobias Tebbi's avatar
      Revert "Reland "[turbofan] eagerly prune None types and deadness from the graph"" · 4651f644
      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: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48246}
      4651f644
  13. 29 Sep, 2017 1 commit
    • Tobias Tebbi's avatar
      Reland "[turbofan] eagerly prune None types and deadness from the graph" · 3c4bc27f
      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: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48232}
      3c4bc27f
  14. 28 Sep, 2017 2 commits
    • Clemens Hammacher's avatar
      Revert "[turbofan] eagerly prune None types and deadness from the graph" · 324e0a7a
      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: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48210}
      324e0a7a
    • Tobias Tebbi's avatar
      [turbofan] eagerly prune None types and deadness from the graph · e1cdda25
      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: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48208}
      e1cdda25
  15. 08 Sep, 2017 1 commit
  16. 04 Sep, 2017 1 commit
  17. 01 Sep, 2017 2 commits
    • Benedikt Meurer's avatar
      [turbofan] Optimize fast enum cache driven for..in. · f1ec44e2
      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: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47768}
      f1ec44e2
    • Michael Starzinger's avatar
      [turbofan] Support inline allocation of mapped outer arguments. · ed17bab8
      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: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47761}
      ed17bab8
  18. 28 Aug, 2017 3 commits
    • Jaroslav Sevcik's avatar
      [turbofan] Introduce SpeculativeSafeInteger(Add|Subtract) operators. · 0fd8c418
      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: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47640}
      0fd8c418
    • Benedikt Meurer's avatar
      [turbofan] Introduce a dedicated CompareMaps operator. · 8f1a92ce
      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: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47635}
      8f1a92ce
    • Benedikt Meurer's avatar
      [turbofan] Optimize O.p.hasOwnProperty inside for-in. · 06753c64
      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: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47632}
      06753c64
  19. 24 Aug, 2017 1 commit
  20. 21 Aug, 2017 2 commits
  21. 18 Aug, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Introduce a new MapGuard operator. · af4f1520
      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: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47417}
      af4f1520
  22. 11 Aug, 2017 1 commit
  23. 31 Jul, 2017 1 commit
  24. 28 Jul, 2017 1 commit