1. 27 Aug, 2019 1 commit
  2. 26 Aug, 2019 1 commit
  3. 23 Aug, 2019 1 commit
  4. 22 Aug, 2019 1 commit
  5. 21 Aug, 2019 1 commit
  6. 16 Aug, 2019 1 commit
  7. 12 Aug, 2019 1 commit
  8. 26 Jul, 2019 1 commit
  9. 12 Jul, 2019 1 commit
  10. 11 Jul, 2019 2 commits
  11. 25 Jun, 2019 1 commit
  12. 19 Jun, 2019 3 commits
  13. 03 Jun, 2019 1 commit
  14. 28 May, 2019 1 commit
  15. 23 May, 2019 4 commits
  16. 22 May, 2019 1 commit
  17. 21 May, 2019 2 commits
  18. 15 May, 2019 2 commits
    • 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
    • Santiago Aboy Solanes's avatar
      [cleanup] MachineType 'rep' variables renamed to 'type' · 0ff813c5
      Santiago Aboy Solanes authored
      Bug: v8:9183
      Change-Id: Idb1910ae30984f548996651e8b2f153531b8cdb0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605729Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61519}
      0ff813c5
  19. 13 May, 2019 1 commit
  20. 10 May, 2019 1 commit
  21. 07 May, 2019 1 commit
  22. 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
  23. 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
  24. 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
  25. 12 Apr, 2019 1 commit
  26. 09 Apr, 2019 1 commit
  27. 01 Apr, 2019 1 commit
  28. 25 Mar, 2019 2 commits
  29. 12 Mar, 2019 1 commit
  30. 18 Feb, 2019 1 commit
    • Mike Stanton's avatar
      Reland "[Torque] Add source positions for Torque files" · b08c6947
      Mike Stanton authored
      Reason for revert/reland: UBSan complained of unaligned reads.
      
      To improve the Torque debugging experience, we can add source positions
      for each line. This information is carried through the generated
      CSA code (in <output directory>/gen/torque-generated/*.cc) and
      embedded as SourcePositions in the Code object.
      
      At snapshot time, these SourcePositions are stripped from the Code
      object and turned into platform-appropriate line number debug
      information.
      
      At this time on Linux, you'll need to build with "is_clang=false"
      in order to use GCC, because crucial steps are missing in Clang's
      ability to convey the information into the binary successfully.
      
      This CL also introduces a flag to control the existing source
      information in CSA code. --enable-source-at-csa-bind is now set
      to false by default because it's a bit confusing to "hop" between
      source lines in .TQ files and in .CC files. I expect to continue
      making adjustments there, as I want to provide helpful
      debugging aids at the CSA level as well as the Torque level.
      The current configuration prioritizes Torque.
      
      TBR=tebbi@chromium.org
      
      Bug: v8:8418
      Change-Id: Idb80467d3679ec2361386fe9b67597b93d7f72cf
      Reviewed-on: https://chromium-review.googlesource.com/c/1475763Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59657}
      b08c6947
  31. 15 Feb, 2019 1 commit
    • Michael Stanton's avatar
      Revert "[Torque] Add source positions for Torque files" · 9542fd8f
      Michael Stanton authored
      This reverts commit 0a24e67a.
      
      Reason for revert: Broke Linux 64 UBSan build with unaligned read in the snapshot. Will investigate...
      
      Original change's description:
      > [Torque] Add source positions for Torque files
      > 
      > To improve the Torque debugging experience, we can add source positions
      > for each line. This information is carried through the generated
      > CSA code (in <output directory>/gen/torque-generated/*.cc) and
      > embedded as SourcePositions in the Code object.
      > 
      > At snapshot time, these SourcePositions are stripped from the Code
      > object and turned into platform-appropriate line number debug
      > information.
      > 
      > At this time on Linux, you'll need to build with "is_clang=false"
      > in order to use GCC, because crucial steps are missing in Clang's
      > ability to convey the information into the binary successfully.
      > 
      > This CL also introduces a flag to control the existing source
      > information in CSA code. --enable-source-at-csa-bind is now set
      > to false by default because it's a bit confusing to "hop" between
      > source lines in .TQ files and in .CC files. I expect to continue
      > making adjustments there, as I want to provide helpful
      > debugging aids at the CSA level as well as the Torque level.
      > The current configuration prioritizes Torque.
      > 
      > A detailed guide on usage to follow (also on v8.dev).
      > 
      > Bug: v8:8418
      > Change-Id: Ib4226877ce4cae451bb4d0c546927e89f4e66b58
      > Reviewed-on: https://chromium-review.googlesource.com/c/1475473
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#59636}
      
      TBR=mvstanton@chromium.org,tebbi@chromium.org
      
      Change-Id: I4ccf94dfdb8b2ba238a60db9ecc8e3ceebef2699
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8418
      Reviewed-on: https://chromium-review.googlesource.com/c/1475757Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59637}
      9542fd8f