Skip to content

V
V8
Switch branch/tag
  1. 22 Jan, 2020 1 commit
  3. 09 Jan, 2020 1 commit
  5. 27 Nov, 2019 1 commit
    • Georg Neis's avatar
      [turbofan] Remove JSInliningHeuristic::Mode · 98d5d66a
      Georg Neis authored 
      This enum defined three modes of doing inlining:
kGeneralInlining, kRestrictedInlining, kStressInlining.
kStressInlining was unused. kRestrictedInlining meant
that JSInliningHeuristic::Reduce would return NoChange,
but only after wasting some time inspecting calls. This
is now replaced by simply not installing JSInliningHeuristic
as a reducer when inlining is disabled.

Note: There is still a --stress-inline flag, which sets
(through flag implications) a bunch of parameters that affect
inlining.

Change-Id: I05bafbe3f1f35610d7035a2c71c5ac17bdb80758
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1936473
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65196}
      98d5d66a
  7. 05 Jul, 2019 1 commit
  9. 24 May, 2019 1 commit
  11. 08 Apr, 2019 1 commit
  13. 29 Mar, 2019 1 commit
  15. 11 Mar, 2019 1 commit
  17. 15 Nov, 2018 1 commit
  19. 12 Oct, 2018 1 commit
  21. 23 Aug, 2018 1 commit
  23. 15 Jun, 2018 1 commit
  25. 04 Apr, 2018 1 commit
  27. 13 Dec, 2017 1 commit
  29. 18 Sep, 2017 1 commit
    • Mythri's avatar
      [TurboFan] Remove SetForceInline · 5114f14c
      Mythri authored 
      SetForceInline flag is no longer used. This flag was added for
inlining some of the javascript builtins. They are now ported to
TurboFan builtins. This cl removes SetForceInline runtime function
and the corresponding bits in the SharedFunctionInfo. Also update
inlining heuristics to not look for this bit.

Bug: v8:6682
Change-Id: Ie8df9648332b765a556e24609c38b4e55b810527
Reviewed-on: https://chromium-review.googlesource.com/668436Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48065}
      5114f14c
  31. 11 Sep, 2017 1 commit
  33. 06 Sep, 2017 1 commit
  35. 05 Sep, 2017 1 commit
  37. 23 Aug, 2017 1 commit
    • Jaroslav Sevcik's avatar
      Revert "Reland "[turbofan] Polymorphic inlining - try merge map check dispatch... · e26e6d88
      Jaroslav Sevcik authored 
      Revert "Reland "[turbofan] Polymorphic inlining - try merge map check dispatch with function call dispatch.""

This reverts commit 4cee9fbc.

Reason for revert: Breaks on clusterfuzz.

Original change's description:
> Reland "[turbofan] Polymorphic inlining - try merge map check dispatch with function call dispatch."
> 
> This reverts commit 57af6811.
> 
> This adds the checkpoint between the call and the polymorphic load.
> I thought that JSCall with constant target cannot cause eager deopt,
> but Canary seems to disagree (http://crbug.com/718019).
> 
> Bug: v8:5267,chromium:718019
> Change-Id: I552b850db6beb93e733b371ad0e7204513da1dc4
> Reviewed-on: https://chromium-review.googlesource.com/622867
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47521}

TBR=jarin@chromium.org,tebbi@chromium.org,bmeurer@chromium.org

Change-Id: Ib333883fa27b79fcd766c33997cb0ce46547bb94
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5267, chromium:718019
Reviewed-on: https://chromium-review.googlesource.com/628076Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47539}
      e26e6d88
  39. 22 Aug, 2017 1 commit
  41. 20 Aug, 2017 1 commit
    • Jaroslav Sevcik's avatar
      Revert "[turbofan] Polymorphic inlining - try merge map check dispatch with... · 57af6811
      Jaroslav Sevcik authored 
      Revert "[turbofan] Polymorphic inlining - try merge map check dispatch with function call dispatch."

This reverts commit 627c440b.

Reason for revert: Likely breaks Canary.

Original change's description:
> [turbofan] Polymorphic inlining - try merge map check dispatch with function call dispatch.
> 
> This improves delta blue by about >5%. Unfortunately, this still does not help load
> and check elimination because we do not learn maps from control flow.
> 
> Change-Id: I49a97dbc40576b9bc80c87ec2b459e37ba9b4440
> Bug: v8:5267
> Reviewed-on: https://chromium-review.googlesource.com/618328
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47405}

TBR=jarin@chromium.org,bmeurer@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: v8:5267
Change-Id: Id12519ae98b42b57fbef86d0685950f6c85f5082
Reviewed-on: https://chromium-review.googlesource.com/622827Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47457}
      57af6811
  43. 17 Aug, 2017 1 commit
  45. 10 Aug, 2017 2 commits
  47. 20 Jul, 2017 1 commit
  49. 11 Jul, 2017 1 commit
    • Alexandre Talon's avatar
      [Turbofan] Enable reducers to report their name to make reducer tracing clearer · 7a75da34
      Alexandre Talon authored 
      Each reducer now has a virtual reducer_name function, returning its name
(the name of the class containing this reducer). This gets displayed when
using the --trace_turbo_reduction flag. Also when using this flags more
messages are displayed.

Actually when a node is replaced in-place (which is called an update
of the node), other reducers can still update it right after the
in-place replacement. When a node is really replaced (not in-place),
then we stop trying to apply reducers to it before we propagate the
reduction through the relevant nodes.

Before a message got printed only for the last reduction it went
through. So in case a node was reduced in-place several times
in a row, only the last update was printed, or none at all if after
being reduced in-place it got reduced by being replaced by another
node: only the non-in-place replacement was showed. 

Now each time an in-place reduction is applied to a node, a message
gets printed.

Bug: 
Change-Id: Id0f816fecd44c01d0253966c6decc4861be0c2fa
Reviewed-on: https://chromium-review.googlesource.com/563365Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Alexandre Talon <alexandret@google.com>
Cr-Commit-Position: refs/heads/master@{#46552}
      7a75da34
  51. 19 May, 2017 1 commit
  53. 03 May, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Introduce dedicated CallFrequency class. · 23ee7431
      bmeurer authored 
      When we don't know the call count for a given call site (i.e. for
inlined accessors), we put 0 as call frequency so far. But as of
https://codereview.chromium.org/2859433002, this would completely
disable the inlining of those calls, since 0 is interpreted as never
called, which is not what we want. So instead of defaulting to 0,
add a dedicated sentinel, whose value is NaN, which makes the call
site eligible for inlining, but not high priority (as it was before
the CL mentioned above).

BUG=v8:4493,v8:5267
R=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2856103002
Cr-Commit-Position: refs/heads/master@{#45053}
      23ee7431
  55. 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
  57. 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
  59. 14 Sep, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Call frequencies for JSCallFunction and JSCallConstruct. · 0b8a6945
      bmeurer authored 
      Extract the call counts from the type feedback vector during graph
building (either via the AstGraphBuilder or the BytecodeGraphBuilder),
and put them onto the JSCallFunction and JSCallConstruct operators,
so that they work even across inlinine through .apply and .call (which
was previously hacked by creating a temporary type feedback vector
for those).

The next logic step will be to make those call counts into real
relative call frequencies (also during graph building), so that we
can make inlining decisions that make sense for the function being
optimized (where absolute values are misleading).

R=jarin@chromium.org
BUG=v8:5267,v8:5372

Review-Url: https://codereview.chromium.org/2330883002
Cr-Commit-Position: refs/heads/master@{#39400}
      0b8a6945
  61. 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
  63. 09 Nov, 2015 1 commit
  65. 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
  67. 29 Oct, 2015 1 commit
  69. 14 Oct, 2015 1 commit
  71. 07 Oct, 2015 1 commit