1. 01 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Utilize UNINITIALIZED state of CompareIC and BinaryOpIC. · d6d72082
      Benedikt Meurer authored
      In the BytecodeGraphBuilder we insert a SOFT deopt whenever we see an
      IC whose state is UNINITIALIZED, i.e. a LOAD_IC or a STORE_IC. This
      greatly reduces the size of the generated graphs (and also helps to
      improve generated code quality). However for COMPARE_IC and BINARY_OP_IC
      we used to stick in the generic JavaScript node instead, which does
      generate code and might block optimizations because its sitting in
      the effect chain. This is changed now to always SOFT deopt for
      UNINITIALIZED instead, consistently with the other ICs.
      
      Bug: v8:6760
      Change-Id: I2ac7469fa86512a2fd909fdde2c6425977694811
      Reviewed-on: https://chromium-review.googlesource.com/645858
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47771}
      d6d72082
  2. 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
  3. 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
  4. 22 May, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Add Symbol feedback to Equal/StrictEqual. · d9e43297
      bmeurer authored
      Introduce a new Symbol comparison feedback bit in the lattice and
      collect that feedback on Equal/StrictEqual in Ignition. Utilize this
      feedback in TurboFan by adding a dedicated CheckSymbol operator to
      check for symbol inputs. This way we can optimize Symbol comparison
      where TurboFan doesn't know anything statically about either side, or
      abstract equality comparisons where TurboFan doesn't statically know
      anything about one side.
      
      BUG=v8:6278,v8:6344,v8:6423
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2893263002
      Cr-Commit-Position: refs/heads/master@{#45455}
      d9e43297
  5. 27 Oct, 2016 1 commit
  6. 17 Oct, 2016 1 commit
  7. 22 Sep, 2016 1 commit
  8. 20 Sep, 2016 1 commit
  9. 28 Aug, 2016 2 commits
  10. 26 Aug, 2016 1 commit
  11. 03 Aug, 2016 1 commit
  12. 18 Jul, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Add support for eager/soft deoptimization reasons. · db635d5b
      bmeurer authored
      So far TurboFan wasn't adding the deoptimization reasons for eager/soft
      deoptimization exits that can be used by either the DevTools profiler or
      the --trace-deopt flag. This adds basic support for deopt reasons on
      Deoptimize, DeoptimizeIf and DeoptimizeUnless nodes and threads through
      the reasons to the code generation.
      
      Also moves the DeoptReason to it's own file (to resolve include cycles)
      and drops unused reasons.
      
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2161543002
      Cr-Commit-Position: refs/heads/master@{#37823}
      db635d5b