1. 21 May, 2019 1 commit
  2. 07 May, 2019 1 commit
    • Mythri A's avatar
      Reland [ic] Remove the check for fast prototypes in LoadIC_Uninitialized · 9fe37d23
      Mythri A authored
      This is a reland of d14ed12e
      with fix for test failures in lite mode.
      
      When handling load named properties (without feedback vectors) we used
      to miss to runtimes if the prototypes aren't set. This was because we
      wanted to give the prototype a chance to become fast, since most prototypes
      start in slow mode but move to fast after the initial setup. Though this
      check is not really useful when we don't have feedback vectors, and once
      feedback vectors are allocated we will turn the prototypes fast anyway.
      
      Bug: v8:8394, v8:8860
      Change-Id: I5c7b5061e1d9068c72d6f0eea47517880940a054
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1591772Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61267}
      9fe37d23
  3. 12 Apr, 2019 2 commits
  4. 04 Apr, 2019 1 commit
  5. 29 Mar, 2019 1 commit
  6. 01 Mar, 2019 1 commit
    • Matt Gardner's avatar
      Reland "Optimize `in` operator" · 803ad324
      Matt Gardner authored
      The original was reverted for breaking webkit layout tests:
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/30270
      
      It also caused the following clusterfuzz failures:
      
      chromium:935832
      This was a correctness bug due to not properly handling the case of arrays with prototypes other
      than Array.prototype. Accesses that were TheHole were not being handled property, both in bounds
      holes in holey arrays and out of bounds on either holey or packed arrays. Handling was incorrect
      both in access-assembler and in Turbofan.
      
      chromium:935932
      This bug was that there was no handling for Has checks on the global object. Turbofan was emitting
      code for a store (the 'else' condition on 'access_mode == AccessMode::kLoad'). It hit a DCHECK in
      debug builds but in release could show up in different places. This is the bug that caused the
      webkit layout test failure that led to the revert.
      
      Both bugs are fixed by in CL, and tests are added for those cases.
      
      Bug: v8:8733, chromium:935932, chromium:935832
      Change-Id: Iba0dfcfce6e15d2c0815a7670ece67bc13ba1925
      Reviewed-on: https://chromium-review.googlesource.com/c/1493132Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Matt Gardner <magardn@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#59958}
      803ad324
  7. 26 Feb, 2019 1 commit
  8. 25 Feb, 2019 1 commit
  9. 21 Feb, 2019 1 commit
  10. 15 Feb, 2019 1 commit
  11. 13 Feb, 2019 1 commit
  12. 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
  13. 28 Jan, 2019 2 commits
  14. 22 Nov, 2018 1 commit
  15. 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
  16. 15 Aug, 2018 1 commit
  17. 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
  18. 05 Jul, 2018 1 commit
  19. 04 Jun, 2018 1 commit
  20. 01 Jun, 2018 2 commits
  21. 25 May, 2018 1 commit
  22. 23 May, 2018 2 commits
  23. 18 May, 2018 1 commit
  24. 17 May, 2018 1 commit
  25. 15 May, 2018 1 commit
  26. 11 May, 2018 1 commit
  27. 08 May, 2018 1 commit
  28. 12 Apr, 2018 1 commit
  29. 11 Apr, 2018 1 commit
  30. 04 Apr, 2018 1 commit
  31. 27 Mar, 2018 1 commit
  32. 23 Mar, 2018 1 commit
  33. 08 Mar, 2018 1 commit
  34. 02 Mar, 2018 1 commit
  35. 02 Feb, 2018 1 commit