1. 06 Oct, 2020 1 commit
  2. 29 Sep, 2020 1 commit
  3. 28 Sep, 2020 1 commit
  4. 10 Sep, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Implement tier-up (part 3, spawn task & install) · 608018e5
      Jakob Gruber authored
      This is the final part of the tier-up commit series. It implements:
      
      - A prologue in NCI code objects that checks and acts upon the
      optimization marker.
      - Currently, handling is deferred to the InterpreterEntryTrampoline
      but this will change in the future.
      - The lifecycle is otherwise like Ignition-to-Turbofan; the runtime
      profiler marks a function for optimization, the next call to that
      function triggers optimization by calling into runtime, and the
      finished code object is installed both on the JSFunction and the
      optimized code cache.
      - The feedback vector's kOptimizedCodeWeakOrSmiOffset slot is
      currently reused for the mid-to-top tier up.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
      Bug: v8:8888
      Change-Id: Iff50b05ddcc68b25d7ed0f1e0d20af076a1522a0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2361466Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69808}
      608018e5
  5. 24 Aug, 2020 1 commit
    • Jakob Gruber's avatar
      Improve usability of GraphAssembler's Unreachable() · e02e5107
      Jakob Gruber authored
      Prior to this CL, one had to artificially insert a
      basic-block-terminating node after Unreachable. The common pattern was
      
       Unreachable();
       Goto(&some_label);  // Never reached but generates useless code.
      
      This CL improves usability by automatically merging Unreachable nodes
      to the end node, and terminating current effect/control. The updated
      pattern is just
      
       Unreachable();
      
      or in cases where Turboprop must maintain a schedule:
      
       Unreachable(&some_label);
      
      Bug: v8:8888
      Change-Id: I26a0b11b5e67252a6dc3584ae09ed06370f1eacc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362690
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69531}
      e02e5107
  6. 11 Aug, 2020 1 commit
  7. 22 Jul, 2020 1 commit
  8. 20 Jul, 2020 1 commit
  9. 15 Jul, 2020 1 commit
  10. 08 Jun, 2020 1 commit
  11. 25 May, 2020 1 commit
    • Ross McIlroy's avatar
      [TurboProp] Don't try to rewire unreachable blocks to end. · f34771f7
      Ross McIlroy authored
      We can't consistently rewire the successor blocks of an unreachable node to
      disconnect them from the graph when we are trying to maintain the schedule.
      Instead simply leave the code there. As a future optimization we could add a
      proper scheduled dead code elimination phase which can deal with this.
      
      As a side-effect, one of the tests sees a int64 DeadValue, so add support for that
      in the instruction selector.
      
      BUG=chromium:1083272,chromium:1083763,chromium:1084953,v8:9684
      
      Change-Id: I69a6feaeef4eae62110392e27ea848b28bccf787
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209061
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67953}
      f34771f7
  12. 14 May, 2020 1 commit
  13. 07 May, 2020 1 commit
  14. 06 May, 2020 1 commit
    • Ross McIlroy's avatar
      [TurboProp] Fully remove successors from schedule on unreachable. · 66e1c84d
      Ross McIlroy authored
      Fully remove the successor blocks when effect-control-linearization
      reaches an unreachable node and is maintaining the schedule. Previously
      we just updated the current_block_'s successor and removed any
      unreachable predecessors from end, however if the current_block_ is not
      an original block in the schedule, but a new one added due to control
      flow from effect control linearization lowering, the removed successor
      blocks could still be re-connected to the end block when they were
      lowered. Instead, entirely remove these unreachable blocks from the
      predecessor / successor chains, and have the effect-control-linearizer
      avoid lowering these blocks entirely.
      
      BUG=chromium:1076569,v8:9684
      
      Change-Id: I4b4216019d55aef5363d88255726b85df8e7ada5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2179842Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67595}
      66e1c84d
  15. 03 Apr, 2020 1 commit
    • Ross McIlroy's avatar
      [TurboProp] Remove unreachable successor basic blocks from schedule. · 4a2ef63c
      Ross McIlroy authored
      Effect-control-linearizer will update a basic block to connect it
      directly to the end node if it has an Unreachable node. Usually the
      block would already have been connected directly to end (via a Throw
      node) already, however in some cases it can be connected indirectly
      (via a branch, where both end in a throw node).
      
      If this happens, and the Effect-control-linearizer is maintaining the
      schedule (e.g., for TurboProp), it will cause the end block to have
      unreachable predecessor blocks, which can cause issues with the
      register allocator.
      
      To fix this, have the BasicBlockUpdater remove all successor blocks
      from the schedule, when they become Unreachable. Also add some tests
      to cover this in effect-control-linearizer-unittests.
      
      BUG=v8:10332,v8:9684
      
      Change-Id: Ibce140e6d1f61751a86247e6f8c36075723a1e55
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120537
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66994}
      4a2ef63c
  16. 31 Mar, 2020 1 commit
  17. 06 Feb, 2020 1 commit
  18. 23 Jan, 2020 1 commit
  19. 20 Jan, 2020 1 commit
    • Jakob Gruber's avatar
      [gasm] Automatically mark all loop exits as loop peeling candidates · 73ae0c8e
      Jakob Gruber authored
      The loop peeling optimization requires all loop exits to be marked
      with {LoopExit,LoopExitEffect,LoopExitValue} nodes in order to peel
      the first loop iteration. Previously, the graph assembler only marked
      the default loop exit (taken once the loop condition evaluates to
      false).
      
      This CL adds more general support, such that all exits taken inside
      the loop body passed to a ForBuilder are automatically marked. We do
      this by tracking the current loop nesting level and a stack of loop
      headers inside the graph assembler, and creating marker nodes as needed
      inside MergeState.
      
      Bug: v8:9972,chromium:1038297
      Change-Id: I1d0196ead55d6678880f8330c7cc7b8d4f2cea06
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2000740
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65861}
      73ae0c8e
  20. 15 Jan, 2020 2 commits
  21. 25 Dec, 2019 2 commits
  22. 23 Dec, 2019 1 commit
  23. 18 Dec, 2019 1 commit
  24. 16 Dec, 2019 1 commit
  25. 10 Dec, 2019 2 commits
  26. 28 Nov, 2019 5 commits
  27. 27 Nov, 2019 1 commit
    • Jakob Gruber's avatar
      [gasm] Implement ReduceArrayPrototypeForEach using the graph assembler · 971e81ad
      Jakob Gruber authored
      After landing a few relatively simple ports in preceding work, this CL
      ports the more involved Array.prototype.forEach reduction, containing
      checkpoints, JS and runtime calls, loops, and exceptions. With the
      mechanisms introduced in this change, I'd expect a large chunk of
      js-call reductions to be trivially portable.
      
      Newly introduced:
      - IfBuilder0 for if-then-else statements (with optional else).
      - ForBuilder for for-loop statements.
      - MayThrow() for exceptional control flow. Exceptional edges are
        automatically merged and wired into the outer graph if necessary.
      
      Bug: v8:9972
      Change-Id: I835bf90c5871fbd94a1d12721d44b500fbef75e2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1921798Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65193}
      971e81ad
  28. 21 Nov, 2019 1 commit
    • Jakob Gruber's avatar
      [gasm] Implement parts of js call reducer using the graph assembler · 002d5be8
      Jakob Gruber authored
      An initial investigation of using GraphAssembler in JSCallReducer.
      
      This CL ports two simple reductions (ReduceMathUnary,
      ReduceMathBinary) as well as a slightly more involved reduction with
      branching control flow (ReduceStringPrototypeSubstring). The graph
      assembler abstracts away the details of maintaining effect and control
      edges. Resulting code ends up looking very similar to CSA.
      
      Newly introduced:
      - Typing through TNode.
      - IfBuilder1 for nicer if-then-else sequences that return exactly 1
        value. Future CLs will add more convenience builders that follow this
        pattern.
      - Many small readability improvements through helper functions.
      
      Bug: v8:9972
      Change-Id: Iaa186b76c006e07c8d69a74f340a4912577a32a5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914204
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65095}
      002d5be8
  29. 20 Nov, 2019 1 commit
  30. 19 Nov, 2019 1 commit
  31. 07 Nov, 2019 1 commit
  32. 05 Nov, 2019 1 commit
  33. 29 Oct, 2019 1 commit