1. 02 Jun, 2020 1 commit
  2. 02 Mar, 2020 1 commit
  3. 20 Feb, 2020 1 commit
  4. 10 Feb, 2020 1 commit
  5. 15 Nov, 2019 1 commit
  6. 24 May, 2019 1 commit
  7. 21 May, 2019 1 commit
  8. 28 Mar, 2019 1 commit
  9. 14 Feb, 2019 1 commit
  10. 13 Feb, 2019 1 commit
  11. 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
  12. 24 Nov, 2018 1 commit
  13. 16 Oct, 2018 1 commit
  14. 22 Jun, 2018 1 commit
  15. 23 Mar, 2018 1 commit
  16. 21 Nov, 2017 1 commit
  17. 20 Oct, 2017 1 commit
  18. 26 Jul, 2017 1 commit
  19. 21 Jul, 2017 1 commit
    • Ross McIlroy's avatar
      Revert "[Turbofan] Merged the OSR phase into the graph building phase." · 5d0a4327
      Ross McIlroy authored
      This reverts commit 69c8f16d.
      
      Reason for revert: Causing crashes on Clusterfuzz - http://crbug.com/747154
      
      BUG=chromium:747154
      
      Original change's description:
      > [Turbofan] Merged the OSR phase into the graph building phase.
      > 
      > Now the OSR phase is only used when OSRing from the ast graph builder.
      > When OSRing from Turbofan, the implementation is now in the graph
      > building phase, at the beginning of the VisitBytecode function.
      > We are no longer generating any OSRLoopEntry or OSRNormalEntry nodes,
      > nor nodes for the possible code of the OSRed function which is before
      > the OSRed loops.
      > 
      > The trimming and reducing of the OSR phase is not done either. This
      > change in the way the way the OSR is done enabled to remove the
      > workaround to the bug mentioned below.
      > 
      > Bug: v8:6112
      > Bug: v8:6518
      > Change-Id: I1c9231810b923486d55ea618d550d981d695d797
      > Reviewed-on: https://chromium-review.googlesource.com/543042
      > Commit-Queue: Alexandre Talon <alexandret@google.com>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#46801}
      
      TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,alexandret@google.com
      
      Change-Id: Ifa9bf5d86e888a47cad7fb10446b36fda5029604
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6112, v8:6518
      Reviewed-on: https://chromium-review.googlesource.com/581288Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46817}
      5d0a4327
  20. 20 Jul, 2017 1 commit
    • Alexandre Talon's avatar
      [Turbofan] Merged the OSR phase into the graph building phase. · 69c8f16d
      Alexandre Talon authored
      Now the OSR phase is only used when OSRing from the ast graph builder.
      When OSRing from Turbofan, the implementation is now in the graph
      building phase, at the beginning of the VisitBytecode function.
      We are no longer generating any OSRLoopEntry or OSRNormalEntry nodes,
      nor nodes for the possible code of the OSRed function which is before
      the OSRed loops.
      
      The trimming and reducing of the OSR phase is not done either. This
      change in the way the way the OSR is done enabled to remove the
      workaround to the bug mentioned below.
      
      Bug: v8:6112
      Bug: v8:6518
      Change-Id: I1c9231810b923486d55ea618d550d981d695d797
      Reviewed-on: https://chromium-review.googlesource.com/543042
      Commit-Queue: Alexandre Talon <alexandret@google.com>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46801}
      69c8f16d
  21. 04 May, 2017 1 commit
  22. 27 Jan, 2017 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. 17 Oct, 2016 1 commit
  25. 14 Oct, 2016 1 commit
  26. 20 Sep, 2016 1 commit
  27. 17 Aug, 2016 1 commit
    • rmcilroy's avatar
      Avoid accessing Isolate in source position logging. · b8b4a443
      rmcilroy authored
      Now that all backends use the source position builder to record source
      positions, simplify the code line logging events to take a source
      position table on code creation. This means that the source position
      table builder no longer needs to access the isolate until the table is
      generated. This is required for off-thread bytecode generation.
      
      BUG=v8:5203
      
      Review-Url: https://codereview.chromium.org/2248673002
      Cr-Commit-Position: refs/heads/master@{#38676}
      b8b4a443
  28. 08 Jul, 2016 1 commit
  29. 30 Jun, 2016 1 commit
  30. 28 Jun, 2016 1 commit
  31. 12 May, 2016 1 commit
    • oth's avatar
      [interpreter] Introduce bytecode generation pipeline. · 02b7373a
      oth authored
      This change introduces a pipeline for the final stages of
      bytecode generation.
      
      The peephole optimizer is made distinct from the BytecodeArrayBuilder.
      
      A new BytecodeArrayWriter is responsible for writing bytecode. It
      also keeps track of the maximum register seen and offers a potentially
      smaller frame size.
      
      R=rmcilroy@chromium.org
      LOG=N
      BUG=v8:4280
      
      Review-Url: https://codereview.chromium.org/1947403002
      Cr-Commit-Position: refs/heads/master@{#36220}
      02b7373a
  32. 05 Apr, 2016 1 commit
  33. 15 Mar, 2016 1 commit
    • yangguo's avatar
      [ignition, debugger] correctly set position for return with elided bytecode. · 3c1dc424
      yangguo authored
      We may not emit bytecode for the evaluation of the to-be-returned
      expression. In that case we cannot set two return positions for a return
      statement (one before and one after the expression evaluation). This
      sets the interpreter apart from full-codegen.
      
      Make sure that we always have the second of the two return positions.
      
      Note that we end up with separate test cases for ignition and FCG.
      
      R=rmcilroy@chromium.org, vogelheim@chromium.org
      BUG=v8:4690
      LOG=N
      
      Review URL: https://codereview.chromium.org/1801473003
      
      Cr-Commit-Position: refs/heads/master@{#34771}
      3c1dc424
  34. 02 Mar, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Log source positions for bytecode arrays. · d5820158
      rmcilroy authored
      Add support to log source position offsets to the profiler. As part of
      this change PositionsRecorder is split into two, with the subset needed
      by log.cc moved into log.h and the remainder kept in assembler.h as
      AssemblerPositionsRecorder. The interpreter's source position table
      builder is updated to log positions when the profiler is active.
      
      BUG=v8:4766
      LOG=N
      
      Review URL: https://codereview.chromium.org/1737043002
      
      Cr-Commit-Position: refs/heads/master@{#34416}
      d5820158
  35. 24 Feb, 2016 3 commits
  36. 11 Feb, 2016 1 commit
  37. 10 Feb, 2016 1 commit
  38. 05 Feb, 2016 1 commit