Skip to content

V
V8
Switch branch/tag
  1. 23 Nov, 2016 1 commit
  3. 17 Nov, 2016 1 commit
  5. 16 Nov, 2016 3 commits
  7. 15 Nov, 2016 1 commit
  9. 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
  11. 11 Nov, 2016 1 commit
  13. 09 Nov, 2016 1 commit
  15. 03 Nov, 2016 2 commits
  17. 02 Nov, 2016 1 commit
  19. 19 Oct, 2016 1 commit
  21. 17 Oct, 2016 3 commits
  23. 14 Oct, 2016 1 commit
  25. 13 Oct, 2016 1 commit
  27. 10 Oct, 2016 2 commits
  29. 07 Oct, 2016 3 commits
  31. 06 Oct, 2016 2 commits
  33. 05 Oct, 2016 6 commits
    • bmeurer's avatar
      [turbofan][x64] Improve code generation for external reference access. · 7500e507
      bmeurer authored 
      Properly fold external reference access into memory operands whenever
possible, i.e. for accessing the allocation top/limit, similar to what
we do in Crankshaft and hand-written native code. This only works when
the serializer is disabled, i.e. doesn't apply to the stubs in the
snapshot (for now). This reduces register pressure especially around
allocations where we'd currently need two registers to hold both the
allocation top and limit pointers in registers (on x64).

R=epertoso@chromium.org

Review-Url: https://codereview.chromium.org/2398603002
Cr-Commit-Position: refs/heads/master@{#39993}
      7500e507
    • 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
    • epertoso's avatar
      [turbofan] Introduces a step to verify the machine graph. · 83a93560
      epertoso authored 
      It is currently being rolled behind the --turbo_verify_machine_graph flag.

BUG=

Review-Url: https://codereview.chromium.org/2388313003
Cr-Commit-Position: refs/heads/master@{#39976}
      83a93560
    • bmeurer's avatar
      [turbofan] Properly specialize JSCreateIterResultObject map. · 50c458a3
      bmeurer authored 
      If possible, take the constant map from the (known) native context for
JSCreateIterResultObject, so that subsequent map checks can be
eliminated in case of iterator inlining.

R=jarin@chromium.org
BUG=v8:3822

Review-Url: https://codereview.chromium.org/2394783002
Cr-Commit-Position: refs/heads/master@{#39974}
      50c458a3
    • 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
    • jarin's avatar
      [turbofan] Check instruction input/output count limits in instruction selector. · a974970c
      jarin authored 
      BUG=chromium:625966

Review-Url: https://codereview.chromium.org/2390303002
Cr-Commit-Position: refs/heads/master@{#39970}
      a974970c
  35. 27 Sep, 2016 1 commit
  37. 23 Sep, 2016 1 commit
  39. 22 Sep, 2016 2 commits
  41. 15 Sep, 2016 1 commit
    • mstarzinger's avatar
      [turbofan] Allow inlining into BytecodeGraphBuilder graph. · a4005907
      mstarzinger authored 
      This is a first implementation of inlining into graphs that have been
created using the {BytecodeGraphBuilder}. Note that inlining sticks to
graphs of the same kind, we only ever inline AstGraph into AstGraph or
BytecodeGraph into BytecodeGraph, no mixed inlining.

R=bmeurer@chromium.org,rmcilroy@chromium.org
TEST=cctest/test-run-inlining
BUG=v8:5251

Review-Url: https://codereview.chromium.org/2262033003
Cr-Commit-Position: refs/heads/master@{#39439}
      a4005907
  43. 14 Sep, 2016 2 commits
    • bmeurer's avatar
      [turbofan] Collect invocation counts and compute relative call frequencies. · c7d7ca36
      bmeurer authored 
      Add a notion of "invocation count" to the baseline compilers, which
increment a special slot in the TypeFeedbackVector for each invocation
of a given function (the optimized code doesn't currently collect this
information).

Use this invocation count to relativize the call counts on the call
sites within the function, so that the inlining heuristic has a view
of relative importance of a call site rather than some absolute numbers
with unclear meaning for the current function. Also apply the call site
frequency as a factor to all frequencies in the inlinee by passing this
to the graph builders so that the importance of a call site in an
inlinee is relative to the topmost optimized function.

Note that all functions that neither have literals nor need type
feedback slots will share a single invocation count cell in the
canonical empty type feedback vector, so their invocation count is
meaningless, but that doesn't matter since we only use the invocation
count to relativize call counts within the function, which we only have
if we have at least one type feedback vector (the CallIC slot).

See the design document for additional details on this change:
https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8

BUG=v8:5267,v8:5372
R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org

Review-Url: https://codereview.chromium.org/2337123003
Cr-Commit-Position: refs/heads/master@{#39410}
      c7d7ca36
    • mstarzinger's avatar
      [turbofan] Remove remnants from JavaScript stubs support. · 4e442641
      mstarzinger authored 
      This removes some leftover code which avoided adding stack checks to
stubs being compiled via the normal JavaScript pipeline, which we no
longer do.

R=bmeurer@chromium.org

Review-Url: https://codereview.chromium.org/2333973003
Cr-Commit-Position: refs/heads/master@{#39404}
      4e442641
  45. 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
  47. 07 Sep, 2016 1 commit