1. 23 Dec, 2019 1 commit
  2. 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
  3. 25 Sep, 2019 1 commit
  4. 01 Aug, 2019 1 commit
  5. 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
  6. 17 Jul, 2019 1 commit
  7. 28 May, 2019 1 commit
  8. 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
  9. 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
  10. 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
  11. 29 Mar, 2019 1 commit
  12. 12 Mar, 2019 1 commit
  13. 05 Feb, 2019 1 commit
  14. 17 Sep, 2018 1 commit
  15. 14 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Initial Word64 support in representation selection. · 6346cdb6
      Benedikt Meurer authored
      This adds support to TurboFan's representation selection for the Word64
      representation, and makes use of that to handle indices for memory access
      and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
      etc.). These instructions had previously used Word32 as representation
      for the indices / sizes, and then internally converted it to the correct
      representation (aka Word64 on 64-bit architectures) later on, but that
      was kind of brittle, and sometimes led to weird generated code.
      
      The change thus only adds support to convert integer values in the safe
      integer range from all kinds of representations to Word64 (on 64-bit
      architectures). We don't yet handle the opposite direction and none of
      the representation selection heuristics for the numeric operations were
      changed so far. This will be done in follow-up CLs.
      
      This CL itself is supposed to be neutral wrt. functionality, and only
      serves as a starting point, and a cleanup for the (weird) implicit
      Word64 index/size handling.
      
      Bug: v8:7881, v8:8015, v8:8171
      Design-Document: http://bit.ly/turbofan-word64
      Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
      Reviewed-on: https://chromium-review.googlesource.com/1224932
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55886}
      6346cdb6
  16. 30 Apr, 2018 1 commit
    • Jaroslav Sevcik's avatar
      Replace array index masking with the poisoning approach. · f53dfd93
      Jaroslav Sevcik authored
      The idea is to mark all the branches and loads participating in array
      bounds checks, and let them contribute-to/use the poisoning register.
      In the code, the marks for array indexing operations now contain
      "Critical" in their name. By default (--untrusted-code-mitigations),
      we only instrument the "critical" operations with poisoning.
      
      With that in place, we also remove the array masking approach based
      on arithmetic.
      
      Since we do not propagate the poison through function calls,
      we introduce a node for poisoning an index that is passed through
      function call - the typical example is the bounds-checked index
      that is passed to the CharCodeAt builtin.
      
      Most of the code in this CL is threads through the three levels of
      protection (safe, critical, unsafe) for loads, branches and flags.
      
      Bug: chromium:798964
      
      Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b
      Reviewed-on: https://chromium-review.googlesource.com/995413
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52883}
      f53dfd93
  17. 27 Mar, 2018 1 commit
    • Tobias Tebbi's avatar
      [turbofan] unify interpreter and JIT speculation poisoning · 1ef6c437
      Tobias Tebbi authored
      This CL changes the poisoning in the interpreter to use the
      infrastructure used in the JIT.
      
      This does not change the original flag semantics:
      
      --branch-load-poisoning enables JIT mitigations as before.
      
      --untrusted-code-mitigation enables the interpreter mitigations
        (now realized using the compiler back-end), but does not enable
        the back-end based mitigations for the Javascript JIT. So in effect
        --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers
        use the same mechanics (including changed register allocation) that
        --branch-load-poisoning enables for the JIT.
      
      Bug: chromium:798964
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27
      Reviewed-on: https://chromium-review.googlesource.com/928881Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52243}
      1ef6c437
  18. 21 Mar, 2018 1 commit
  19. 05 Mar, 2018 1 commit
  20. 10 Nov, 2017 1 commit
  21. 08 Nov, 2017 2 commits
  22. 21 Aug, 2017 1 commit
  23. 03 Jan, 2017 1 commit
  24. 20 Sep, 2016 1 commit
  25. 10 May, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Initial version of allocation folding and write barrier elimination. · b8229ec4
      bmeurer authored
      This adds a new pass MemoryOptimizer that walks over the effect chain
      from Start and lowers all Allocate, LoadField, StoreField, LoadElement,
      and StoreElement nodes, trying to fold allocations into allocation
      groups and eliminate write barriers on StoreField and StoreElement if
      possible (i.e. if the object belongs to the current allocation group and
      that group allocates in new space).
      
      R=hpayer@chromium.org, jarin@chromium.org
      BUG=v8:4931, chromium:580959
      LOG=n
      
      Review-Url: https://codereview.chromium.org/1963583004
      Cr-Commit-Position: refs/heads/master@{#36128}
      b8229ec4