1. 23 May, 2019 1 commit
  2. 21 May, 2019 1 commit
  3. 15 Nov, 2018 1 commit
  4. 10 Apr, 2018 1 commit
    • Matheus Marchini's avatar
      interpreter: make interpreted frames distinguishable in the native stack · ada64b58
      Matheus Marchini authored
      Before Turbofan/Ignition it was possible to use external profilers to
      sample running V8/Node.js processes and generate reports/FlameGraphs
      from that. It's still possible to do so, but non-optimized JavaScript
      functions appear in the stack as InterpreterEntryTrampoline. This commit
      adds a runtime flag which makes interpreted frames visible on the
      process' native stack as distinguishable functions, making the sampled
      data gathered by external profilers such as Linux perf and DTrace more
      useful.
      
      R=bmeurer@google.com, franzih@google.com, jarin@google.com, yangguo@google.com
      
      Bug: v8:7155
      Change-Id: I3dc8876aa3cd9f1b9766624842a7cc354ccca415
      Reviewed-on: https://chromium-review.googlesource.com/959081
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52533}
      ada64b58
  5. 04 Apr, 2018 1 commit
  6. 22 Sep, 2017 1 commit
  7. 10 Aug, 2017 1 commit
  8. 09 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. 28 Apr, 2017 1 commit
  13. 21 Mar, 2017 1 commit
  14. 05 Dec, 2016 1 commit
  15. 06 Oct, 2016 1 commit
  16. 05 Oct, 2016 2 commits
    • jarin's avatar
      Revert of [turbofan] Osr value typing + dynamic type checks on entry.... · ff81734c
      jarin authored
      Revert of [turbofan] Osr value typing + dynamic type checks on entry. (patchset #5 id:80001 of https://codereview.chromium.org/2384113002/ )
      
      Reason for revert:
      Tanks the world.
      
      Original issue's description:
      > [turbofan] Osr value typing + dynamic type checks on entry.
      >
      > This introduces a new OsrGuard node that is inserted during graph building
      > to guard the inferred type of the OSR value.
      >
      > The type of the OSR value is inferred by running the typer before OSR
      > deconstruction, and then taking the type from the phi that takes the
      > OSR value. After the deconstruction, we throw the types away.
      >
      > At the moment we only support the SignedSmall OSR type and we always
      > pick the tagged representation. Later, we might want to support more
      > types (such as Number) and pick better representations (int32/float64).
      >
      > This CL also removes the OSR deconstruction tests because they build
      > unrealistic graph (no effect chain, no loop termination). I considered
      > adding the effect chains to the tests, but this would make the tests
      > even more brittle.
      >
      > Committed: https://crrev.com/1f5dc90a900d222da44bee3eff171a2ba1e3c076
      > Cr-Commit-Position: refs/heads/master@{#39971}
      
      TBR=bmeurer@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Review-Url: https://codereview.chromium.org/2395783002
      Cr-Commit-Position: refs/heads/master@{#39985}
      ff81734c
    • jarin's avatar
      [turbofan] Osr value typing + dynamic type checks on entry. · 1f5dc90a
      jarin authored
      This introduces a new OsrGuard node that is inserted during graph building
      to guard the inferred type of the OSR value.
      
      The type of the OSR value is inferred by running the typer before OSR
      deconstruction, and then taking the type from the phi that takes the
      OSR value. After the deconstruction, we throw the types away.
      
      At the moment we only support the SignedSmall OSR type and we always
      pick the tagged representation. Later, we might want to support more
      types (such as Number) and pick better representations (int32/float64).
      
      This CL also removes the OSR deconstruction tests because they build
      unrealistic graph (no effect chain, no loop termination). I considered
      adding the effect chains to the tests, but this would make the tests
      even more brittle.
      
      Review-Url: https://codereview.chromium.org/2384113002
      Cr-Commit-Position: refs/heads/master@{#39971}
      1f5dc90a
  17. 12 Sep, 2016 1 commit
  18. 09 Sep, 2016 1 commit
  19. 31 Aug, 2016 1 commit
  20. 09 Aug, 2016 1 commit
  21. 27 Jul, 2016 1 commit
    • mstarzinger's avatar
      [interpreter] Implement OSR graph construction from bytecode. · 1314406c
      mstarzinger authored
      This implements graph construction for entry via on-stack replacement
      within the {BytecodeGraphBuilder}. Entry points are at loop headers
      similar to previous OSR implementations. All interpreter registers are
      addressable via {OsrValue} nodes in the graph. Currently we rely on
      {OsrPoll} bytecodes to be placed right after loop headers (i.e. at the
      targets of back edges).
      
      R=jarin@chromium.org
      BUG=v8:4764
      
      Review-Url: https://codereview.chromium.org/2171083004
      Cr-Commit-Position: refs/heads/master@{#38083}
      1314406c
  22. 26 Nov, 2015 1 commit
  23. 24 Sep, 2015 1 commit
    • mstarzinger's avatar
      [turbofan] Make Node::set_op safer via wrapper. · da9c42dd
      mstarzinger authored
      This introduces the NodeProperties::ChangeOp helper which guards node
      operator changes so that additional checking can be done without any
      additional dependencies being pulled into the Node class. For now only
      the input count is checked, but additional checking might follow.
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1366753003
      
      Cr-Commit-Position: refs/heads/master@{#30916}
      da9c42dd
  24. 16 Sep, 2015 1 commit
  25. 18 Aug, 2015 1 commit
    • danno's avatar
      [turbofan] Unify referencing of stack slots · cbbaf9ea
      danno authored
      Previously, it was not possible to specify StackSlotOperands for all
      slots in both the caller and callee stacks. Specifically, the region
      of the callee's stack including the saved return address, frame
      pointer, function pointer and context pointer could not be addressed
      by the register allocator/gap resolver.
      
      In preparation for better tail call support, which will use the gap
      resolver to reconcile outgoing parameters, this change makes it
      possible to address all slots on the stack, because slots in the
      previously inaccessible dead zone may become parameter slots for
      outgoing tail calls. All caller stack slots are accessible as they
      were before, with slot -1 corresponding to the last stack
      parameter. Stack slot indices >= 0 access the callee stack, with slot
      0 corresponding to the callee's saved return address, 1 corresponding
      to the saved frame pointer, 2 corresponding to the current function
      context, 3 corresponding to the frame marker/JSFunction, and slots 4
      and above corresponding to spill slots.
      
      The following changes were specifically	needed:
      
      * Frame	has been changed to explicitly manage three areas of the
        callee frame, the fixed header, the spill slot area, and the
        callee-saved register area.
      * Conversions from stack slot indices to fp offsets all now go through
        a common bottleneck: OptimizedFrame::StackSlotOffsetRelativeToFp
      * The generation of deoptimization translation tables has been changed
        to support the new stack slot indexing scheme. Crankshaft, which
        doesn't support the new slot numbering in its register allocator,
        must adapt the indexes when creating translation tables.
      * Callee-saved parameters are now kept below spill slots, not above,
        to support saving only the optimal set of used registers, which is
        only known after register allocation is finished and spill slots
        have been allocated.
      
      Review URL: https://codereview.chromium.org/1261923007
      
      Cr-Commit-Position: refs/heads/master@{#30224}
      cbbaf9ea
  26. 06 Jul, 2015 3 commits
    • bmeurer's avatar
      [turbofan] Reland "Add new JSFrameSpecialization reducer." and "Perform OSR... · ef661b08
      bmeurer authored
      [turbofan] Reland "Add new JSFrameSpecialization reducer." and "Perform OSR deconstruction early and remove type propagation.".
      
      We have to reland these two commits at once, because the first breaks
      some asm.js benchmarks without the second. The change was reverted
      because of bogus checks in the verifier, which will not work in the
      presence of OSR (and where hidden because of the type back propagation
      hack in OSR so far). Original messages are below:
      
      [turbofan] Add new JSFrameSpecialization reducer.
      
      The JSFrameSpecialization specializes an OSR graph to the current
      unoptimized frame on which we will perform the on-stack replacement.
      This is used for asm.js functions, where we cannot reuse the OSR
      code object anyway because of context specialization, and so we could as
      well specialize to the max instead.
      
      It works by replacing all OsrValues in the graph with their values
      in the JavaScriptFrame.
      
      The idea is that using this trick we get better performance without
      doing the unsound backpropagation of types to OsrValues later. This
      is the first step towards fixing OSR for TurboFan.
      
      [turbofan] Perform OSR deconstruction early and remove type propagation.
      
      This way we don't have to deal with dead pre-OSR code in the graph
      and risk optimizing the wrong code, especially we don't make
      optimistic assumptions in the dead code that leaks into the OSR code
      (i.e. deopt guards are in dead code, but the types propagate to OSR
      code via the OsrValue type back propagation).
      
      BUG=v8:4273
      LOG=n
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1226673005
      
      Cr-Commit-Position: refs/heads/master@{#29486}
      ef661b08
    • machenbach's avatar
      Revert "[turbofan] Add new JSFrameSpecialization reducer." · 9e71cdba
      machenbach authored
      Also revert "[turbofan] Perform OSR deconstruction early and remove type propagation."
      
      This reverts commit b0a852e8.
      
      This reverts commit cdbb6c48.
      
      NOTRY=true
      NOTREECHECKS=true
      BUG=v8:4273
      LOG=n
      TBR=bmeurer@chromium.org
      
      Review URL: https://codereview.chromium.org/1225743002
      
      Cr-Commit-Position: refs/heads/master@{#29480}
      9e71cdba
    • bmeurer's avatar
      [turbofan] Perform OSR deconstruction early and remove type propagation. · cdbb6c48
      bmeurer authored
      This way we don't have to deal with dead pre-OSR code in the graph and
      risk optimizing the wrong code, especially we don't make optimistic
      assumptions in the dead code that leaks into the OSR code (i.e. deopt
      guards are in dead code, but the types propagate to OSR code via the
      OsrValue type back propagation).
      
      BUG=v8:4273
      LOG=n
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1215333005
      
      Cr-Commit-Position: refs/heads/master@{#29478}
      cdbb6c48
  27. 19 Jun, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Proper dead code elimination as regular reducer. · 733a2463
      bmeurer authored
      The three different concerns that the ControlReducer used to deal with
      are now properly separated into
      
        a.) DeadCodeElimination, which is a regular AdvancedReducer, that
            propagates Dead via control edges,
        b.) CommonOperatorReducer, which does strength reduction on common
            operators (i.e. Branch, Phi, and friends), and
        c.) GraphTrimming, which removes dead->live edges from the graph.
      
      This will make it possible to run the DeadCodeElimination together with
      other passes that actually introduce Dead nodes, i.e. typed lowering;
      and it opens the door for general inlining without two stage fix point
      iteration.
      
      To make the DeadCodeElimination easier and more uniform, we basically
      reverted the introduction of DeadValue and DeadEffect, and changed the
      Dead operator to produce control, value and effect. Note however that
      this is not a requirement, but merely a way to make dead propagation
      easier and more uniform. We could always go back and decide to have
      different Dead operators if some other change requires that.
      
      Note that there are several additional opportunities for cleanup now,
      i.e. OSR deconstruction could be a regular reducer now, and we don't
      need to use TheHole as dead value marker in the GraphReducer. And we can
      actually run the dead code elimination together with the other passes
      instead of using separate passes over the graph.  We will do this in
      follow up CLs.
      
      R=jarin@chromium.org, mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/1193833002
      
      Cr-Commit-Position: refs/heads/master@{#29146}
      733a2463
  28. 17 Jun, 2015 1 commit
  29. 12 Jun, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Use appropriate type for NodeId. · c487aba7
      bmeurer authored
      Up until now we used int32_t for NodeId, but that was not ideal because
      negative values are invalid for NodeId and we use it as an array index
      for example in the NodeMarker class, where C++ compilers on x64 have to
      generate code that does proper sign extension for the indices, which is
      completely unnecessary.
      
      R=svenpanne@chromium.org
      
      Review URL: https://codereview.chromium.org/1178403004
      
      Cr-Commit-Position: refs/heads/master@{#28997}
      c487aba7
  30. 26 May, 2015 1 commit
  31. 06 May, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Add support for advanced reducers. · 7b33409b
      bmeurer authored
      An AdvancedReducer is basically a regular Reducer with an editor
      that can perform graph editing operations beyond changing or
      replacing the node that is currently being reduced. The GraphReducer
      is the default implementation of the AdvancedReducer::Editor interface.
      
      The ControlReducerImpl is now just an AdvancedReducer, which
      temporarily requires a Finish method in the reducer to implement
      the dead node trimming until we move that to the GraphReducer
      (which in turn requires that all loops are connected to End).
      
      Review URL: https://codereview.chromium.org/1122423003
      
      Cr-Commit-Position: refs/heads/master@{#28251}
      7b33409b
  32. 27 Apr, 2015 1 commit
  33. 17 Mar, 2015 1 commit
  34. 19 Feb, 2015 2 commits
  35. 17 Feb, 2015 2 commits