1. 03 Jun, 2022 1 commit
  2. 02 Jun, 2022 1 commit
    • Leszek Swirski's avatar
      Revert "[maglev] Fix dead fallthrough merging" · 403dc1e0
      Leszek Swirski authored
      This reverts commit c7aef552.
      
      Reason for revert: Merged the wrong CL for the fix.
      
      Original change's description:
      > [maglev] Fix dead fallthrough merging
      >
      > Add a method which optionally merges dead fallthrough paths, in case the
      > iteration in EmitUnconditionalDeopt reaches a merge point that is live
      > from another jump but dead on the fallthrough.
      >
      > Bug: v8:7700
      > Change-Id: Ie505cd5356fcf70208f2f6d3e52b805956485f74
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663086
      > Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#80878}
      
      Bug: v8:7700
      Change-Id: I75a21777aecfa08138fcc25a882ae109f3409159
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687649
      Auto-Submit: Leszek Swirski <leszeks@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/main@{#80917}
      403dc1e0
  3. 01 Jun, 2022 2 commits
  4. 31 May, 2022 1 commit
  5. 30 May, 2022 1 commit
  6. 25 May, 2022 1 commit
  7. 24 May, 2022 3 commits
  8. 23 May, 2022 5 commits
  9. 20 May, 2022 1 commit
    • Leszek Swirski's avatar
      [maglev] Add more Int32/Float64 arithmetic nodes · 47090774
      Leszek Swirski authored
      Add Int32/Float64 nodes for:
      
        * Subtract
        * Multiply
        * Divide
      
      and additionally Int32 nodes for
      
        * BitwiseOr/And/Xor
        * ShiftLeft/Right/RightLogical
      
      The latter ones don't have Float64 equivalents since they're implicitly
      Int32 operations. In the future we'll add support for Number feedback by
      adding Float64-to-Int32 conversions and using the Int32 nodes.
      
      The divide node does an Int32 division and deopts if there's a remainder
      to the division -- we may want to make it output a Float64 instead if we
      think that's more likely in real-world code. There's also no peephole
      optimisations for constant operations, which would generate much better
      code, especially for shifts.
      
      Bug: v8:7700
      Change-Id: Ief1d24b46557cf4d2b7929ed50956df7b0d25992
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3652301
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80670}
      47090774
  10. 19 May, 2022 1 commit
  11. 17 May, 2022 3 commits
  12. 16 May, 2022 1 commit
  13. 13 May, 2022 6 commits
  14. 06 May, 2022 2 commits
  15. 05 May, 2022 1 commit
    • Leszek Swirski's avatar
      [maglev] Fix result regalloc clobbering inputs · dc92fe09
      Leszek Swirski authored
      Consider the following
      
        * A ValueNode has inputs A and B
        * Input A has later uses, input B doesn't
        * The ValueNode's result must be in the same register as A
      
      It can then happen that UpdateUses frees B, and the result allocation
      emits a gap move from A's register to B's old register (now free) to
      preserve the value of A when the ValueNode writes into its register.
      This gap move is emmitted before the ValueNode start, which means that
      it clobbers B.
      
      Now, UpdateUses only clears registers _after_ node result allocation, so
      that the known free registers are still the ones before updating uses.
      
      Done naively, this would have bad consequences -- in the case where A
      has no later uses, it would still force the regalloc to save its value
      thinking that it is still live. So, this patch also introduces a concept
      of "AllocationStage" where we're either allocating at the start or end
      of a Node. Inputs are allocated at the start, results at the end. When
      walking registers during an allocation, nodes whose lifetimes end at the
      current node are considered to be dead at the "end" allocation stage,
      and we are allowed to a) use their registers, and b) drop them without
      preserving their value.
      
      Bug: v8:7700
      Change-Id: I5ca764ed04b12269f189577e81eb7e2a27cd1b09
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3625978
      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/main@{#80371}
      dc92fe09
  16. 02 May, 2022 1 commit
  17. 29 Apr, 2022 4 commits
  18. 28 Apr, 2022 4 commits
  19. 27 Apr, 2022 1 commit