1. 15 Mar, 2017 1 commit
    • Michael Starzinger's avatar
      [turbofan] Elide redundant {IfSuccess} control projections. · 6fca2cfa
      Michael Starzinger authored
      This changes the IR to no longer require single {IfSuccess} projection
      nodes unless there is a corresponding {IfException} node that links the
      potentially throwing call to an exception handler. This reduces graph
      size as well as compilation time when exception handlers aren't present.
      
      The new invariant for potentially throwing nodes is: Nodes that can
      potentially throw either have both IfSuccess/IfException projections as
      the only control uses and no direct control uses, or no projections at
      all and solely direct control uses.
      
      R=jarin@chromium.org
      
      Change-Id: I3d9cd816d74ad5af13e0673da7ec7a98f1ecdc7e
      Reviewed-on: https://chromium-review.googlesource.com/449715
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43814}
      6fca2cfa
  2. 03 Mar, 2017 1 commit
  3. 06 Feb, 2017 1 commit
    • mstarzinger's avatar
      [turbofan] Enable inlining based on SharedFunctionInfo. · b628aba0
      mstarzinger authored
      This adapts the inlining logic to allow for inlining based solely on a
      statically known underlying SharedFunctionInfo instead of a concrete
      closure of the call target.
      
      In cases where the closure is known, its bound context is constant
      promoted just as before. In the new cases where only the SFI for an
      entire class of closures is known, we use the dynamic SSA-value of the
      bound context.
      
      R=bmeurer@chromium.org
      BUG=v8:2206
      
      Review-Url: https://codereview.chromium.org/2626783003
      Cr-Commit-Position: refs/heads/master@{#42968}
      b628aba0
  4. 01 Feb, 2017 2 commits
  5. 17 Nov, 2016 1 commit
  6. 16 Nov, 2016 2 commits
  7. 11 Nov, 2016 1 commit
  8. 23 Sep, 2016 3 commits
  9. 14 Sep, 2016 2 commits
  10. 13 Sep, 2016 2 commits
  11. 12 Sep, 2016 1 commit
  12. 09 Sep, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Initial support for polymorphic inlining. · 7d4ab7d4
      bmeurer authored
      For call sites where the target is not a known constant, but potentially
      a list of known constants (i.e. a Phi with all HeapConstant inputs), we
      still record the call site as a potential candidate for inlining.
      In case the heuristic picks that candidate for inlining, we
      expand the call site to a dispatched call site and invoke the
      actual inlining logic for all the nested call sites.
      
      Like Crankshaft, we currently allow up to 4 targets for polymorphic inlining,
      although we might want to refine that later.
      
      This approach is different from what Crankshaft does in
      that we don't duplicate the evaluation of the parameters per polymorphic
      case. Instead we first perform the load of the target (which usually
      dispatches based on the receiver map), then we evaluate all the
      parameters, and then we dispatch again based on the known targets. This
      might generate better or worse code compared to what Crankshaft does,
      and for the cases where we generate worse code (i.e. because we have
      only trivial parameters or no parameters at all), we might want to
      investigate optimizing away the double dispatch in the
      future.
      
      R=mvstanton@chromium.org
      BUG=v8:5267,v8:5365
      
      Review-Url: https://codereview.chromium.org/2325943002
      Cr-Commit-Position: refs/heads/master@{#39302}
      7d4ab7d4
  13. 31 Aug, 2016 1 commit
  14. 29 Aug, 2016 1 commit
    • bgeron's avatar
      [turbofan] Also inline into try blocks. · 791118fc
      bgeron authored
      This removes test/webkit/fast/js/stack-overflow-arrity-catch.js, which tests that the stack overflows in a very particular way. It doesn't seem to test anything important, and only used to work because we didn't inline into try-blocks.
      
      BUG=
      R=jarin
      
      Review-Url: https://codereview.chromium.org/2216353002
      Cr-Commit-Position: refs/heads/master@{#38976}
      791118fc
  15. 03 Aug, 2016 1 commit
  16. 30 May, 2016 1 commit
  17. 21 Mar, 2016 1 commit
  18. 07 Dec, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Don't try to inling dead nodes. · 1c44aa0e
      bmeurer authored
      The JSInliningHeuristic keeps a list of nodes, which might have been
      killed by other reducers before the JSInliningHeuristic looks at it
      again, so it has to check whether nodes are dead before trying to
      expand them later (this is similar to what the ValueNumberingReducer
      needs to do with its internal table).
      
      R=mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/1508643002
      
      Cr-Commit-Position: refs/heads/master@{#32652}
      1c44aa0e
  19. 04 Dec, 2015 1 commit
  20. 01 Dec, 2015 1 commit
  21. 13 Nov, 2015 1 commit
  22. 12 Nov, 2015 2 commits
  23. 11 Nov, 2015 1 commit
  24. 09 Nov, 2015 2 commits
  25. 03 Nov, 2015 1 commit
    • mstarzinger's avatar
      [turbofan] Use sorted set in JSInliningHeuristic. · 2a4336d9
      mstarzinger authored
      This changes the inlining candidates to be stored in a sorted set of
      unique entries instead of a vector. We can avoid the final sorting
      operation by amortizing the cost across insertions and also duplicate
      entries are not created in the first place. Duplicate entries cause
      crashes when candidates are processed.
      
      R=bmeurer@chromium.org
      BUG=chromium:549113
      LOG=n
      
      Review URL: https://codereview.chromium.org/1430553003
      
      Cr-Commit-Position: refs/heads/master@{#31742}
      2a4336d9
  26. 29 Oct, 2015 1 commit
  27. 15 Oct, 2015 1 commit
  28. 14 Oct, 2015 1 commit
  29. 07 Oct, 2015 1 commit