1. 15 Jul, 2019 1 commit
  2. 23 May, 2019 2 commits
  3. 29 Apr, 2019 1 commit
  4. 11 Sep, 2018 1 commit
  5. 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
  6. 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
  7. 16 Aug, 2017 1 commit
  8. 03 Aug, 2017 1 commit
  9. 26 Jul, 2017 1 commit
  10. 21 Jul, 2017 1 commit
    • Ross McIlroy's avatar
      Revert "[Turbofan] Merged the OSR phase into the graph building phase." · 5d0a4327
      Ross McIlroy authored
      This reverts commit 69c8f16d.
      
      Reason for revert: Causing crashes on Clusterfuzz - http://crbug.com/747154
      
      BUG=chromium:747154
      
      Original change's description:
      > [Turbofan] Merged the OSR phase into the graph building phase.
      > 
      > Now the OSR phase is only used when OSRing from the ast graph builder.
      > When OSRing from Turbofan, the implementation is now in the graph
      > building phase, at the beginning of the VisitBytecode function.
      > We are no longer generating any OSRLoopEntry or OSRNormalEntry nodes,
      > nor nodes for the possible code of the OSRed function which is before
      > the OSRed loops.
      > 
      > The trimming and reducing of the OSR phase is not done either. This
      > change in the way the way the OSR is done enabled to remove the
      > workaround to the bug mentioned below.
      > 
      > Bug: v8:6112
      > Bug: v8:6518
      > Change-Id: I1c9231810b923486d55ea618d550d981d695d797
      > Reviewed-on: https://chromium-review.googlesource.com/543042
      > Commit-Queue: Alexandre Talon <alexandret@google.com>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46801}
      
      TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,alexandret@google.com
      
      Change-Id: Ifa9bf5d86e888a47cad7fb10446b36fda5029604
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6112, v8:6518
      Reviewed-on: https://chromium-review.googlesource.com/581288Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46817}
      5d0a4327
  11. 20 Jul, 2017 1 commit
    • Alexandre Talon's avatar
      [Turbofan] Merged the OSR phase into the graph building phase. · 69c8f16d
      Alexandre Talon authored
      Now the OSR phase is only used when OSRing from the ast graph builder.
      When OSRing from Turbofan, the implementation is now in the graph
      building phase, at the beginning of the VisitBytecode function.
      We are no longer generating any OSRLoopEntry or OSRNormalEntry nodes,
      nor nodes for the possible code of the OSRed function which is before
      the OSRed loops.
      
      The trimming and reducing of the OSR phase is not done either. This
      change in the way the way the OSR is done enabled to remove the
      workaround to the bug mentioned below.
      
      Bug: v8:6112
      Bug: v8:6518
      Change-Id: I1c9231810b923486d55ea618d550d981d695d797
      Reviewed-on: https://chromium-review.googlesource.com/543042
      Commit-Queue: Alexandre Talon <alexandret@google.com>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46801}
      69c8f16d
  12. 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
  13. 26 Apr, 2017 1 commit
  14. 15 Dec, 2016 1 commit
  15. 08 Dec, 2016 1 commit
  16. 05 Dec, 2016 1 commit
  17. 29 Nov, 2016 3 commits
  18. 22 Nov, 2016 1 commit
    • leszeks's avatar
      [ignition] Replace branch+loop analysis with a single pass · 292c4a0a
      leszeks authored
      Now that we have a JumpLoop bytecode, we can heavily simplify the
      branch/loop analysis by assuming that only JumpLoop bytecodes are
      backwards edges, and performing the loop analysis as a single
      (backwards) pass.
      
      This allows us to get rid of the branch analysis entirely, and builds a
      framework to do liveness analysis in the same pass.
      
      Review-Url: https://codereview.chromium.org/2519983002
      Cr-Commit-Position: refs/heads/master@{#41194}
      292c4a0a