1. 17 Aug, 2021 1 commit
  2. 12 Aug, 2021 1 commit
  3. 29 Jul, 2021 1 commit
  4. 15 Jul, 2021 1 commit
  5. 28 Jun, 2021 1 commit
  6. 24 Jun, 2021 1 commit
  7. 23 Jun, 2021 1 commit
    • Mihir Shah's avatar
      A jump-table implementation for constant case switch statements · 9711289d
      Mihir Shah authored
      The change is made since for switch statements with lots of cases,
      where each case is a constant integer, the emitted bytecode is still
      a series of jumps, when we can instead use a jump table.
      
      If there are 6 or more cases (similar to GCC) of Smi literals, and
      if the max Smi case minus the min Smi case is not more than 3 times
      the number of cases, we use a jump table up front to handle Smi's,
      and then use traditional if-else logic for the rest of the cases.
      
      We then use the jump table in interpreter/bytecode-jump-table to
      do the optimization.
      
      This tries to go off issue 9738 in v8's issue tracker. It is not
      exactly the same, since that recommends doing the work at JIT-time,
      but has similar ideas. It also partially goes off issue 10764.
      
      Bug: v8:9738
      Change-Id: Ic805682ee3abf9ce464bb733b427fa0c83a6e10c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2904926Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75323}
      9711289d
  8. 18 Jun, 2021 1 commit
  9. 17 Jun, 2021 1 commit
  10. 14 Jun, 2021 1 commit
    • Peter Kasting's avatar
      Fix -Wdeprecated-copy in V8. · 2af5cfa8
      Peter Kasting authored
      TNode has a templated constructor from TNode<U>, but this doesn't take
      precedence over the auto-generated copy constructor, which results in a
      warning being fired.  Fix by adding an explicit copy constructor that
      does what the templated constructor does, which in turn requires fixing
      some missing #includes that slipped by due to the lack of
      LazyTemplateChecks() in the autogenerated copy constructor.
      
      Bug: chromium:1213098
      Change-Id: Iad40950261af8f88396be9227355e4e013837341
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953503Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Peter Kasting <pkasting@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75133}
      2af5cfa8
  11. 08 Jun, 2021 1 commit
    • Wenyu Zhao's avatar
      Reland "[csa] Remove InnerAllocate and replace with non-folded allocations" · 09faa661
      Wenyu Zhao authored
      The initial CL is suspected to break the --predictable CI.
      But looks like the CI is still crashing and also flaky after the
      revert. So reland it again.
      
      This is a reland of 59d58d72
      
      Original change's description:
      > [csa] Remove InnerAllocate and replace with non-folded allocations
      >
      > This CL removes all uses of InnerAllocate (except memento allocations)
      > and replace with non-folded allocations. The change is based on the
      > fact that 1. Those InnerAllocates are not guarded by --allocation-folding
      > flag. 2. Hopefully the MemoryOptimizer can handle the folding and no
      > performance regression will happen.
      >
      > Two special versions of InnerAllocate is still kept:
      > * One for memento allocations (renamed to InnerAllocateMemento).
      > * One for AllocateUninitializedJSArrayWithElements (renamed to InnerAllocateElements).
      >
      > Change-Id: Ie77da6b2fba31b048241f7b7d927065305a01c27
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2873767
      > Commit-Queue: Wenyu Zhao <wenyu.zhao@anu.edu.au>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#74899}
      
      Change-Id: I540c3a6b6e3f7c70c048f8ad1e5f702287fb086b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2946667
      Commit-Queue: Wenyu Zhao <wenyu.zhao@anu.edu.au>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75015}
      09faa661
  12. 07 Jun, 2021 1 commit
  13. 02 Jun, 2021 2 commits
    • Wenyu Zhao's avatar
      Revert "[csa] Remove InnerAllocate and replace with non-folded allocations" · a15cfb8f
      Wenyu Zhao authored
      This reverts commit 59d58d72.
      
      Reason for revert: This CL breaks --predictable
      
      Original change's description:
      > [csa] Remove InnerAllocate and replace with non-folded allocations
      >
      > This CL removes all uses of InnerAllocate (except memento allocations)
      > and replace with non-folded allocations. The change is based on the
      > fact that 1. Those InnerAllocates are not guarded by --allocation-folding
      > flag. 2. Hopefully the MemoryOptimizer can handle the folding and no
      > performance regression will happen.
      >
      > Two special versions of InnerAllocate is still kept:
      > * One for memento allocations (renamed to InnerAllocateMemento).
      > * One for AllocateUninitializedJSArrayWithElements (renamed to InnerAllocateElements).
      >
      > Change-Id: Ie77da6b2fba31b048241f7b7d927065305a01c27
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2873767
      > Commit-Queue: Wenyu Zhao <wenyu.zhao@anu.edu.au>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#74899}
      
      Change-Id: If6a1836634670eff3342f6df1d2a5b76afbdc0ac
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2932796
      Auto-Submit: Wenyu Zhao <wenyu.zhao@anu.edu.au>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#74903}
      a15cfb8f
    • Wenyu Zhao's avatar
      [csa] Remove InnerAllocate and replace with non-folded allocations · 59d58d72
      Wenyu Zhao authored
      This CL removes all uses of InnerAllocate (except memento allocations)
      and replace with non-folded allocations. The change is based on the
      fact that 1. Those InnerAllocates are not guarded by --allocation-folding
      flag. 2. Hopefully the MemoryOptimizer can handle the folding and no
      performance regression will happen.
      
      Two special versions of InnerAllocate is still kept:
      * One for memento allocations (renamed to InnerAllocateMemento).
      * One for AllocateUninitializedJSArrayWithElements (renamed to InnerAllocateElements).
      
      Change-Id: Ie77da6b2fba31b048241f7b7d927065305a01c27
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2873767
      Commit-Queue: Wenyu Zhao <wenyu.zhao@anu.edu.au>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74899}
      59d58d72
  14. 17 May, 2021 1 commit
    • Philip Pfaffe's avatar
      Reland "[ic] Fix handling of API properties with side effects" · b4942eb3
      Philip Pfaffe authored
      This is a reland of 0ce36e7d
      
      The reland includes two fixes:
      - Move the EvaluateGlobalForTesting into libv8 to avoid linkage issues
        and to avoid having to export ThreadLocalTop symbols.
      - Give the ExecutionMode enum a uint8_t backing type to avoid endianess
        issues.
      
      Original change's description:
      > [ic] Fix handling of API properties with side effects
      >
      > DebugEvaluate can evaluate expressions in side-effect-free mode, where
      > any operation that would cause observable side effects throws an
      > exception. Currently, when accessors are backed by callbacks, it's
      > possible that ICs call those accessors directly, bypassing the
      > side-effect checks. This CL introduces a bailouts to runtime in those
      > cases.
      >
      > Fixed: chromium:1201781
      > Also-By: ishell@chromium.org, pfaffe@chromium.org
      > Change-Id: Ie53bfb2bff7b3420f2b27091e8df6723382cf53c
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2857634
      > Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#74507}
      
      Fixes: v8:11761
      Change-Id: I58cde8bd11ba0fc9d83adc19fa87733628ab6c13
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891829Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74602}
      b4942eb3
  15. 14 May, 2021 1 commit
  16. 12 May, 2021 1 commit
    • Maya Lekova's avatar
      Revert "[ic] Fix handling of API properties with side effects" · ba6a1a7c
      Maya Lekova authored
      This reverts commit 0ce36e7d.
      
      Reason for revert: Speculative revert for a Chromium build breakage causing a blocked roll - https://bugs.chromium.org/p/v8/issues/detail?id=11761
      
      Original change's description:
      > [ic] Fix handling of API properties with side effects
      >
      > DebugEvaluate can evaluate expressions in side-effect-free mode, where
      > any operation that would cause observable side effects throws an
      > exception. Currently, when accessors are backed by callbacks, it's
      > possible that ICs call those accessors directly, bypassing the
      > side-effect checks. This CL introduces a bailouts to runtime in those
      > cases.
      >
      > Fixed: chromium:1201781
      > Also-By: ishell@chromium.org, pfaffe@chromium.org
      > Change-Id: Ie53bfb2bff7b3420f2b27091e8df6723382cf53c
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2857634
      > Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#74507}
      
      Change-Id: Ifb5c24682af29572591d436ab92b0304058e99af
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891650
      Auto-Submit: Maya Lekova <mslekova@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#74515}
      ba6a1a7c
  17. 11 May, 2021 1 commit
  18. 10 May, 2021 1 commit
  19. 06 May, 2021 1 commit
    • Fanchen Kong's avatar
      Collect receiver to feedback for prototype.apply · 519c82ce
      Fanchen Kong authored
      When a function is invoked by prototype.apply, it may undergo following transformation in the JSCallReducer:
      	receiver.apply(this, args) ->
      	this.receiver(...args) Since the new target (also the receiver of apply()) is not collected to the feedback slot, further speculative optimization on the new target is not available if the new target
      is not a heapconstant.
      
      With this CL, the receiver will be collected to the feedback instead of the target if the target is a prototype.apply. It may improve the performance of the following usecase by ~80%.
      
      function reduceArray(func, arr, r) {
          for (var i = 0, len = arr.length; i < len; i++) {
                  r = func.apply(null, r, arr[i]);
          }
          return r;
      }
      
      var a = 0; for (var i = 0; i < 10000000; i++) {
          a += reduceArray(Math.imul, [5,6,2,3,7,6,8,3,7,9,2,5,], 1);
      }
      console.log(a);
      
      This CL also improves the runTime score of JetStream2/richards-wasm by ~45% in default, ~60% with --turbo-inline-js-wasm-calls.
      
      Change-Id: I542eb8d3fcb592f4e0993af93ba1af70e89c3982
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639813
      Commit-Queue: Fanchen Kong <fanchen.kong@intel.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74413}
      519c82ce
  20. 29 Apr, 2021 1 commit
  21. 20 Apr, 2021 2 commits
  22. 12 Apr, 2021 1 commit
    • Wenyu Zhao's avatar
      Allowing map word to be used for other state in GC header. · 5e0b94c4
      Wenyu Zhao authored
      This CL adds features to pack/unpack map words.
      
      Currently V8 cannot store extra metadata in object headers -- because V8
      objects do not have a proper header, but only a map pointer at the start
      of the object. To store per-object metadata like marking data, a side
      table is required as the per-object metadata storage.
      
      This CL enables V8 to use higher unused bits in a 64-bit map word as
      per-object metadata storage. Map pointer stores come with an extra step
      to encode the metadata into the pointer (we call it "map packing").
      Map pointer loads will also remove the metadata bits as well (we call it
      "map packing").
      
      Since the map word is no longer a valid pointer after packing, we also
      change the tag of the packed map word to make it looks like a Smi. This
      helps various GC and barrier code to correctly skip them instead of
      blindly dereferencing this invalid pointer.
      
      A ninja flag `v8_enable_map_packing` is provided to turn this
      map-packing feature on and off. It is disabled by default.
      
      * Only works on x64 platform, with `v8_enable_pointer_compression`
        set to `false`
      
      Bug: v8:11624
      Change-Id: Ia2bdf79553945e5fc0b0874c87803d2cc733e073
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247561Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73915}
      5e0b94c4
  23. 08 Apr, 2021 2 commits
  24. 31 Mar, 2021 3 commits
    • Igor Sheludko's avatar
      Reland "[dict-proto] SIMD support for SwissNameDictionary in Torque" · 4cd6ad9e
      Igor Sheludko authored
      This is a reland of 856e8577
      The diff compared to the first attempt is that the tests that
      require SSSE3/AVX are not run when these CPU features are not
      available.
      
      Original change's description:
      > [dict-proto] SIMD support for SwissNameDictionary in Torque
      >
      > This CL adds a Torque-counterpart for swiss_table::GroupSse2Impl in
      > Torque. This allows the Torque version of SwissNameDictionary to use
      > SSE for lookups, rather than needing to bailout to the runtime on
      > x64/ia32.
      >
      > Bug: v8:11330
      > Change-Id: I74e3f97c460a8b89031016967ec0e545265016a9
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2787485
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
      > Reviewed-by: Zhi An Ng <zhin@chromium.org>
      > Commit-Queue: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73727}
      
      Bug: v8:11330
      Cq-Include-Trybots: luci.v8.try:v8_linux_optional_rel_ng
      Change-Id: Ibfa5ae5a39333778ea0d0406d5ea4ad683ad0dbe
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2794431Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73740}
      4cd6ad9e
    • Maya Lekova's avatar
      Revert "[ic] Add a new MegaDOM IC" · 3f8aa89e
      Maya Lekova authored
      This reverts commit c83c9590.
      
      Reason for revert: Speculatively reverting for a failure on Arm GC stress bot - https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Arm%20GC%20Stress/b8851256837192083520/overview
      
      Original change's description:
      > [ic] Add a new MegaDOM IC
      >
      > This patch implements the MegaDOM IC setup and access. A new MegaDOM
      > IC state indicates that we've seen only DOM accessors at this access
      > site.
      >
      > This CL only adds support for DOM getters in LoadIC, other kinds of
      > access will be added in follow on CLs.
      >
      > Still remaining TODO before shipping:
      > 1. Have a mechanism to invalidate the protector
      > 2. Have a mechanism to find the accessors that aren't overloaded
      > 3. Use a new builtin to miss to runtime on access check failure
      >
      > Change-Id: Ie12efe5e9fa284f023043b996d61e7d74e710ee2
      > Bug: v8:11321
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618239
      > Reviewed-by: Omer Katz <omerkatz@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Dan Elphick <delphick@chromium.org>
      > Reviewed-by: Mythri Alle <mythria@chromium.org>
      > Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73733}
      
      Bug: v8:11321
      Change-Id: Ib6a55796f2a3c345d4923f9eaa215a6ff55ed15b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2794437
      Auto-Submit: Maya Lekova <mslekova@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#73734}
      3f8aa89e
    • Sathya Gunasekaran's avatar
      [ic] Add a new MegaDOM IC · c83c9590
      Sathya Gunasekaran authored
      This patch implements the MegaDOM IC setup and access. A new MegaDOM
      IC state indicates that we've seen only DOM accessors at this access
      site.
      
      This CL only adds support for DOM getters in LoadIC, other kinds of
      access will be added in follow on CLs.
      
      Still remaining TODO before shipping:
      1. Have a mechanism to invalidate the protector
      2. Have a mechanism to find the accessors that aren't overloaded
      3. Use a new builtin to miss to runtime on access check failure
      
      Change-Id: Ie12efe5e9fa284f023043b996d61e7d74e710ee2
      Bug: v8:11321
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618239Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73733}
      c83c9590
  25. 30 Mar, 2021 2 commits
  26. 25 Mar, 2021 4 commits
  27. 24 Mar, 2021 2 commits
  28. 23 Mar, 2021 1 commit
  29. 22 Mar, 2021 1 commit
  30. 19 Mar, 2021 1 commit