Skip to content

V
V8
Switch branch/tag
  1. 15 Nov, 2016 32 commits
  3. 14 Nov, 2016 8 commits
    • ahaas's avatar
      [wasm] Reimplement function verification in the module decoder. · 1bde8304
      ahaas authored 
      This CL adds the function verification option to the module decoder.
Therefore we can remove the verification in wasm-module-runner.cc

R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2496203002
Cr-Commit-Position: refs/heads/master@{#40977}
      1bde8304
    • caitp's avatar
      [builtins] Take fast path in Array.prototype.keys() only if length is an Smi · 2a350ed4
      caitp authored 
      Do not take the fast path for Array.prototype.keys() if the array length is not
guaranteed to be an Smi.

BUG=660925, v8:5388
R=bmeurer@chromium.org, mstarzinger@chromium.org

Review-Url: https://codereview.chromium.org/2496323002
Cr-Commit-Position: refs/heads/master@{#40976}
      2a350ed4
    • 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
    • caitp's avatar
      [tests] skip es6/array-iterator-turbo on deopt_fuzzer · 372d905d
      caitp authored 
      BUG=v8:5388
R=bmeurer@chromium.org
NOTRY=true

Review-Url: https://codereview.chromium.org/2496063003
Cr-Commit-Position: refs/heads/master@{#40974}
      372d905d
    • franzih's avatar
      [Interpreter] Add CallRuntime() for 5 arguments. · c0291e12
      franzih authored 
      CodeAssembler::CallRuntime() with 5 arguments was declared but
not implemented.

BUG=

Review-Url: https://codereview.chromium.org/2503523002
Cr-Commit-Position: refs/heads/master@{#40973}
      c0291e12
    • ulan's avatar
      [heap] Use size_t for heap and space counters. · 71a7bca9
      ulan authored 
      BUG=chromium:652721

Review-Url: https://codereview.chromium.org/2490523003
Cr-Commit-Position: refs/heads/master@{#40972}
      71a7bca9
    • clemensh's avatar
      [wasm] Make reported "lines" on stack frames 1-based · 0c6fa172
      clemensh authored 
      In captured stack traces, all lines and columns must be 1-based.
Even though this makes things a bit ugly, we have to comply also for
wasm locations, where line and column encode function index and byte
offset (both are originally 0-based).

If we don't comply, the frontend might complain, as e.g. DevTools does.

BUG=chromium:659715
R=yangguo@chromium.org, kozyatinskiy@chromium.org
CC=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2493943002
Cr-Commit-Position: refs/heads/master@{#40971}
      0c6fa172
    • caitp's avatar
      [builtins] implement JSBuiltinReducer for ArrayIteratorNext() · 7f21e67b
      caitp authored 
      Adds a protector cell to prevent inlining (which will likely lead to deopt
loops) when a JSArrayIterator's array transitions from a fast JSArray to a
slow JSArray (such as, when the array is touched during iteration in a way
which triggers a map transition).

Also adds TODO comments relating to the spec update proposed by Dan at
https://github.com/tc39/ecma262/pull/724

BUG=v8:5388
R=bmeurer@chromium.org, mstarzinger@chromium.org
TBR=hpayer@chromium.org, ulan@chromium.org

Review-Url: https://codereview.chromium.org/2484003002
Cr-Commit-Position: refs/heads/master@{#40970}
      7f21e67b