1. 21 Jan, 2021 1 commit
  2. 28 Jul, 2020 1 commit
  3. 29 Apr, 2020 1 commit
  4. 08 Jan, 2020 1 commit
  5. 16 Dec, 2019 1 commit
  6. 12 Dec, 2019 2 commits
  7. 10 Dec, 2019 2 commits
  8. 20 Nov, 2019 1 commit
  9. 11 Nov, 2019 1 commit
  10. 24 Oct, 2019 1 commit
    • Ross McIlroy's avatar
      [TurboProp] Remove the second schedule for TurboProp. · 22fd9555
      Ross McIlroy authored
      This rearranges the TurboProp pipeline to avoid the need for a second
      schedule of the graph. To do this, it moves the final schedule creation
      before effect-control-linearization (which used a temporary schedule
      previously, and with TurboFan). It then enables the block updater in the
      graph assembler for effect control linearization and does select and
      memory lowering in a new ScheduledMachineLowering phase to maintain
      this existing schedule during these lowering passes.
      
      BUG=v8:9684
      
      Change-Id: I6a7790b010f8b152dd01d85aa95ee5d4f99087a5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847351
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64537}
      22fd9555
  11. 23 Oct, 2019 1 commit
  12. 25 Sep, 2019 1 commit
  13. 02 Aug, 2019 1 commit
  14. 01 Aug, 2019 1 commit
  15. 26 Jul, 2019 1 commit
    • Santiago Aboy Solanes's avatar
      [ptr-compr][gc] Propagate tenuring in StoreField with Compress nodes. · 0a424ac1
      Santiago Aboy Solanes authored
      The propagation of tenuring from outer allocations to inner allocations
      was blocked in pointer compression since we now had Compress nodes between
      AllocateRaw and StoreField.
      
      This was causing issues in GC. It popped up in the Octane2.1/Splay
      benchmark, where we had big regressions.
      
      This CL updates the memory optimizer so that it can use the Compress nodes
      as bridges and can perform the optimization successfully. Note that the
      Compress nodes only appear on the value input of the StoreField.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
      Bug: v8:7703, v8:9519
      Change-Id: I6b0cc67955c6cc696e8c426b85c87a1794098ed0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714650Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62938}
      0a424ac1
  16. 17 Jul, 2019 1 commit
  17. 11 Jul, 2019 2 commits
  18. 09 Jul, 2019 1 commit
  19. 17 Jun, 2019 1 commit
  20. 14 Jun, 2019 2 commits
  21. 12 Jun, 2019 1 commit
  22. 28 May, 2019 2 commits
  23. 24 May, 2019 1 commit
  24. 21 May, 2019 1 commit
  25. 15 May, 2019 1 commit
    • Tobias Tebbi's avatar
      Reland: [csa] verify skipped write-barriers in MemoryOptimizer · a19c3ffb
      Tobias Tebbi authored
      With very few exceptions, this verifies all skipped write-barriers in
      CSA and Torque, showing that the MemoryOptimizer together with some
      type information on the stored value are enough to avoid unsafe skipped
      write-barriers.
      
      Changes to CSA:
      SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
      MemoryOptimizer by default.
      Type information about the stored values (TNode<Smi>) is exploited to
      safely skip write barriers for stored Smi values.
      In some cases, the code is re-structured to make it easier to consume
      for the MemoryOptimizer (manual branch and load elimination).
      
      Changes to the MemoryOptimizer:
      Improve the MemoryOptimizer to remove write barriers:
      - When the store happens to a CSA-generated InnerAllocate, by ignoring
        Bitcasts and additions.
      - When the stored value is the HeapConstant of an immortal immovable root.
      - When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
      - Fast C-calls are treated as non-allocating.
      - Runtime calls can be white-listed as non-allocating.
      
      Remaining missing cases:
      - C++-style iterator loops with inner pointers.
      - Inner allocates that are reloaded from a field where they were just stored
        (for example an elements backing store). Load elimination would fix that.
      - Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
        We could handle that in Torque.
      - Double-aligned allocations, which are not lowered in the MemoryOptimizer
        but in CSA.
      
      Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
      can be handled by overload resolution (in Torque and C++).
      
      Reland Change: Support pointer compression operands.
      
      R=jarin@chromium.org
      TBR=mvstanton@chromium.org
      
      Bug: v8:7793
      Change-Id: I84e1831eb6bf9be14f36db3f8b485ee4fab6b22e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1612904
      Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61522}
      a19c3ffb
  26. 06 May, 2019 1 commit
  27. 02 May, 2019 1 commit
  28. 26 Apr, 2019 1 commit
    • Ross McIlroy's avatar
      Revert "[csa] verify skipped write-barriers in MemoryOptimizer" · dd6c9536
      Ross McIlroy authored
      This reverts commit da7322c0.
      
      Reason for revert: Breaking the pointer compression bots, e.g.:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20pointer%20compression/3047
      
      Original change's description:
      > [csa] verify skipped write-barriers in MemoryOptimizer
      > 
      > With very few exceptions, this verifies all skipped write-barriers in
      > CSA and Torque, showing that the MemoryOptimizer together with some
      > type information on the stored value are enough to avoid unsafe skipped
      > write-barriers.
      > 
      > Changes to CSA:
      > SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
      > MemoryOptimizer by default.
      > Type information about the stored values (TNode<Smi>) is exploited to
      > safely skip write barriers for stored Smi values.
      > In some cases, the code is re-structured to make it easier to consume
      > for the MemoryOptimizer (manual branch and load elimination).
      > 
      > Changes to the MemoryOptimizer:
      > Improve the MemoryOptimizer to remove write barriers:
      > - When the store happens to a CSA-generated InnerAllocate, by ignoring
      >   Bitcasts and additions.
      > - When the stored value is the HeapConstant of an immortal immovable root.
      > - When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
      > - Fast C-calls are treated as non-allocating.
      > - Runtime calls can be white-listed as non-allocating.
      > 
      > Remaining missing cases:
      > - C++-style iterator loops with inner pointers.
      > - Inner allocates that are reloaded from a field where they were just stored
      >   (for example an elements backing store). Load elimination would fix that.
      > - Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
      >   We could handle that in Torque.
      > - Double-aligned allocations, which are not lowered in the MemoryOptimizer
      >   but in CSA.
      > 
      > Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
      > can be handled by overload resolution (in Torque and C++).
      > 
      > R=​jarin@chromium.org
      > TBR=mvstanton@chromium.org
      > 
      > Change-Id: I0af9b710673f350e0fe81c2e59f37da93c024b7c
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571414
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61016}
      
      TBR=mvstanton@chromium.org,jarin@chromium.org,tebbi@chromium.org
      
      Change-Id: I36877cd6d08761726ef8dce8a3e3f2ce3eebe6cf
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585732Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61038}
      dd6c9536
  29. 25 Apr, 2019 1 commit
    • Tobias Tebbi's avatar
      [csa] verify skipped write-barriers in MemoryOptimizer · da7322c0
      Tobias Tebbi authored
      With very few exceptions, this verifies all skipped write-barriers in
      CSA and Torque, showing that the MemoryOptimizer together with some
      type information on the stored value are enough to avoid unsafe skipped
      write-barriers.
      
      Changes to CSA:
      SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
      MemoryOptimizer by default.
      Type information about the stored values (TNode<Smi>) is exploited to
      safely skip write barriers for stored Smi values.
      In some cases, the code is re-structured to make it easier to consume
      for the MemoryOptimizer (manual branch and load elimination).
      
      Changes to the MemoryOptimizer:
      Improve the MemoryOptimizer to remove write barriers:
      - When the store happens to a CSA-generated InnerAllocate, by ignoring
        Bitcasts and additions.
      - When the stored value is the HeapConstant of an immortal immovable root.
      - When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
      - Fast C-calls are treated as non-allocating.
      - Runtime calls can be white-listed as non-allocating.
      
      Remaining missing cases:
      - C++-style iterator loops with inner pointers.
      - Inner allocates that are reloaded from a field where they were just stored
        (for example an elements backing store). Load elimination would fix that.
      - Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
        We could handle that in Torque.
      - Double-aligned allocations, which are not lowered in the MemoryOptimizer
        but in CSA.
      
      Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
      can be handled by overload resolution (in Torque and C++).
      
      R=jarin@chromium.org
      TBR=mvstanton@chromium.org
      
      Change-Id: I0af9b710673f350e0fe81c2e59f37da93c024b7c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571414
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61016}
      da7322c0
  30. 24 Apr, 2019 1 commit
    • Tobias Tebbi's avatar
      [csa][turbofan] allow large object allocation · 343898ed
      Tobias Tebbi authored
      Add suport for large object space allocations in Turbofan and use it
      from CSA when young large objects are enabled. This maintains the
      Turbofan invariant that the generation is statically predictable.
      
      In principle, this enables write barrier elimination for large objects
      allocated from Torque/CSA. But it doesn't seem to trigger much yet,
      probably we have to improve the MemoryOptimizer.
      
      Bug: v8:7793
      
      Change-Id: I7ea7d0cb549573db65fafe5df5edf67e0ce90893
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1565905Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60984}
      343898ed
  31. 28 Mar, 2019 1 commit
    • Jaroslav Sevcik's avatar
      [turbofan] Analyze loops in memory optimizer. · c62a6da5
      Jaroslav Sevcik authored
      Currently, we are flushing current allocation group state on loop entry.
      With this CL, we only flush the state for loops that can allocate.
      Non-allocating loop will preserve the state. This enables more
      optimization opportunities for write barrier elimination and
      allocation folding.
      
      Unforutnately, the optimization will only trigger for
      compiler-introduced loops - user loops always contain stack check
      (which can allocate).
      
      Bug: v8:8984
      Change-Id: I5a47accec92455f4aabb0129800773596712029a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1541043Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60501}
      c62a6da5
  32. 12 Mar, 2019 1 commit
  33. 07 Mar, 2019 1 commit
  34. 05 Feb, 2019 1 commit
  35. 15 Jan, 2019 1 commit