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. 09 Sep, 2019 1 commit
  7. 29 Jul, 2019 3 commits
    • Clemens Hammacher's avatar
      Reland "[utils] Make BitField final" · 0cabc6a0
      Clemens Hammacher authored
      This is a reland of 658ff200
      
      Original change's description:
      > [utils] Make BitField final
      > 
      > We have hundreds of classes that derive from {BitField} without adding
      > any functionality. This CL switches all such occurrences to 'using'
      > declarations instead.
      > 
      > Before:
      >   class MyBitField : public BitField<int, 6, 4, MyEnum> {};
      > After:
      >   using MyBitField = BitField<int, 6, 4, MyEnum>;
      > 
      > This might reduce compilation time by reducing the number of existing
      > classes.
      > 
      > The old pattern is forbidden now by making {BitField} final.
      > 
      > R=yangguo@chromium.org
      > 
      > Bug: v8:9396, v8:7629
      > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62956}
      
      Bug: v8:9396, v8:7629
      Change-Id: Ic68541af9d1e8d0340691970922f282b24a9767f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724379Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62959}
      0cabc6a0
    • Clemens Hammacher's avatar
      Revert "[utils] Make BitField final" · 753a07db
      Clemens Hammacher authored
      This reverts commit 658ff200.
      
      Reason for revert: Fails no-i18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/27826
      
      Original change's description:
      > [utils] Make BitField final
      > 
      > We have hundreds of classes that derive from {BitField} without adding
      > any functionality. This CL switches all such occurrences to 'using'
      > declarations instead.
      > 
      > Before:
      >   class MyBitField : public BitField<int, 6, 4, MyEnum> {};
      > After:
      >   using MyBitField = BitField<int, 6, 4, MyEnum>;
      > 
      > This might reduce compilation time by reducing the number of existing
      > classes.
      > 
      > The old pattern is forbidden now by making {BitField} final.
      > 
      > R=​yangguo@chromium.org
      > 
      > Bug: v8:9396, v8:7629
      > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62956}
      
      TBR=yangguo@chromium.org,clemensh@chromium.org
      
      Change-Id: I50234a09c77aa89fdcf1e01c2497cc08d3ac79a8
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9396, v8:7629
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724377Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62958}
      753a07db
    • Clemens Hammacher's avatar
      [utils] Make BitField final · 658ff200
      Clemens Hammacher authored
      We have hundreds of classes that derive from {BitField} without adding
      any functionality. This CL switches all such occurrences to 'using'
      declarations instead.
      
      Before:
        class MyBitField : public BitField<int, 6, 4, MyEnum> {};
      After:
        using MyBitField = BitField<int, 6, 4, MyEnum>;
      
      This might reduce compilation time by reducing the number of existing
      classes.
      
      The old pattern is forbidden now by making {BitField} final.
      
      R=yangguo@chromium.org
      
      Bug: v8:9396, v8:7629
      Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62956}
      658ff200
  8. 08 Jul, 2019 1 commit
  9. 27 May, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Replace simple typedefs by using · a335f2ae
      Clemens Hammacher authored
      This replaces all typedefs that define types and not functions by the
      equivalent "using" declaration.
      
      This was done mostly automatically using this command:
      ag -l '\btypedef\b' src test | xargs -L1 \
           perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'
      
      Patchset 2 then adds some manual changes for typedefs for pointer types,
      where the regular expression did not match.
      
      R=mstarzinger@chromium.org
      TBR=yangguo@chromium.org, jarin@chromium.org
      
      Bug: v8:9183
      Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61849}
      a335f2ae
  10. 23 May, 2019 2 commits
  11. 21 May, 2019 1 commit
  12. 12 Mar, 2019 1 commit
  13. 28 Jan, 2019 1 commit
  14. 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
  15. 24 Nov, 2018 1 commit
  16. 16 Oct, 2018 1 commit
  17. 27 Jun, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Store protected instructions in an OwnedVector · ce2d01bc
      Clemens Hammacher authored
      We currently store the protected instructions per code object in a
      {std::unique_ptr<std::vector<ProtectedInstructionData>>}. This wastes
      memory, because it requires two heap allocations, plus the vector might
      over-allocate (and it currently does, because it is filled dynamically
      during compilation).
      This CL changes that to store the protected instructions in an
      {OwnedVector}. This requires one copy after generating the list of
      {ProtectedInstructionData} in an {std::vector} during compilation, but
      saves memory afterwards.
      
      R=mstarzinger@chromium.org
      
      Bug: chromium:856938
      Change-Id: Ie290a17dc32f27fbbfe0c000a52297181c954550
      Reviewed-on: https://chromium-review.googlesource.com/1116701Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54052}
      ce2d01bc
  18. 22 Jun, 2018 1 commit
  19. 23 Mar, 2018 1 commit
  20. 21 Nov, 2017 1 commit
  21. 20 Oct, 2017 1 commit
  22. 18 Oct, 2017 1 commit
  23. 02 Aug, 2017 1 commit
  24. 04 May, 2017 1 commit
  25. 23 Nov, 2016 1 commit
  26. 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
  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. 22 Jun, 2016 1 commit
  32. 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
  33. 05 Apr, 2016 1 commit
  34. 04 Apr, 2016 1 commit
  35. 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
  36. 02 Mar, 2016 2 commits
    • yangguo's avatar
      [debugger] Ensure at least one breakable position per function. · 44e9622a
      yangguo authored
      The function literal consists of a list of statements. Each statement
      is associated with a statement position including break location. The
      only exception to this rule is when the function immediately throws if
      scope resolution found an illegal redeclaration. Make sure that we add a
      break location for this case as well. The debugger relies on this.
      
      R=bmeurer@chromium.org, vogelheim@chromium.org
      BUG=v8:4690
      LOG=N
      
      Review URL: https://codereview.chromium.org/1759603002
      
      Cr-Commit-Position: refs/heads/master@{#34422}
      44e9622a
    • 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