1. 12 Nov, 2019 1 commit
  2. 31 Oct, 2019 1 commit
  3. 23 May, 2019 1 commit
  4. 26 Jun, 2017 1 commit
  5. 23 Jun, 2017 1 commit
  6. 11 Jan, 2017 1 commit
    • rmcilroy's avatar
      [compiler] Collect eager inner functions for compilation during renumbering. · a3052cfe
      rmcilroy authored
      This CL modifies the ast-numbering phase to collect function literals which
      should be compiled eagerly. This is then used to eagerly compile the inner
      functions before compiling the outer function. This will be used to queue
      compilation jobs on the CompilerDispatcher in a later CL.
      
      This CL moves the compilation of eager inner functions out of the
      GetSharedFunctionInfo function and instead compiles them explicitly. This
      simplifies GetSharedFunctionInfo and also means there is no need to pass a
      LazyCompilationMode to the function, so this concept has been removed.
      
      BUG=v8:5203,v8:5215
      
      Review-Url: https://codereview.chromium.org/2618553004
      Cr-Commit-Position: refs/heads/master@{#42221}
      a3052cfe
  7. 26 Nov, 2015 1 commit
  8. 25 Aug, 2015 1 commit
    • mtrofin's avatar
      [turbofan] Deferred blocks splintering. · 5d954d65
      mtrofin authored
      This change encompasses what is necessary to enable stack checks in loops without suffering large regressions.
      
      Primarily, it consists of a new mechanism for dealing with deferred blocks by "splintering", rather than splitting, inside deferred blocks.
      
      My initial change was splitting along deferred block boundaries, but the regression introduced by stackchecks wasn't resolved conclusively. After investigation, it appears that just splitting ranges along cold block boundaries leads to a greater opportunity for moves on the hot path, hence the suboptimal outcome.
      
      The alternative "splinters" ranges rather than splitting them. While splitting creates 2 ranges and links them (parent-child), in contrast, splintering creates a new independent range with no parent-child relation to the original. The original range appears as if it has a liveness hole in the place of the splintered one. All thus obtained ranges are then register allocated with no change to the register allocator.
      
      The splinters (cold blocks) do not conflict with the hot path ranges, by construction. The hot path ones have less pressure to split, because we remove a source of conflicts. After allocation, we merge the splinters back to their original ranges and continue the pipeline. We leverage the previous changes made for deferred blocks (determining where to spill, for example).
      
      Review URL: https://codereview.chromium.org/1305393003
      
      Cr-Commit-Position: refs/heads/master@{#30357}
      5d954d65
  9. 31 Oct, 2014 1 commit
  10. 25 Aug, 2014 1 commit
  11. 20 Aug, 2014 1 commit
  12. 03 Jun, 2014 1 commit
  13. 29 Apr, 2014 1 commit
  14. 14 Apr, 2011 1 commit
  15. 07 Apr, 2011 1 commit
  16. 07 Dec, 2010 3 commits
  17. 04 Oct, 2010 1 commit
  18. 30 Sep, 2010 1 commit
  19. 28 Sep, 2010 2 commits
  20. 24 Sep, 2010 1 commit
  21. 24 Aug, 2010 2 commits
  22. 02 Jun, 2010 1 commit
  23. 29 Mar, 2010 1 commit
    • kmillikin@chromium.org's avatar
      Rework flow graph construction. · 81779f63
      kmillikin@chromium.org authored
      The flow graph has been simplified to remove the special branch, join,
      and exit nodes.  All nodes are now basic blocks (possibly empty to
      preserve edge-split form) with a distinguished entry and exit block.
      
      Most trivial expressions are not added to the flow graph as
      instructions.  The assigned variable analyzer has been changed to
      sometimes work right-to-left so that right subexpressions can be
      marked as trivial.
      
      The reaching definitions analysis has been temporarily removed, and
      the analyses that depended on it (primitivity analysis, dead code
      marking) as well.
      
      Review URL: http://codereview.chromium.org/1530003
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4307 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      81779f63
  24. 25 Mar, 2010 1 commit
  25. 24 Mar, 2010 1 commit
  26. 23 Mar, 2010 2 commits
  27. 22 Mar, 2010 2 commits
  28. 19 Mar, 2010 1 commit
  29. 16 Mar, 2010 2 commits
  30. 12 Mar, 2010 4 commits