1. 12 Apr, 2017 2 commits
  2. 30 Mar, 2017 1 commit
  3. 27 Mar, 2017 1 commit
  4. 17 Mar, 2017 1 commit
  5. 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
  6. 02 Mar, 2017 1 commit
  7. 20 Feb, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Unify NodeProperties::InferReceiverMaps. · fc331225
      bmeurer authored
      Unify the three different implementations of InferReceiverMaps, which
      were basically copy&paste with slightly different optimizations applied
      later into a single NodeProperties::InferReceiverMaps helper, which also
      returns a ZoneHandleSet of maps, rather than only a single map.
      
      BUG=v8:5267
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2703133003
      Cr-Commit-Position: refs/heads/master@{#43318}
      fc331225
  8. 17 Feb, 2017 1 commit
  9. 13 Feb, 2017 1 commit
    • Michael Starzinger's avatar
      [turbofan] Correct lazy deopt by {JSCreate} operation. · 6ee0b6ce
      Michael Starzinger authored
      This adds support for deoptimizing into the JSConstructStub after the
      receiver instantiation but before the actual constructor invocation.
      Such a deoptimization point is needed for cases where instantiation
      might be observed (e.g. when new.target is a proxy) and hence might
      trigger a deopt.
      
      We use this new deoptimization point for the "after" frame-state the
      inliner attaches to {JSCreate} nodes being inserted when constructor
      calls are being inlined.
      
      R=jarin@chromium.org
      TEST=mjsunit/regress/regress-5638b
      BUG=v8:5638
      
      Change-Id: I7c72c807ee8fb76d12e0e9ccab86d970ab1a0efd
      Reviewed-on: https://chromium-review.googlesource.com/440125Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43149}
      6ee0b6ce
  10. 10 Feb, 2017 1 commit
    • rmcilroy's avatar
      [Compiler] Enable use of seperate zones for parsing and compiling. · 1fc93f2e
      rmcilroy authored
      In order to allow parallel compilation of eager inner functions, we need to
      seperate the zone used for parsing (which will be shared between all the
      parallel compile jobs) and the zone used for compilation. This CL changes
      CompilationInfo to require a zone (which can be different from the zone in
      ParseInfo). We then seal the ParseInfo zone after parsing and analysis is done
      to prevent any further allocation in that zone, so that it can be shared
      (read-only) with the parallel compile jobs.
      
      BUG=v8:5203
      
      Review-Url: https://codereview.chromium.org/2645403002
      Cr-Commit-Position: refs/heads/master@{#43089}
      1fc93f2e
  11. 07 Feb, 2017 8 commits
  12. 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
  13. 02 Feb, 2017 1 commit
  14. 01 Feb, 2017 2 commits
  15. 24 Jan, 2017 1 commit
  16. 20 Jan, 2017 3 commits
  17. 18 Jan, 2017 1 commit
  18. 11 Jan, 2017 1 commit
    • mstarzinger's avatar
      [turbofan] Graph building is independent of closure. · fc241b90
      mstarzinger authored
      This changes the BytecodeGraphBuilder interface to make the fact that
      graph construction is independent of a closure explicit. A valid graph
      can be constructed by providing only the pair of statically known values
      for SharedFunctionInfo and TypeFeedbackVector. This is in preparation of
      inlining based on the SharedFunctionInfo.
      
      R=jarin@chromium.org
      BUG=v8:2206
      
      Review-Url: https://codereview.chromium.org/2626623002
      Cr-Commit-Position: refs/heads/master@{#42224}
      fc241b90
  19. 05 Jan, 2017 1 commit
  20. 02 Jan, 2017 1 commit
  21. 24 Nov, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Remove inlining support for the deprecated pipeline. · 76fd6f25
      bmeurer authored
      The deprecated pipeline is used for asm.js only, where we forcibly
      disable inlining anyways (for performance reasons), so inlining via
      the AstGraphBuilder is essentially dead code by now, thus there's no
      point in trying to keep that around in the code base.
      
      Also nuke the test-run-inlining.cc file, which would require some heavy
      surgery (for probably little benefit), and move the useful tests for
      mjsunit tests instead.
      
      BUG=v8:2206,v8:5657
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2527053002
      Cr-Commit-Position: refs/heads/master@{#41245}
      76fd6f25
  22. 23 Nov, 2016 1 commit
  23. 14 Nov, 2016 1 commit
    • tebbi's avatar
      This CL enables precise source positions for all V8 compilers. It merges... · c3a6ca68
      tebbi authored
      This CL enables precise source positions for all V8 compilers. It merges compiler::SourcePosition and internal::SourcePosition to a single class used throughout the codebase. The new internal::SourcePosition instances store an id identifying an inlined function in addition to a script offset.
      SourcePosition::InliningId() refers to a the new table DeoptimizationInputData::InliningPositions(), which provides the following data for every inlining id:
       - The inlined SharedFunctionInfo as an offset into DeoptimizationInfo::LiteralArray
       - The SourcePosition of the inlining. Recursively, this yields the full inlining stack.
      Before the Code object is created, the same information can be found in CompilationInfo::inlined_functions().
      
      If SourcePosition::InliningId() is SourcePosition::kNotInlined, it refers to the outer (non-inlined) function.
      So every SourcePosition has full information about its inlining stack, as long as the corresponding Code object is known. The internal represenation of a source position is a positive 64bit integer.
      
      All compilers create now appropriate source positions for inlined functions. In the case of Turbofan, this required using AstGraphBuilderWithPositions for inlined functions too. So this class is now moved to a header file.
      
      At the moment, the additional information in source positions is only used in --trace-deopt and --code-comments. The profiler needs to be updated, at the moment it gets the correct script offsets from the deopt info, but the wrong script id from the reconstructed deopt stack, which can lead to wrong outputs. This should be resolved by making the profiler use the new inlining information for deopts.
      
      I activated the inlined deoptimization tests in test-cpu-profiler.cc for Turbofan, changing them to a case where the deopt stack and the inlining position agree. It is currently still broken for other cases.
      
      The following additional changes were necessary:
       - The source position table (internal::SourcePositionTableBuilder etc.) supports now 64bit source positions. Encoding source positions in a single 64bit int together with the difference encoding in the source position table results in very little overhead for the inlining id, since only 12% of the source positions in Octane have a changed inlining id.
       - The class HPositionInfo was effectively dead code and is now removed.
       - SourcePosition has new printing and information facilities, including computing a full inlining stack.
       - I had to rename compiler/source-position.{h,cc} to compiler/compiler-source-position-table.{h,cc} to avoid clashes with the new src/source-position.cc file.
       - I wrote the new wrapper PodArray for ByteArray. It is a template working with any POD-type. This is used in DeoptimizationInputData::InliningPositions().
       - I removed HInlinedFunctionInfo and HGraph::inlined_function_infos, because they were only used for the now obsolete Crankshaft inlining ids.
       - Crankshaft managed a list of inlined functions in Lithium: LChunk::inlined_functions. This is an analog structure to CompilationInfo::inlined_functions. So I removed LChunk::inlined_functions and made Crankshaft use CompilationInfo::inlined_functions instead, because this was necessary to register the offsets into the literal array in a uniform way. This is a safe change because LChunk::inlined_functions has no other uses and the functions in CompilationInfo::inlined_functions have a strictly longer lifespan, being created earlier (in Hydrogen already).
      
      BUG=v8:5432
      
      Review-Url: https://codereview.chromium.org/2451853002
      Cr-Commit-Position: refs/heads/master@{#40975}
      c3a6ca68
  24. 11 Nov, 2016 1 commit
  25. 07 Nov, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Properly rename receiver on CheckHeapObject. · a758c197
      bmeurer authored
      We need to rename the receiver on CheckHeapObject, because we
      don't canonicalize numbers in SignedSmall range, and thus we
      the representation selection can hand out TaggedSigned values
      for receiver uses, even though we checked for TaggedPointerness
      first.
      
      Note that this is rather hacky and just intended to fix the bug
      ASAP. We need to think about how to deal with representations in
      earlier compilation stages.
      
      BUG=chromium:662410
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2485563002
      Cr-Commit-Position: refs/heads/master@{#40792}
      a758c197
  26. 03 Nov, 2016 1 commit
  27. 02 Nov, 2016 2 commits
    • danno's avatar
      [turbofan] Support variable size argument removal in TF-generated functions · fe552636
      danno authored
      This is preparation for using TF to create builtins that handle variable number of
      arguments and have to remove these arguments dynamically from the stack upon
      return.
      
      The gist of the changes:
      - Added a second argument to the Return node which specifies the number of stack
        slots to pop upon return in addition to those specified by the Linkage of the
        compiled function.
      - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
        handles all tail-call cases except where the return value type differs, this fallback
        was not really useful and in fact caused unexpected behavior with variable
        sized argument popping, since it wasn't possible to materialize a Return node
        with the right pop count from the TailCall without additional context.
      - Modified existing Return generation to pass a constant zero as the additional
        pop argument since the variable pop functionality
      
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2446543002
      Cr-Commit-Position: refs/heads/master@{#40699}
      fe552636
    • machenbach's avatar
      Revert of [turbofan] Support variable size argument popping in TF-generated... · c61902e0
      machenbach authored
      Revert of [turbofan] Support variable size argument popping in TF-generated functions (patchset #13 id:240001 of https://codereview.chromium.org/2446543002/ )
      
      Reason for revert:
      Seems to break arm64 sim debug and blocks roll:
      https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/3294
      
      Original issue's description:
      > [turbofan] Support variable size argument removal in TF-generated functions
      >
      > This is preparation for using TF to create builtins that handle variable number of
      > arguments and have to remove these arguments dynamically from the stack upon
      > return.
      >
      > The gist of the changes:
      > - Added a second argument to the Return node which specifies the number of stack
      >   slots to pop upon return in addition to those specified by the Linkage of the
      >   compiled function.
      > - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
      >   handles all tail-call cases except where the return value type differs, this fallback
      >   was not really useful and in fact caused unexpected behavior with variable
      >   sized argument popping, since it wasn't possible to materialize a Return node
      >   with the right pop count from the TailCall without additional context.
      > - Modified existing Return generation to pass a constant zero as the additional
      >   pop argument since the variable pop functionality
      >
      > LOG=N
      
      TBR=bmeurer@chromium.org,mstarzinger@chromium.org,epertoso@chromium.org,danno@chromium.org
      # Not skipping CQ checks because original CL landed more than 1 days ago.
      NOPRESUBMIT=true
      
      Review-Url: https://codereview.chromium.org/2473643002
      Cr-Commit-Position: refs/heads/master@{#40691}
      c61902e0
  28. 31 Oct, 2016 1 commit
    • danno's avatar
      [turbofan] Support variable size argument removal in TF-generated functions · 5319b50c
      danno authored
      This is preparation for using TF to create builtins that handle variable number of
      arguments and have to remove these arguments dynamically from the stack upon
      return.
      
      The gist of the changes:
      - Added a second argument to the Return node which specifies the number of stack
        slots to pop upon return in addition to those specified by the Linkage of the
        compiled function.
      - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
        handles all tail-call cases except where the return value type differs, this fallback
        was not really useful and in fact caused unexpected behavior with variable
        sized argument popping, since it wasn't possible to materialize a Return node
        with the right pop count from the TailCall without additional context.
      - Modified existing Return generation to pass a constant zero as the additional
        pop argument since the variable pop functionality
      
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2446543002
      Cr-Commit-Position: refs/heads/master@{#40678}
      5319b50c