1. 24 Feb, 2022 1 commit
  2. 15 Feb, 2022 1 commit
  3. 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
  4. 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
  5. 04 Feb, 2022 1 commit
  6. 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
  7. 16 Dec, 2021 1 commit
  8. 11 Oct, 2021 1 commit
  9. 24 Jun, 2021 1 commit
  10. 24 Feb, 2021 1 commit
  11. 17 Feb, 2021 1 commit
    • Seth Brenith's avatar
      Reland "[interpreter] Short Star bytecode" · 7be64db4
      Seth Brenith authored
      This is a reland of cf93071c
      
      Original change's description:
      > [interpreter] Short Star bytecode
      >
      > Design doc:
      > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
      >
      > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
      > that we can use a single byte to represent the common operation of
      > storing to a low-numbered register. This generally reduces the quantity
      > of bytecode generated on web sites by 8-9%.
      >
      > In order to not degrade speed, a couple of other changes are required:
      >
      > The existing lookahead logic to check for Star after certain other
      > bytecode handlers is updated to check for these new short Star codes
      > instead. Furthermore, that lookahead logic is updated to contain its own
      > copy of the dispatch jump rather than merging control flow with the
      > lookahead-failed case, to improve branch prediction.
      >
      > A bunch of constants use bytecode size in bytes as a proxy for the size
      > or complexity of a function, and are adjusted downward proportionally to
      > the decrease in generated bytecode size.
      >
      > Other small drive-by fix: update generate-bytecode-expectations to emit
      > \n instead of \r\n on Windows.
      >
      > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#72773}
      
      Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72821}
      7be64db4
  12. 16 Feb, 2021 2 commits
    • Leszek Swirski's avatar
      Revert "[interpreter] Short Star bytecode" · 08a49bbe
      Leszek Swirski authored
      This reverts commit cf93071c.
      
      Reason for revert: Speculative revert because of Mac4 GC stress failure: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/16697/overview
      
      Original change's description:
      > [interpreter] Short Star bytecode
      >
      > Design doc:
      > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
      >
      > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
      > that we can use a single byte to represent the common operation of
      > storing to a low-numbered register. This generally reduces the quantity
      > of bytecode generated on web sites by 8-9%.
      >
      > In order to not degrade speed, a couple of other changes are required:
      >
      > The existing lookahead logic to check for Star after certain other
      > bytecode handlers is updated to check for these new short Star codes
      > instead. Furthermore, that lookahead logic is updated to contain its own
      > copy of the dispatch jump rather than merging control flow with the
      > lookahead-failed case, to improve branch prediction.
      >
      > A bunch of constants use bytecode size in bytes as a proxy for the size
      > or complexity of a function, and are adjusted downward proportionally to
      > the decrease in generated bytecode size.
      >
      > Other small drive-by fix: update generate-bytecode-expectations to emit
      > \n instead of \r\n on Windows.
      >
      > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#72773}
      
      TBR=rmcilroy@chromium.org,mythria@chromium.org,seth.brenith@microsoft.com
      
      Change-Id: I0162b9400861b90bacef27cca9aebc8ab9d74c10
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697350Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72777}
      08a49bbe
    • Seth Brenith's avatar
      [interpreter] Short Star bytecode · cf93071c
      Seth Brenith authored
      Design doc:
      https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
      
      This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
      that we can use a single byte to represent the common operation of
      storing to a low-numbered register. This generally reduces the quantity
      of bytecode generated on web sites by 8-9%.
      
      In order to not degrade speed, a couple of other changes are required:
      
      The existing lookahead logic to check for Star after certain other
      bytecode handlers is updated to check for these new short Star codes
      instead. Furthermore, that lookahead logic is updated to contain its own
      copy of the dispatch jump rather than merging control flow with the
      lookahead-failed case, to improve branch prediction.
      
      A bunch of constants use bytecode size in bytes as a proxy for the size
      or complexity of a function, and are adjusted downward proportionally to
      the decrease in generated bytecode size.
      
      Other small drive-by fix: update generate-bytecode-expectations to emit
      \n instead of \r\n on Windows.
      
      Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#72773}
      cf93071c
  13. 20 Jan, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Rename type BailoutId to BytecodeOffset · 727d22be
      Jakob Gruber authored
      This reflects the actual contents of the type, which is an offset into
      the bytecode (or certain marker values). Historically, in the days of
      FCG the bailout id used to refer to node ids - this is why certain
      tracing output still calls the bailout id 'node id' and 'ast id'.
      These spots will be fixed in a follow-up CL.
      
      This change is mechanical:
      
       git grep -l BailoutId | while read f; do \
        sed -i 's/BailoutId/BytecodeOffset/g' $f; done
      
      With a manual component of updating the DeoptimizationData method
      name from 'BytecodeOffset' to 'GetBytecodeOffset'.
      
      Bug: v8:11332
      Change-Id: I956b947a480bf52263159c0eb1e895360bcbe6d2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639754
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72189}
      727d22be
  14. 15 Dec, 2020 1 commit
    • Ross McIlroy's avatar
      [TurboFan] Avoid serializing BytecodeAnalysis · 6544a1e4
      Ross McIlroy authored
      The SerializerForBackgroundCompilation needs bytecode analysis for loop
      target analysis, but doesn't require the much more expensive liveness
      analysis. In order to move more work off the main thread, perform fast
      bytecode analysis without liveness analysis in
      SerializerForBackgroundCompilation, and then move the full bytecode
      analysis to the background thread in BytecodeGraphBuilder.
      
      BUG=v8:7790,v8:9684
      
      Change-Id: I63ef80ecab8ad0c56953c72be31abc8f5a74b9c1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2593329Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71767}
      6544a1e4
  15. 10 Jul, 2020 1 commit
  16. 20 Mar, 2020 1 commit
  17. 29 Jul, 2019 1 commit
  18. 26 Jul, 2019 1 commit
  19. 15 Jul, 2019 1 commit
  20. 08 Jul, 2019 1 commit
  21. 19 Jun, 2019 1 commit
  22. 23 May, 2019 2 commits
  23. 29 Apr, 2019 1 commit
  24. 22 Jan, 2019 1 commit
  25. 18 Sep, 2018 1 commit
  26. 22 Mar, 2018 1 commit
  27. 27 Feb, 2018 1 commit
  28. 23 Jan, 2018 1 commit
    • Leszek Swirski's avatar
      [ignition] Single-switch generator bytecode · c869d40d
      Leszek Swirski authored
      Currently, yields and awaits inside loops compile to bytecode which
      switches to the top of the loop header, and switch again once inside the
      loop. This is to make loops reducible.
      
      This replaces this switching logic with a single switch bytecode that
      directly jumps to the bytecode being resumed. Among other things, this
      allows us to no longer maintain the generator state after the switch at
      the top of the function, and avoid having to track loop suspend counts.
      
      TurboFan still needs to have reducible loops, so we now insert loop
      header switches during bytecode graph building, for suspends that are
      discovered to be inside loops during bytecode analysis. We do, however,
      do some environment magic across loop headers since we know that we will
      continue switching if and only if we reached that loop header via a
      generator resume. This allows us to generate fewer phis and tighten
      liveness.
      
      Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385
      Reviewed-on: https://chromium-review.googlesource.com/866734
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50804}
      c869d40d
  29. 22 Jan, 2018 1 commit
    • Leszek Swirski's avatar
      [compiler] Propagate liveness across suspends · 41b80eef
      Leszek Swirski authored
      Suspend points (inside generators and async functions) have slightly
      funky semantics when it comes to liveness, as they save and restore a
      chunk of the register file as-is. In particular, this means that
      granular liveness information is lost, as it is assumed that all
      registers in that chunk of the register file are live in a suspend.
      
      Rather than marking that entire chunk of register as live/dead in
      suspend/restore, we can instead pattern-match the set of bytecodes in a
      suspend point, and propagate liveness across them. This tightens
      liveness estimates, and could be used to optimize which values TurboFan
      actually saves when suspending.
      
      Bug: chromium:798137
      Change-Id: I5840cdbfc2c6edb1d3a48cf025f52615b629cdfc
      Reviewed-on: https://chromium-review.googlesource.com/848895
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50757}
      41b80eef
  30. 05 Sep, 2017 1 commit
  31. 31 Aug, 2017 1 commit
  32. 25 Aug, 2017 1 commit
  33. 17 Aug, 2017 1 commit
    • Leszek Swirski's avatar
      [turbofan] Never generate loop exit phis for the accumulator · 1a302730
      Leszek Swirski authored
      The accumulator should never be alive when jumping back to a loop
      header, or jumping out of a loop. This means that as far as far as
      TurboFan is concerned, we never need to create Phis or LoopExitValues
      for the accumulator, as its value should not escape the loop.
      
      For safety, this also augments the IsLivenessValid DCHECK in the
      liveness analysis to check that the accumulator is not live in these
      cases, and amends the bytecode analysis tests to kill the accumulator
      where necessary to ensure this.
      
      As a drive-by, added some comments to the more complex bytecode analysis
      tests, since figuring out what they were for and how to fix them took a
      non-trivial amount of time.
      
      Change-Id: Idecf76a36681d724134c59768650c23cc6b0e9ef
      Reviewed-on: https://chromium-review.googlesource.com/615168
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47388}
      1a302730
  34. 16 Aug, 2017 1 commit
  35. 02 Aug, 2017 1 commit
  36. 02 Jun, 2017 1 commit
    • jarin's avatar
      This is a first step towards reducing the number of stores/loads when... · f0645612
      jarin authored
      This is a first step towards reducing the number of stores/loads when suspending/resuming a generator.
      
      Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs.
      
      Changes:
      
      - SuspendGenerator bytecode now takes register list to save.
      - ResumeGenerator was split into two bytecodes:
        * Resume generator reads the state out and marks the generator as
            'executing'.
        * RestoreGeneratorRegisters reloads the registers from
            the generator.
          + this required adding support for output register list.
      
      - Introduced generator_object_ register in the bytecode generator.
        * in subsequent CLs, I will make better use of it, the goal is
            to get rid if the .generator_object local variable.
      
      - Taught register optimizer to flush unassigned registers.
      
      BUG=v8:6379
      
      Review-Url: https://codereview.chromium.org/2894293003
      Cr-Commit-Position: refs/heads/master@{#45675}
      f0645612
  37. 15 May, 2017 1 commit
  38. 26 Apr, 2017 1 commit