1. 21 May, 2019 1 commit
  2. 22 Jan, 2019 1 commit
    • Mike Stanton's avatar
      [Builtins] Infrastructure for source positions in stubs/builtins · df071e94
      Mike Stanton authored
      Now, the CodeAssembler can annotate Nodes with SourcePositions.
      SourcePositions themselves get a new mode "external," in which
      they get a file_id, line and column. The file_id is currently
      maintained in the isolate, mapping to strings for filenames.
      
      Additionally, inlining information is ignored at this point,
      but in the long run I'd like to recognize calls to different
      CSA functions as manual inlinings.
      
      At this point, if you want to see the results in tools like GDB,
      you'll need to build without clang, and use the GCC toolchain.
      GN flag is_clang=false will do the trick.
      
      Bug: v8:8418
      Change-Id: I123cdc041612285fa7d0ba532a625bceeda5d338
      Reviewed-on: https://chromium-review.googlesource.com/c/1322954
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59009}
      df071e94
  3. 04 Jan, 2019 1 commit
    • Peter Marshall's avatar
      [cpu-profiler] Add source positions for inlined function calls · af0428ac
      Peter Marshall authored
      Currently in both kCallerLineNumbers and kLeafNodeLineNumbers modes, we
      correctly capture inline stacks. In leaf number mode, this is simple as
      we simply add the path onto the existing tree. For caller line numbers
      mode this is more complex, because each path through various inlined
      function should be represented in the tree, even when there are
      multiple callsites to the same function inlined.
      
      Currently we don't correctly show line numbers for inlined functions.
      We do actually have this information though, which is generated by
      turbofan and stored in the source_position_table data structure on the
      code object.
      
      This also changes the behavior of the SourcePositionTable class. A
      problem we uncovered is that the PC that the sampler provides for every
      frame except the leaf is the return address of the calling frame. This
      address is *after* the call has already happened. It can be attributed
      to the next line of the function, rather than the calling line, which
      is wrong. We fix that here by using lower_bound in GetSourceLineNumber.
      
      The same problem happens in GetInlineStack - the PC of the caller is
      actually the instruction after the call. The information turbofan
      generates assumes that the instruction after the call is not part of
      the call (fair enough). To fix this we do the same thing as above - use
      lower_bound and then iterate back by one.
      
      TBR=alph@chromium.org
      
      Bug: v8:8575, v8:8606
      Change-Id: Idc4bd4bdc8fb70b70ecc1a77a1e3744a86f83483
      Reviewed-on: https://chromium-review.googlesource.com/c/1374290
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58545}
      af0428ac
  4. 28 Nov, 2018 1 commit
  5. 12 Nov, 2018 1 commit
  6. 16 May, 2018 1 commit
  7. 09 May, 2018 2 commits
  8. 08 May, 2018 1 commit
  9. 04 Apr, 2018 1 commit
  10. 18 Oct, 2017 2 commits
  11. 14 Dec, 2016 1 commit
  12. 22 Nov, 2016 1 commit
    • tebbi's avatar
      [cpu-profiler] use new source position information for deoptimization in cpu profiler · 1b320d20
      tebbi authored
      The new SourcePosition class allows for precise tracking of source positions including the stack of inlinings. This CL makes the cpu profiler use this new information. Before, the cpu profiler used the deoptimization data to reconstruct the inlining stack. However, optimizing compilers (especially Turbofan) can hoist out checks such that the inlining stack of the deopt reason and the inlining stack of the position the deoptimizer jumps to can be different (the old cpu profiler tests and the ones introduced in this cl produce such situations for turbofan). In this case, relying on the deoptimization info produces paradoxical results, where the reported position is before the function responsible is called. Even worse, https://codereview.chromium.org/2451853002/ combines the precise position with the wrong inlining stack from the deopt info, leading to completely wrong results.
      
      Other changes in this CL:
      - DeoptInlinedFrame is no longer needed, because we can compute the correct inlining stack up front.
      - I changed the cpu profiler tests back to test situations where deopt checks are hoisted out in Turbofan and made them robust enough to handle the differences between Crankshaft and Turbofan.
      - I reversed the order of SourcePosition::InliningStack to make it match the cpu profiler convention.
      - I removed CodeDeoptEvent::position, as it is no longer used.
      
      R=alph@chromium.org
      
      BUG=v8:5432
      
      Review-Url: https://codereview.chromium.org/2503393002
      Cr-Commit-Position: refs/heads/master@{#41168}
      1b320d20
  13. 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
  14. 30 Jun, 2016 1 commit
  15. 15 Jan, 2016 1 commit