1. 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
  2. 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
  3. 08 Sep, 2017 1 commit
  4. 04 Sep, 2017 1 commit
  5. 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
  6. 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
  7. 24 Aug, 2017 1 commit
  8. 21 Aug, 2017 2 commits
  9. 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
  10. 11 Aug, 2017 1 commit
  11. 31 Jul, 2017 1 commit
  12. 28 Jul, 2017 4 commits
  13. 27 Jul, 2017 1 commit
  14. 25 Jul, 2017 1 commit
  15. 20 Jul, 2017 1 commit
    • Adam Klein's avatar
      Revert "[literals] Introduce CreateEmptyArrayLiteral Bytecode" · 62f83377
      Adam Klein authored
      This reverts commit 4851745f.
      
      Reason for revert: Top crasher on Canary, see https://crbug.com/746935
      
      Original change's description:
      > [literals] Introduce CreateEmptyArrayLiteral Bytecode
      > 
      > Empty Array literals are amongst the most commonly used literal types on our
      > top25 page list. Using a custom bytecode we can drop the boilerplate for empty
      > Array literals alltogether. However, we still need a proper AllocationSite to
      > track ElementsKind transitions.
      > 
      > Bug: v8:6211
      > Change-Id: Id5dbdac0ea8e24dd474e679c902c6e4a2957af1d
      > Reviewed-on: https://chromium-review.googlesource.com/567079
      > Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46752}
      
      TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,cbruni@chromium.org,ishell@chromium.org,rmcilroy@google.com
      Bug: v8:6211, chromium:746935
      
      Change-Id: Ibf19a923688c071d03bad8661a10e08f8414db56
      Reviewed-on: https://chromium-review.googlesource.com/580193
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46804}
      62f83377
  16. 19 Jul, 2017 2 commits
  17. 13 Jul, 2017 1 commit
  18. 10 Jul, 2017 1 commit
    • Jaroslav Sevcik's avatar
      Initial optimization of Map.prototype.(get|has) in Turbofan. · aba708a1
      Jaroslav Sevcik authored
      This introduces a new builtin (MapLookupHashIndex) and uses it
      in Turbofan to compute Map.p.get and Map.p.has.
      
      I have also refactored the existing CSA builtins for Map.p.get and 
      Map.p.has to use the new builtin under the hood.
      
      The code for the lookup has been also improved.
      - Specialized lookups for smis, strings, heap numbers and everything else.
        - the advantage is that we can use fast equalities for the lookup.
        - strings can likely be optimized further if we care about the 
          internalized string fast case.
      - Instead of a call to runtime to get the hash code, we now call C directly.
      
      In the Turbofan implementation itself, there are no special optimizations yet.
      The next step is to teach load elimination to reuse the indexes from
      previous calls of MapLookupHashIndex. 
      
      BUG=v8:6410
      
      Change-Id: I0b1a70493eb031d444e51002f6b2cc1f30ea2b68
      Reviewed-on: https://chromium-review.googlesource.com/560169Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46510}
      aba708a1
  19. 26 Jun, 2017 1 commit
  20. 21 Jun, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Introduce new JSConstructWithArrayLike operator. · 21701297
      bmeurer authored
      Add a new JSConstructWithArrayLike operator that is backed by the
      ConstructWithArrayLike builtin (similar to what was done before
      for the JSCallWithArrayLike operator), and use that operator to
      optimize Reflect.construct inlining in TurboFan. This is handled
      uniformly with JSConstructWithSpread in the JSCallReducer.
      
      Also add missing test coverage for Reflect.construct in optimized
      code, especially for some interesting corner cases.
      
      R=petermarshall@chromium.org
      BUG=v8:4587,v8:5269
      
      Review-Url: https://codereview.chromium.org/2949813002
      Cr-Commit-Position: refs/heads/master@{#46087}
      21701297
  21. 20 Jun, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Introduce new JSCallWithArrayLike operator. · 767ce788
      bmeurer authored
      Add a new JSCallWithArrayLike operator that is backed by the
      CallWithArrayLike builtin, and use that operator for both
      Function.prototype.apply and Reflect.apply inlining. Also unify
      the handling of JSCallWithArrayLike and JSCallWithSpread in
      the JSCallReducer to reduce the copy&paste overhead.
      
      Drive-by-fix: Add a lot of test coverage for Reflect.apply and
      Function.prototype.apply in optimized code, especially for some
      corner cases, which was missing so far.
      
      BUG=v8:4587,v8:5269
      R=petermarshall@chromium.org
      
      Review-Url: https://codereview.chromium.org/2950773002
      Cr-Commit-Position: refs/heads/master@{#46041}
      767ce788
  22. 13 Jun, 2017 2 commits
    • bbudge's avatar
      [WASM] Simplify SIMD shuffle opcodes. · 5d7039ea
      bbudge authored
      - Eliminates S32x4Shuffle, S16x8Shuffle opcodes. All shuffles are subsumed
        by S8x16Shuffle. This aligns us with the latest WASM SIMD spec.
      
      LOG=N
      BUG=v8:6020
      
      Review-Url: https://codereview.chromium.org/2923103003
      Cr-Commit-Position: refs/heads/master@{#45929}
      5d7039ea
    • bmeurer's avatar
      [builtins] Properly optimize Object.prototype.isPrototypeOf. · b11c557d
      bmeurer authored
      Port the baseline implementation of Object.prototype.isPrototypeOf to
      the CodeStubAssembler, sharing the existing prototype chain lookup logic
      with the instanceof / OrdinaryHasInstance implementation. Based on that,
      do the same in TurboFan, introducing a new JSHasInPrototypeChain
      operator, which encapsulates the central prototype chain walk logic.
      
      This speeds up Object.prototype.isPrototypeOf by more than a factor of
      four, so that the code
      
        A.prototype.isPrototypeOf(a)
      
      is now performance-wise on par with
      
        a instanceof A
      
      for the case where A is a regular constructor function and a is an
      instance of A.
      
      Since instanceof does more than just the fundamental prototype chain
      lookup, it was discovered in Node core that O.p.isPrototypeOf would
      be a more appropriate alternative for certain sanity checks, since
      it's less vulnerable to monkey-patching. In addition, the Object
      builtin would also avoid the performance-cliff associated with
      instanceof (due to the Symbol.hasInstance hook), as for example hit
      by https://github.com/nodejs/node/pull/13403#issuecomment-305915874.
      The main blocker was the missing performance of isPrototypeOf, since
      it was still a JS builtin backed by a runtime call.
      
      This CL also adds more test coverage for the
      Object.prototype.isPrototypeOf builtin, especially when called from
      optimized code.
      
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
      BUG=v8:5269,v8:5989,v8:6483
      R=jgruber@chromium.org
      
      Review-Url: https://codereview.chromium.org/2934893002
      Cr-Commit-Position: refs/heads/master@{#45925}
      b11c557d
  23. 08 Jun, 2017 3 commits
  24. 07 Jun, 2017 2 commits
  25. 06 Jun, 2017 1 commit
  26. 29 May, 2017 1 commit
  27. 24 May, 2017 1 commit