1. 18 Oct, 2017 1 commit
  2. 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
  3. 16 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [es2015] Optimize Reflect.has builtin. · 4213af64
      Benedikt Meurer authored
      Port the baseline version of Reflect.has to the CodeStubAssembler and
      reuse the existing logic for HasProperty (i.e. the HasProperty builtin).
      Also inline the Reflect.has builtin into TurboFan, by adding a check
      on the target in front of a use of the JSHasProperty operator.
      Technically this additional check is not necessary, because the
      JSHasProperty operator already throws if the target is not a JSReceiver,
      but the exception message is confusing then.
      
      This improves the performance of the micro-benchmark from
      
        reflectHasPresent: 337 ms.
        reflectHasAbsent: 472 ms.
      
      to
      
        reflectHasPresent: 121 ms.
        reflectHasAbsent: 216 ms.
      
      which is a nice 2.8x improvement in the best case. It also improves the
      chai test on the web-tooling-benchmark by around 1-2%, which is roughly
      the expected win (since Reflect.has overall accounts for around 3-4%).
      
      Bug: v8:5996, v8:6936, v8:6937
      Change-Id: I856183229677a71c19936f06f2a4fc7a794a9a4a
      Reviewed-on: https://chromium-review.googlesource.com/720959
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48608}
      4213af64
  4. 13 Oct, 2017 1 commit
  5. 12 Oct, 2017 1 commit
    • Leszek Swirski's avatar
      [turbofan] Add deopt reason to CheckIf · b4deef61
      Leszek Swirski authored
      CheckIf is lowered to DeoptimizeIfNot, but there is no deoptimization
      reason given in the deopt if that check fails (the reason is hardcoded
      to "no reason"). These deopts are annoying to track down.
      
      This patch makes CheckIf an operator with a DeoptimizeReason parameter,
      which is passed through to the DeoptimizeIfNot when lowered.
      A couple of checks are converted to give good deoptimize reasons (some
      new reasons are introduced), and the others are defaulted to kNoReason
      until someone else finds a use for them.
      
      Change-Id: I7e910cc9579ccf978dfe9d270ba7b98c8f6c2492
      Reviewed-on: https://chromium-review.googlesource.com/716479Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48506}
      b4deef61
  6. 10 Oct, 2017 1 commit
  7. 09 Oct, 2017 4 commits
  8. 04 Oct, 2017 1 commit
  9. 19 Sep, 2017 1 commit
  10. 15 Sep, 2017 1 commit
  11. 11 Sep, 2017 1 commit
  12. 08 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Optimize Object constructor subclassing. · 1f3f8f3e
      Benedikt Meurer authored
      Add support to the JSCallReducer to recognize JSConstruct nodes where
      the target is the Object constructor, and reduce them to JSCreate
      nodes if either
      
       (a) no value is passed to the Object constructor, or
       (b) the target and new.target are definitely not identical, by checking
           whether both target and new.target are different HeapConstants
           (if they are not, then the JSCreateLowering will not be able to
           do a lot with the JSCreate anyways).
      
      This should cover the relevant cases for subclassing appropriately. It
      fixes the 3-4x slowdown on the micro-benchmark mentioned in the linked
      bug,
      
        baseNoExtends: 752 ms.
        baseExtendsObject: 752 ms.
        baseExtendsViaFactory: 751 ms.
      
      and thus removes the performance cliff.
      
      R=jarin@chromium.org
      
      Bug: v8:6801
      Change-Id: Id265fd1399302a67b5790a6d0156679920c58bdd
      Reviewed-on: https://chromium-review.googlesource.com/657019Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47913}
      1f3f8f3e
  13. 07 Sep, 2017 2 commits
  14. 01 Sep, 2017 1 commit
    • 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
  15. 31 Aug, 2017 1 commit
  16. 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
  17. 24 Aug, 2017 1 commit
  18. 09 Aug, 2017 1 commit
  19. 08 Aug, 2017 1 commit
    • Benedikt Meurer's avatar
      [ic] Collect new.target feedback for Construct bytecodes. · 650d65c9
      Benedikt Meurer authored
      Change the CALL_IC machinery inside of Ignition to collect new.target
      feedback for Construct and ConstructWithSpread bytecodes instead of
      collecting feedback about the target, and adapt TurboFan's JSCallReducer
      to consume feedback for new.target instead of target on JSConstruct
      nodes.
      
      This enables TurboFan to inline JSCreate - and thus the actual instance
      allocation - into derived leaf constructors even if the leaf constructor
      itself is not inlined, and thereby removes this weird performance cliff.
      The feedback for target in case of class constructors is provided by
      the function context specialization, and in case of `new A`, we can
      just use the feedback for new.target, as both target and new.target are
      A in that case.
      
      Bug: v8:5517, v8:6399, v8:6679
      Change-Id: I0475e2500e787fd672ed037ac0faed78a8fa5dc0
      Reviewed-on: https://chromium-review.googlesource.com/604790Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47210}
      650d65c9
  20. 07 Aug, 2017 4 commits
    • Benedikt Meurer's avatar
      [ic] Properly integrate the CallIC into Ignition. · ee350c31
      Benedikt Meurer authored
      Drop the deprecated CallConstructStub and remove the use of CallICStub
      from fullcodegen, since that feedback is unused completely every since
      Crankshaft got removed, thus we can safely unlink all the CallIC stuff
      from fullcodegen nowadays, and completely nuke the CallICStub and the
      CallICTrampolineStub now (we can also transitively nuke the unused
      CreateAllocationSiteStub and CreateWeakCellStub).
      
      Instead the CallIC logic is integrated into Ignition now, and part of
      the bytecode handlers for [[Call]] and [[Construct]]. There's still some
      follow-up cleanup with the way the Array constructor feedback is
      integrated, but that's way easier now.
      
      Bug: v8:5517, v8:6399, v8:6409, v8:6679
      Change-Id: I0a6c6046faceca9b1606577bc9e63d9295e44619
      Reviewed-on: https://chromium-review.googlesource.com/603609
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47196}
      ee350c31
    • Benedikt Meurer's avatar
      [turbofan] Remove obsolete JSCall support for AllocationSites. · b1b595b0
      Benedikt Meurer authored
      As of https://chromium-review.googlesource.com/600968 the CallIC no
      longer supports AllocationSite feedback for [[Call]], so we can drop
      the TurboFan bits that deal with AllocationSites for JSCall nodes as
      well. This further simplifies the handling of the Array constructor.
      
      Drive-by-fix: Rename Builtins::kArrayCode to Builtins::kArrayConstructor
      for sake of consistency.
      
      Bug: v8:6399
      Change-Id: I9e6a684fc00dd72e25f925db5f407c3f3f715873
      Reviewed-on: https://chromium-review.googlesource.com/602354
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47194}
      b1b595b0
    • Michael Achenbach's avatar
      Revert "[ic] Properly integrate the CallIC into Ignition." · 018128a4
      Michael Achenbach authored
      This reverts commit 6c541561.
      
      Reason for revert:
      https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap/builds/17240
      
      Original change's description:
      > [ic] Properly integrate the CallIC into Ignition.
      > 
      > Drop the deprecated CallConstructStub and remove the use of CallICStub
      > from fullcodegen, since that feedback is unused completely every since
      > Crankshaft got removed, thus we can safely unlink all the CallIC stuff
      > from fullcodegen nowadays, and completely nuke the CallICStub and the
      > CallICTrampolineStub now (we can also transitively nuke the unused
      > CreateAllocationSiteStub and CreateWeakCellStub).
      > 
      > Instead the CallIC logic is integrated into Ignition now, and part of
      > the bytecode handlers for [[Call]] and [[Construct]]. There's still some
      > follow-up cleanup with the way the Array constructor feedback is
      > integrated, but that's way easier now.
      > 
      > Bug: v8:5517, v8:6399, v8:6409, v8:6679
      > Change-Id: Ia0efc6145ee64633757a6c3fd1879d4906ea2835
      > Reviewed-on: https://chromium-review.googlesource.com/602134
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47192}
      
      TBR=rmcilroy@chromium.org,yangguo@chromium.org,bmeurer@chromium.org
      
      Change-Id: I416ce6646f62ceb4127b3acee43912ee0d701c23
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:5517, v8:6399, v8:6409, v8:6679
      Reviewed-on: https://chromium-review.googlesource.com/603647Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47193}
      018128a4
    • Benedikt Meurer's avatar
      [ic] Properly integrate the CallIC into Ignition. · 6c541561
      Benedikt Meurer authored
      Drop the deprecated CallConstructStub and remove the use of CallICStub
      from fullcodegen, since that feedback is unused completely every since
      Crankshaft got removed, thus we can safely unlink all the CallIC stuff
      from fullcodegen nowadays, and completely nuke the CallICStub and the
      CallICTrampolineStub now (we can also transitively nuke the unused
      CreateAllocationSiteStub and CreateWeakCellStub).
      
      Instead the CallIC logic is integrated into Ignition now, and part of
      the bytecode handlers for [[Call]] and [[Construct]]. There's still some
      follow-up cleanup with the way the Array constructor feedback is
      integrated, but that's way easier now.
      
      Bug: v8:5517, v8:6399, v8:6409, v8:6679
      Change-Id: Ia0efc6145ee64633757a6c3fd1879d4906ea2835
      Reviewed-on: https://chromium-review.googlesource.com/602134
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47192}
      6c541561
  21. 27 Jul, 2017 1 commit
  22. 24 Jul, 2017 2 commits
    • Michael Starzinger's avatar
      [turbofan] Handle exceptional edges in ReduceArrayForEach. · d07365f9
      Michael Starzinger authored
      This adds handling for exceptional control projections when lowering
      calls to {Array.prototype.forEach} in the call reducer.
      
      R=jarin@chromium.org
      TEST=mjsunit/optimized-foreach
      BUG=v8:1956
      
      Change-Id: I282048b203814cbc1c90df983879578b210f92fb
      Reviewed-on: https://chromium-review.googlesource.com/574542
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46834}
      d07365f9
    • Benedikt Meurer's avatar
      [turbofan] Add IC support for Call/ConstructWithSpread. · 5ee1b7ad
      Benedikt Meurer authored
      Properly hook up the (existing) IC slots for the CallWithSpread and
      ConstructWithSpread bytecodes, and change the interpreter to collect
      feedback (call counts and regular target function feedback) for those.
      There's no integration with the Array constructor yet, since that
      requires some yak shaving to thread through the AllocationSite to the
      Array constructor stub. Once we have a solution for that, we can also
      remove the current code duplication in the Call/Construct IC logic.
      
      Also properly hook up the newly available feedback in TurboFan. This
      will fix not only the missing target feedback, but more importantly
      the tear-up decisions for optimization are correct now in the presence
      of spread calls, and even more importantly the inlining heurstic has
      proper call frequencies for those.
      
      Some follow-up changes will be necessary to make sure we use the
      feedback even for corner cases that aren't handled properly yet. Also
      we should consider collecting feedback about the map of the spread
      at some point to be able to always inline the spread calls.
      
      Bug: v8:6399, v8:6527, v8:6630
      Change-Id: I818dbcb411fd3951d8e9d31f5d7e794f8d60fa00
      Reviewed-on: https://chromium-review.googlesource.com/582647Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46832}
      5ee1b7ad
  23. 20 Jul, 2017 1 commit
  24. 19 Jul, 2017 2 commits
  25. 17 Jul, 2017 1 commit
  26. 14 Jul, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Inline Map and Set iterators into optimized code. · 1287688c
      Benedikt Meurer authored
      This CL inlines the following builtins into TurboFan
      
        - %MapIteratorPrototype%.next
        - %SetIteratorPrototype%.next
      
      following the design that we are using for Array iteration already
      (different instance types for the different kinds of iterators). Details
      can be found in the relevant design document at:
      
        https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8
      
      The key to great performance here is to ensure that the inlined code
      allows escape analysis and scalar replacement of aggregates to remove
      the allocations for the iterator itself as well as the iterator results
      and potential key/value arrays in the simple case of a for-of loop (and
      by extension also in other constructs that reduce to for-of loops
      internally), i.e.:
      
        const s = new Set;
        // ... do something with s
        for (const x of s) {
          // ...
        }
      
      Here the for-of loop shouldn't perform any allocations of helper
      objects.
      
      Drive-by-fix: Replace the ExistsJSMapWithness in JSBuiltinReducer with a more
      general HasInstanceTypeWitness, similar to what's in JSCallReducer. Also
      migrate the {Map,Set}.prototype.size getter inlining to the
      JSBuiltinReducer, so that everything is in a single place.
      
      R=jgruber@chromium.org
      
      Bug: v8:6344, v8:6571, chromium:740122
      Change-Id: I09cb506fe26ed3e10d7dcb2f95ec4415e639582d
      Reviewed-on: https://chromium-review.googlesource.com/570159Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46655}
      1287688c
  27. 13 Jul, 2017 2 commits
  28. 11 Jul, 2017 2 commits
  29. 10 Jul, 2017 1 commit