1. 04 Sep, 2019 1 commit
  2. 03 Sep, 2019 2 commits
  3. 30 Aug, 2019 1 commit
  4. 17 Jul, 2019 1 commit
  5. 15 Jul, 2019 1 commit
  6. 08 Jul, 2019 1 commit
  7. 23 May, 2019 2 commits
  8. 14 May, 2019 1 commit
  9. 06 May, 2019 1 commit
  10. 29 Apr, 2019 3 commits
  11. 25 Feb, 2019 1 commit
    • Ross McIlroy's avatar
      [Runtime] Ensure template objects are retained if bytecode is flushed. · ec9aef3d
      Ross McIlroy authored
      Template objects should be cached after they are first created and reused on
      subsiquent calls to tag functions. Currently these cached objects are stored
      on the feedback vector, which has appropriate lifetime, however with bytecode
      flushing the feedback vector could be cleared when the bytecode is flushed,
      causing the template object to be dropped.
      
      In order to retain the cached template objects in the face of bytecode flushing,
      this CL adds a weakmap for each native context that is (weakly) keyed by
      shared function info, and holds a linked list of cached template objects
      associated with that shared function info, indexed by feedback vector slot id.
      Misses will check this weakmap, and if no entry is found, a new template object
      is created and added into this weakmap alongside the feedback vector.
      
      BUG=v8:8799,v8:8799,v8:8395
      
      Change-Id: Ia95d5cfc394ce58dc9fe6a1e49780f05299acc17
      Reviewed-on: https://chromium-review.googlesource.com/c/1477746
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59818}
      ec9aef3d
  12. 15 Nov, 2018 1 commit
  13. 27 Sep, 2018 1 commit
  14. 09 Aug, 2018 1 commit
    • jgruber's avatar
      [builtins] Fix argument order inconsistency in HasProperty · 3c1f40de
      jgruber authored
      The HasProperty builtin differed in its expected argument order from
      the HasProperty runtime function. Like all other related spec
      primitives (e.g.: GetProperty, SetProperty, DeleteProperty), it should
      take {object} as the first argument and {key} as the second.
      
      This CL changes the builtin and all related spots to use the correct
      order.
      
      There was also a tricky bug in interpreter intrinsic rewriting, which
      assumes (but does not verify) that the argument order between runtime
      function and builtin is identical. Besides cctests, HasProperty
      intrinsic rewriting seems to be dead code.
      
      Bug: v8:8036
      Change-Id: Ia669fd6f5c73a30df4e4607064603be759ced392
      Reviewed-on: https://chromium-review.googlesource.com/1167297
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55022}
      3c1f40de
  15. 20 Jul, 2018 1 commit
    • Caitlin Potter's avatar
      [runtime] use new CloneObject bytecode for some ObjectLiteralSpread cases · b6f7ea58
      Caitlin Potter authored
      As discussed in
      https://docs.google.com/document/d/1sBdGe8RHgeYP850cKSSgGABTyfMdvaEWLy-vertuTCo/edit?ts=5b3ba5cc#,
      
      this CL introduces a new bytecode (CloneObject), and a new IC type.
      
      In this prototype implementation, the type feedback looks like the
      following:
      
      Uninitialized case:
        { uninitialized_sentinel, uninitialized_sentinel }
      Monomorphic case:
        { weak 'source' map, strong 'result' map }
      Polymorphic case:
        { WeakFixedArray with { weak 'source' map, strong 'result' map }, cleared value }
      Megamorphic case:
        { megamorphic_sentinel, cleared_Value }
      
      In the fast case, Object cloning is done by allocating an object with
      the saved result map, and a shallow clone of the fast properties from
      the source object, as well as cloned fast elements from the source object.
      If at any point the fast case can't be taken, the IC transitions to the
      slow case and remains there.
      
      This prototype CL does not include any TurboFan optimization, and the
      CloneObject operation is merely reduced to a stub call.
      
      It may still be possible to get some further improvements by somehow
      incorporating compile-time boilerplate elements into the cloned object,
      or simplifying how the boilerplate elements are inserted into the
      object.
      
      In terms of performance, we improve the ObjectSpread score in JSTests/ObjectLiteralSpread/
      by about 8x, with substantial improvements over the Babel and ObjectAssign scores.
      
      R=gsathya@chromium.org, mvstanton@chromium.org, rmcilroy@chromium.org, neis@chromium.org, bmeurer@chromium.org
      BUG=v8:7611
      
      Change-Id: I79e1796eb77016fb4feba0e1d3bb9abb348c183e
      Reviewed-on: https://chromium-review.googlesource.com/1127472
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54595}
      b6f7ea58
  16. 15 Jun, 2018 1 commit
  17. 29 Mar, 2018 1 commit
  18. 27 Feb, 2018 1 commit
  19. 01 Feb, 2018 1 commit
  20. 24 Jan, 2018 1 commit
  21. 23 Jan, 2018 1 commit
    • Leszek Swirski's avatar
      [ignition] Single-switch generator bytecode · c869d40d
      Leszek Swirski authored
      Currently, yields and awaits inside loops compile to bytecode which
      switches to the top of the loop header, and switch again once inside the
      loop. This is to make loops reducible.
      
      This replaces this switching logic with a single switch bytecode that
      directly jumps to the bytecode being resumed. Among other things, this
      allows us to no longer maintain the generator state after the switch at
      the top of the function, and avoid having to track loop suspend counts.
      
      TurboFan still needs to have reducible loops, so we now insert loop
      header switches during bytecode graph building, for suspends that are
      discovered to be inside loops during bytecode analysis. We do, however,
      do some environment magic across loop headers since we know that we will
      continue switching if and only if we reached that loop header via a
      generator resume. This allows us to generate fewer phis and tighten
      liveness.
      
      Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385
      Reviewed-on: https://chromium-review.googlesource.com/866734
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50804}
      c869d40d
  22. 22 Jan, 2018 1 commit
  23. 14 Dec, 2017 1 commit
  24. 11 Dec, 2017 1 commit
  25. 08 Dec, 2017 1 commit
  26. 07 Dec, 2017 1 commit
  27. 28 Nov, 2017 1 commit
  28. 21 Nov, 2017 1 commit
  29. 22 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [es2015] Introduce dedicated GetTemplateObject bytecode. · 79ac69b8
      Benedikt Meurer authored
      Tagged templates were previously desugared during parsing using some
      combination of runtime support written in JavaScript and C++, which
      prevented some optimizations from happening, namely the constant folding
      of the template object in TurboFan optimized code. This CL adds a new
      bytecode GetTemplateObject (with a corresponding GetTemplateObject AST
      node), which represents the abstract operation in the ES6 specification
      and allows TurboFan to simply constant-fold template objects at compile
      time (which is explicitly supported by the specification).
      
      This also pays down some technical debt by removing the template.js
      runtime support and therefore should reduce the size of the native
      context (snapshot) a bit.
      
      With this change in-place the ES6 version microbenchmark in the
      referenced tracking bug is now faster than the transpiled Babel
      code, it goes from
      
        templateStringTagES5: 4552 ms.
        templateStringTagES6: 14185 ms.
        templateStringTagBabel: 7626 ms.
      
      to
      
        templateStringTagES5: 4515 ms.
        templateStringTagES6: 7491 ms.
        templateStringTagBabel: 7639 ms.
      
      which corresponds to a solid 45% reduction in execution time. With some
      further optimizations the ES6 version should be able to outperform the
      ES5 version. This micro-benchmark should be fairly representative of the
      six-speed-templatestringtag-es6 benchmark, and as such that benchmark
      should also improve by around 50%.
      
      Bug: v8:6819,v8:6820
      Tbr: mlippautz@chromium.org
      Change-Id: I821085e3794717fc7f52b5c306fcb93ba03345dc
      Reviewed-on: https://chromium-review.googlesource.com/677462Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarCaitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48126}
      79ac69b8
  30. 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
  31. 13 Sep, 2017 1 commit
  32. 12 Sep, 2017 1 commit
  33. 07 Sep, 2017 1 commit
  34. 05 Sep, 2017 1 commit
  35. 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