1. 27 Sep, 2018 1 commit
    • Creddy's avatar
      Reland "[interpreter] Separate bytecodes for one-shot property loads and stores" · 0714bd9f
      Creddy authored
      This is a reland of eccf1867
      
      Original change's description:
      > [interpreter] Separate bytecodes for one-shot property loads and stores
      > 
      > Create LdaNamedPropertyNoFeedback and StaNamedPropertyNoFeedback
      > for one-shot property loads and stores. This CL replaces the runtime
      > calls with new bytecodes for named property load stores in one-shot code.
      > the runtime calls needed extra set of consecutive registers and
      > additional move instructions. This increased the size of
      > bytecode-array and possibly extended the life time of objects.
      > By replacing them with NoFeedback bytecodes we avoid these issues.
      > 
      > Bug: v8:8072
      > Change-Id: I20a38a5ce9940026171d870d354787fe0b7c5a6f
      > Reviewed-on: https://chromium-review.googlesource.com/1196725
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Chandan Reddy <chandanreddy@google.com>
      > Cr-Commit-Position: refs/heads/master@{#56211}
      
      Bug: v8:8072
      Change-Id: Ie8e52b37daf35c7bc08bb910d7b15a9b783354e4
      Reviewed-on: https://chromium-review.googlesource.com/1245742
      Commit-Queue: Chandan Reddy <chandanreddy@google.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56266}
      0714bd9f
  2. 26 Sep, 2018 1 commit
    • Maya Lekova's avatar
      Revert "[interpreter] Separate bytecodes for one-shot property loads and stores" · 3c3330f6
      Maya Lekova authored
      This reverts commit eccf1867.
      
      Reason for revert: Speculative revert because it seems to introduce a pretty stable flake on gc stress tests, see https://bugs.chromium.org/p/v8/issues/detail?id=8229
      
      Original change's description:
      > [interpreter] Separate bytecodes for one-shot property loads and stores
      > 
      > Create LdaNamedPropertyNoFeedback and StaNamedPropertyNoFeedback
      > for one-shot property loads and stores. This CL replaces the runtime
      > calls with new bytecodes for named property load stores in one-shot code.
      > the runtime calls needed extra set of consecutive registers and
      > additional move instructions. This increased the size of
      > bytecode-array and possibly extended the life time of objects.
      > By replacing them with NoFeedback bytecodes we avoid these issues.
      > 
      > Bug: v8:8072
      > Change-Id: I20a38a5ce9940026171d870d354787fe0b7c5a6f
      > Reviewed-on: https://chromium-review.googlesource.com/1196725
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Chandan Reddy <chandanreddy@google.com>
      > Cr-Commit-Position: refs/heads/master@{#56211}
      
      TBR=rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org,neis@chromium.org,cbruni@chromium.org,chandanreddy@google.com
      
      Change-Id: I445db58e6d4c275b434fabad5fad775bf259033f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8072
      Reviewed-on: https://chromium-review.googlesource.com/1245421Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56232}
      3c3330f6
  3. 25 Sep, 2018 1 commit
  4. 17 Sep, 2018 1 commit
  5. 15 Jun, 2018 1 commit
  6. 21 Nov, 2017 1 commit
  7. 14 Sep, 2017 1 commit
    • Jaroslav Sevcik's avatar
      Revert "[turbofan] Lower monomorphic loads during graph building." · 7540e841
      Jaroslav Sevcik authored
      This reverts commit 14b424c3.
      
      Reason for revert: Regresses benchmarks, e.g., Octane/gameboy
      
      Original change's description:
      > [turbofan] Lower monomorphic loads during graph building.
      > 
      > We introduce an explicit LoweringResult data structure. Until this change,
      > the lowering result could be recovered from the node. However, lowering
      > monomorphic loads requires wiring different value and effect, so we need
      > a structure that can express such lowering result.
      > 
      > Bug: v8:6357
      > Change-Id: I92655800890b744d9203a778a1936a8dcd465ed3
      > Reviewed-on: https://chromium-review.googlesource.com/637304
      > Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47992}
      
      TBR=mstarzinger@chromium.org,jarin@chromium.org,bmeurer@chromium.org
      
      Change-Id: I2b7db0278c13414e20c94a34d215ed92bd0d412b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6357
      Reviewed-on: https://chromium-review.googlesource.com/667016Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48012}
      7540e841
  8. 13 Sep, 2017 1 commit
  9. 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
    • Jaroslav Sevcik's avatar
      [turbofan] Introduce LoweringResult in type hint lowering. · d667bf4a
      Jaroslav Sevcik authored
      Bug: v8:5267
      Change-Id: Iea44ba7ee6ba09580176936e6157d63c53d06446
      Reviewed-on: https://chromium-review.googlesource.com/646021
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47762}
      d667bf4a
  10. 28 Aug, 2017 1 commit
    • 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
  11. 19 Jul, 2017 1 commit
  12. 30 Jun, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Replace uninitialized JSConstruct nodes with SOFT deopt. · fd24deb0
      bmeurer authored
      Similar to JSCall, we can also replace uninitialized JSConstruct nodes
      with SOFT deopts to ensure that we don't generate unnecessary dead code.
      This for example shows up in the hot parts of the Node event emitter
      currently where the generic code for handling events with 4 or more
      parameters might not have been run, but we still generate most of the
      code because the new Array call in the beginning is not turned into
      a SOFT deopt immediately.
      
      Drive-by-fix: Also refactor the BytecodeGraphBuilder's handling of
      Construct bytecodes a bit to reduce the amount of code duplication.
      
      BUG=v8:4551, v8:5267
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2958253002
      Cr-Commit-Position: refs/heads/master@{#46339}
      fd24deb0
  13. 27 Jun, 2017 1 commit
  14. 07 Jun, 2017 1 commit
  15. 07 Apr, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Introduce a SpeculativeToNumber operator. · e6ca0146
      bmeurer authored
      Add a dedicated operator for ToNumber(x) with feedback instead of
      translating to SpeculativeNumberMultiply(x,1), which allows us to
      treat the case where x is already a Number specially, ignoring the
      feedback on the operator. This recovers most of the regression in
      the crypto benchmark.
      
      BUG=chromium:709398,v8:6214,v8:5267
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2802113003
      Cr-Commit-Position: refs/heads/master@{#44484}
      e6ca0146
  16. 28 Mar, 2017 2 commits
  17. 17 Mar, 2017 1 commit
  18. 28 Feb, 2017 1 commit
  19. 22 Feb, 2017 2 commits
  20. 20 Feb, 2017 2 commits
  21. 15 Feb, 2017 1 commit