1. 14 Feb, 2022 1 commit
    • Leszek Swirski's avatar
      [compiler] Make accumulator index 0 in liveness bitvectors · 2b96e854
      Leszek Swirski authored
      Previously, the accumulator was at the end of liveness bitvectors, which
      meant that checking for accumulator liveness required a length lookup.
      This CL moves it to the start of the bitvector, with registers starting
      at index 1 -- the assumption is that the addition of 1 to the index on
      register liveness access can be constant folded away.
      
      As a cleanup, replace all the custom liveness printing code with a
      single unified ToString. This places the accumulator at the end of the
      printed liveness, to avoid having to change test expectations (also, the
      position of the accumulator is now an implementation detail). As a
      similar cleanup, change StateValue node building to use the
      BytecodeLivenessState interface rather than the underlying bitvector.
      These two cleanups allow us to remove the raw bitvector accessor from
      liveness entirely.
      
      Change-Id: Ic2744b5e8e16b8527e6a4e8d3b4ddad7096289d9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3455144
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79066}
      2b96e854
  2. 11 Feb, 2022 1 commit
    • Leszek Swirski's avatar
      [compiler] Change liveness to use a flat array · 3d02ccf7
      Leszek Swirski authored
      Bytecode liveness needs a mapping from offset to liveness. This was
      previously a hashmap with a very weak hash (the identity function) and
      both inserts and lookups showed up as a non-trivial costs during
      compilation.
      
      Now, replace the hashmap with a simple flat array of liveness, indexed
      by offset, pre-sized to the size of the bytecode. This will have a lot
      of empty entries, but will have much better runtime performance and
      probably ends up not much less memory efficient as a hashmap if the
      hashmap has to resize inside the Zone, and is likely negligible compared
      to the other compilation memory overheads.
      
      Change-Id: Id21375bfcbf0d53b5ed9c41f30cdf7fde66ee699
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3455802Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79049}
      3d02ccf7
  3. 21 Dec, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler] Share liveness across straight-line bytecode · 4465c321
      Leszek Swirski authored
      Straight-line bytecode with exactly one "next" bytecode (i.e. everything
      that can't affect control flow) will always have the same "out" liveness
      as the next bytecode's "in" liveness. For those cases, we can save a bit
      of time and memory by aliasing the pointers between the bytecode's out
      liveness and the next bytecode's in liveness, and skipping copying
      between them.
      
      This is done by specializing the current liveness update on whether this
      is the first pass (which will allocate and initialize the liveness
      bitvectors) or an update pass (which will revisit loops to collect
      liveness crossing over the back-edge, and propagate this liveness
      through the loop bodies). On the first pass, we can delay allocation of
      the out liveness until we know it needs to be union of multiple in
      livenesses, and on the update pass we can skip it if it is an alias.
      
      As a drive-by, tweak BitVector::CopyFrom to require copying from a
      vector with the same size (same as Union or Intersect), and move the
      only different sized vector use (in Resize) to be inline.
      
      Change-Id: Iad1b2e1b927a37ad925ef68e2a224152aaa2ba18
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3350452
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78425}
      4465c321
  4. 15 Jul, 2020 1 commit
  5. 10 Jul, 2020 1 commit
  6. 08 Dec, 2016 1 commit
  7. 29 Nov, 2016 3 commits