1. 17 Jun, 2020 1 commit
  2. 25 May, 2020 1 commit
  3. 11 May, 2020 1 commit
  4. 01 Apr, 2020 1 commit
  5. 31 Mar, 2020 1 commit
  6. 20 Mar, 2020 2 commits
  7. 04 Mar, 2020 1 commit
  8. 03 Mar, 2020 1 commit
  9. 29 Feb, 2020 1 commit
  10. 20 Feb, 2020 1 commit
  11. 14 Jan, 2020 1 commit
  12. 10 Jan, 2020 1 commit
    • Seth Brenith's avatar
      [torque] move more bitfield definitions to Torque · 87c16da5
      Seth Brenith authored
      This change moves the definitions of the bitfield flags used by Symbol
      and Map to Torque. Symbol could directly follow the pattern established
      by SharedFunctionInfo, but Map required some other changes:
      - Until now, Torque bitfield definitions have required unsigned types. I
        thought that this would be the least-surprising behavior, since we
        never sign-extend when decoding bitfield values. However, I believe
        that the amount of churn involved in making ElementsKind be unsigned
        outweighs the benefit we were getting from this restriction (and
        similar difficulties are likely to arise in converting other bitfield
        structs to Torque), so this CL updates Torque to allow signed bitfield
        values.
      - If we try to make Map extend from all of the generated classes that
        define its flags, we end up with class sizing problems because some
        compilers only apply empty base class optimization to the first in a
        row of empty base classes. We could work around this issue by
        generating macros instead of classes, but I took this as an
        opportunity for a minor clean-up instead: rather than having bitfield
        definitions for several different bitfield structs all jumbled
        together in Map, they can be split up. I think this makes the code a
        little easier to follow, but if others disagree I'm happy to implement
        macro generation instead.
      
      Change-Id: Ibf339b0be97f72d740bf1daa8300b471912faeba
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988934Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#65701}
      87c16da5
  13. 07 Jan, 2020 2 commits
  14. 20 Dec, 2019 1 commit
    • Tobias Tebbi's avatar
      Revert "Extend GetIterator bytecode to perform JSReceiver check on object[Symbol.iterator]()" · 4671cb56
      Tobias Tebbi authored
      This reverts commit 91e3243d.
      
      Reason for revert: This deopts to the wrong point.
      
      Original change's description:
      > Extend GetIterator bytecode to perform JSReceiver check on object[Symbol.iterator]()
      > 
      > Current GetIterator bytecode loads and calls @@iterator property on a
      > given object. This change extends the bytecode functionality to check
      > whether the value returned after calling @@iterator property is a valid
      > JSReceiver. The bytecode throws SymbolIteratorInvalid exception if the
      > returned value is not a valid JSReceiver. This change absorbs the
      > functionality of additional two bytecodes - JumpIfJSReceiver and
      > CallRuntime, that are part of the iterator protocol in the GetIterator
      > bytecode.
      > 
      > Bug: v8:9489
      > Change-Id: I9e84cfe85eeb9a1b8a97ca0595375ac26ba1bbfd
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792905
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
      > Cr-Commit-Position: refs/heads/master@{#63704}
      
      TBR=rmcilroy@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:9489
      Change-Id: I9324b5b01ead29912ad793a1e7b4d009643d7901
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960288Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65541}
      4671cb56
  15. 19 Dec, 2019 1 commit
  16. 18 Dec, 2019 1 commit
    • Leszek Swirski's avatar
      Reland "[ic] Load name/context lazily in LdaNamedProperty" · b21cda74
      Leszek Swirski authored
      This reverts commit 5377e72c.
      
      Reason for revert: Looks like the relevant graphs didn't recover after
      this revert, which suggests that the regression was an unrelated
      secondary effect. Relanding the original change since the revert did
      cause some microbenchmark regressions.
      
      Original change's description:
      > Revert "[ic] Load name/context lazily in LdaNamedProperty"
      > 
      > This reverts commit 347092ac.
      > 
      > Not a clean revert, since other changes got baked on top, but rather
      > a manual removal of LoadLazyICParameters.
      > 
      > Reason for revert: Seems to actually regress bindings perf tests (see
      > bugs and https://chromeperf.appspot.com/group_report?rev=62539), doesn't
      > seem to improve performance elsewhere, and increases complexity.
      > 
      > Original change's description:
      > > [ic] Load name/context lazily in LdaNamedProperty
      > >
      > > Introduces LazyLoadICParameters which allow a LazyNode for context and
      > > name. These aren't used on the fast path, so we want to avoid reading
      > > them for both performance and register pressure reasons.
      > >
      > > Change-Id: Ifb637cf4782ce984feee9af503998e7539beb823
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1686665
      > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#62539}
      > 
      > # Not skipping CQ checks because original CL landed > 1 day ago.
      > 
      > Bug: chromium:981797
      > Bug: chromium:982630
      > Change-Id: I88af764d17afb76d6e64b95a3d1e4aaa1c6c8978
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934327
      > Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#65205}
      
      TBR=leszeks@chromium.org,verwaest@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: chromium:981797, chromium:982630, v8:10059
      Change-Id: I13754de06c83439e03e22cfaa7a14ce454076db9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1973730Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65499}
      b21cda74
  17. 16 Dec, 2019 1 commit
  18. 27 Nov, 2019 1 commit
    • Leszek Swirski's avatar
      Revert "[ic] Load name/context lazily in LdaNamedProperty" · 5377e72c
      Leszek Swirski authored
      This reverts commit 347092ac.
      
      Not a clean revert, since other changes got baked on top, but rather
      a manual removal of LoadLazyICParameters.
      
      Reason for revert: Seems to actually regress bindings perf tests (see
      bugs and https://chromeperf.appspot.com/group_report?rev=62539), doesn't
      seem to improve performance elsewhere, and increases complexity.
      
      Original change's description:
      > [ic] Load name/context lazily in LdaNamedProperty
      >
      > Introduces LazyLoadICParameters which allow a LazyNode for context and
      > name. These aren't used on the fast path, so we want to avoid reading
      > them for both performance and register pressure reasons.
      >
      > Change-Id: Ifb637cf4782ce984feee9af503998e7539beb823
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1686665
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62539}
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: chromium:981797
      Bug: chromium:982630
      Change-Id: I88af764d17afb76d6e64b95a3d1e4aaa1c6c8978
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934327
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65205}
      5377e72c
  19. 15 Nov, 2019 1 commit
  20. 14 Nov, 2019 1 commit
  21. 11 Nov, 2019 1 commit
  22. 01 Nov, 2019 1 commit
  23. 31 Oct, 2019 1 commit
  24. 01 Oct, 2019 1 commit
  25. 25 Sep, 2019 1 commit
  26. 19 Sep, 2019 1 commit
  27. 16 Sep, 2019 2 commits
  28. 13 Sep, 2019 2 commits
  29. 12 Sep, 2019 4 commits
  30. 11 Sep, 2019 2 commits
  31. 10 Sep, 2019 1 commit
  32. 09 Sep, 2019 1 commit