1. 15 Feb, 2019 1 commit
  2. 13 Feb, 2019 1 commit
  3. 31 Jan, 2019 1 commit
    • Benedikt Meurer's avatar
      [ic] Don't unroll the loop in AccessorAssembler::HandlePolymorphicCase(). · e004fe75
      Benedikt Meurer authored
      Previously AccessorAssembler::HandlePolymorphicCase() had 4 versions of
      the inner loop unrolled, but we always had to check against the length
      after 1 (POLYMORPHIC with name) or 2 (regular POLYMORPHIC) unrolled
      iterations anyways, so there's not a lot of benefit to unrolling besides
      the potentially better branch prediction in some cases. But that doesn't
      seem to be beneficial even in extreme cases (in fact on ARM cores we
      might get some benefit from having less code instead), and probably
      doesn't justify the additional C++ / generated code.
      
      I used the following extreme micro-benchmark to check the worst case
      performance impact:
      
      ```js
      function test(o, n) {
        var result;
        for (var i = 0; i < n; ++i) {
          result = o.x;
        }
        return result;
      }
      
      const N = 1e8;
      const objs = [{x: 0}, {x:1,a:1}, {x:2,b:2}, {x:3,c:3}];
      for (var j = 0; j < objs.length; ++j) test(objs[j], N);
      
      console.time('Time');
      for (var j = 0; j < objs.length; ++j) test(objs[j], N);
      console.timeEnd('Time');
      ```
      
      Running this with --noopt shows a ~1% performance regression with this
      patch on a beefy z840 gLinux workstation, which gives me some confidence
      that overall this patch is going to be neutral and maybe beneficial in
      case of less powerful ARM cores.
      
      Note to performance sheriffs: This could potentially tank some
      performance tests. In that case we may need to revisit the unrolling.
      
      Bug: v8:8562
      Change-Id: I731599a7778da1992d981d36022c407ef5c735eb
      Reviewed-on: https://chromium-review.googlesource.com/c/1448275Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59252}
      e004fe75
  4. 28 Jan, 2019 2 commits
  5. 22 Nov, 2018 1 commit
  6. 11 Sep, 2018 2 commits
    • Caitlin Potter's avatar
      [CloneObjectIC] add CSA implementation of slow case · fbcf0221
      Caitlin Potter authored
      The CSA implementation is a separate handler so that TF has the
      opportunity to reduce to a direct call, skipping some of the dispatching
      in the CloneObjectIC stub.
      
      This patch moves the looping over a source object's keys and values into the
      base CodeStubAssembler, so that it can be shared between ObjectAssignFast
      and CloneObjectIC_Slow.
      
      During each step of the loop, storing is delegated to a new SetPropertyInLiteral
      helper in KeyedStoreGenericGenerator, which performs a store without consulting
      the prototype chain, and automatically reconfigures accessors into data
      properties regardless of their attributes.
      
      BUG=v8:8067, v8:7611
      R=ishell@chromium.org, jkummerow@chromium.org
      
      Change-Id: I06ae89f37e9b4265aab67389cf68a96529f90578
      Reviewed-on: https://chromium-review.googlesource.com/1182122
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55806}
      fbcf0221
    • Benedikt Meurer's avatar
      [turbofan] Reduce overhead of megamorphic property accesses. · a15ad0d3
      Benedikt Meurer authored
      We had an optimization in Crankshaft where we would call into the
      megamorphic handler stub directly if an inline cache was already
      found to be megamorphic when it hit the optimizing compiler. This
      way we could avoid the dispatch overhead when we know that there's
      no point in checking for the other states anyways. However we somehow
      missed to port this optimization to TurboFan.
      
      Now this change introduces support to call into LoadIC_Megamorphic and
      KeyedLoadIC_Megamorphic directly (plus the trampoline versions), which
      saves quite a lot of overhead for the cases where the map/name pair is
      found in the megamorphic stub cache, and it's quite a simple change. We
      can later extend this to also handle the StoreIC and KeyedStoreIC cases
      if that turns out to be beneficial.
      
      This improves the score on the Octane/TypeScript test by around ~2%
      and the TypeScript test in the web-tooling-benchmark by around ~4%. On
      the ARES-6 Air test the steady state mean improves by 2-4%, and on the
      ARES-6 ML test the steady state mean seems to also improve by 1-2%, but
      that might be within noise.
      
      On a micro-benchmark that just runs `o.x` in a hot loop on a set of 9
      different objects, which all have `x` as the first property and are
      all in fast mode, we improve by around ~30%, and are now almost on par
      with JavaScriptCore.
      
      Bug: v8:6344, v8:6936
      Change-Id: Iaa4c6e34c37e78da217ee75f32f6acc95a834250
      Reviewed-on: https://chromium-review.googlesource.com/1215623Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55803}
      a15ad0d3
  7. 15 Aug, 2018 1 commit
  8. 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
  9. 05 Jul, 2018 1 commit
  10. 04 Jun, 2018 1 commit
  11. 01 Jun, 2018 2 commits
  12. 25 May, 2018 1 commit
  13. 23 May, 2018 2 commits
  14. 18 May, 2018 1 commit
  15. 17 May, 2018 1 commit
  16. 15 May, 2018 1 commit
  17. 11 May, 2018 1 commit
  18. 08 May, 2018 1 commit
  19. 12 Apr, 2018 1 commit
  20. 11 Apr, 2018 1 commit
  21. 04 Apr, 2018 1 commit
  22. 27 Mar, 2018 1 commit
  23. 23 Mar, 2018 1 commit
  24. 08 Mar, 2018 1 commit
  25. 02 Mar, 2018 1 commit
  26. 02 Feb, 2018 1 commit
  27. 21 Dec, 2017 1 commit
  28. 18 Dec, 2017 2 commits
  29. 14 Dec, 2017 4 commits
  30. 13 Dec, 2017 1 commit
  31. 05 Dec, 2017 1 commit
  32. 07 Nov, 2017 1 commit