1. 10 Feb, 2021 1 commit
  2. 19 Nov, 2020 1 commit
    • Seth Brenith's avatar
      Avoid overflow when profiling builtins · ab52d525
      Seth Brenith authored
      The basic block instrumentation currently uses 32-bit integers, which
      could overflow during a long profiling session. I considered upgrading
      them to 64-bit integers, but generating the correct instrumentation code
      for various architectures would be rather non-trivial. Instead, this
      change uses 64-bit floating-point values, which are simple and also have
      the nice behavior that they saturate rather than overflowing.
      
      Bug: v8:10470
      Change-Id: I60f7456cb750091809803c03a85dd348dc614b58
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2545573Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#71297}
      ab52d525
  3. 22 Jul, 2020 1 commit
    • Seth Brenith's avatar
      Profile-guided optimization of builtins · 922983df
      Seth Brenith authored
      Design doc:
      https://docs.google.com/document/d/1szInbXZfaErWW70d30hJsOLL0Es-l5_g8d2rXm1ZBqI/edit?usp=sharing
      
      V8 can already collect data about how many times each basic block in the
      builtins is run. This change enables using that data for profile-guided
      optimization. New comments in BUILD.gn describe how to use this feature.
      
      A few implementation details worth mentioning, which aren't covered in
      the design doc:
      
      - BasicBlockProfilerData currently contains an array of RPO numbers.
        However, this array is always just [0, 1, 2, 3, ...], so this change
        removes that array. A new DCHECK in BasicBlockInstrumentor::Instrument
        ensures that the removal is valid.
      
      - RPO numbers, while useful for printing data that matches with the
        stringified schedule, are not useful for matching profiling data with
        blocks that haven't been scheduled yet. This change adds a new array
        of block IDs in BasicBlockProfilerData, so that block counters can be
        used for PGO.
      
      - Basic block counters need to be written to a file so that they can be
        provided to a subsequent run of mksnapshot, but the design doc doesn't
        specify the transfer format or what file is used. In this change, I
        propose using the existing v8.log file for that purpose. Block count
        records look like this:
      
        block,TestLessThanHandler,37,29405
      
        This line indicates that block ID 37 in TestLessThanHandler was run
        29405 times. If multiple lines refer to the same block, the reader
        adds them all together. I like this format because it's easy to use:
        - V8 already has robust logic for creating the log file, naming it to
          avoid conflicts in multi-process situations, etc.
        - Line order doesn't matter, and interleaved writes from various
          logging sources are fine, given that V8 writes each line atomically.
        - Combining multiple sources of profiling data is as simple as
          concatenating their v8.log files together.
      
      - It is a good idea to avoid making any changes based on profiling data
        if the function being compiled doesn't match the one that was
        profiled, since it is common to use profiling data downloaded from a
        central lab which is updated only periodically. To check whether a
        function matches, I propose using a hash of the Graph state right
        before scheduling. This might be stricter than necessary, as some
        changes to the function might be small enough that the profile data is
        still relevant, but I'd rather err on the side of not making incorrect
        changes. This hash is also written to the v8.log file, in a line that
        looks like this:
      
        builtin_hash,LdaZeroHandler,3387822046
      
      Bug: v8:10470
      Change-Id: I429e5ce5efa94e01e7489deb3996012cf860cf13
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220765
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69008}
      922983df
  4. 12 Jun, 2020 1 commit
  5. 02 Jun, 2020 1 commit
    • Seth Brenith's avatar
      [diagnostics] Make basic block profiling more configurable · 7ce4b196
      Seth Brenith authored
      This change adds more granular control to the behavior that was
      previously controlled by the single flag --turbo-profiling. With this
      change, it becomes possible to:
      - output information only about builtins, ignoring functions compiled at
        runtime
      - skip the very slow process of writing the schedule and disassembly for
        all builtins, if you only want the block counts and don't need verbose
        output
      
      This change also moves the output step from Shell::OnExit to
      Isolate::DumpAndResetStats so that it's more consistent with other
      features and works in hosts other than d8.
      
      Bug: v8:10470, v8:9119
      Change-Id: I19b1caca3ff27a2e4a6fdc7ad2f8174f8d678b3a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216717Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#68104}
      7ce4b196
  6. 21 May, 2020 1 commit
    • Seth Brenith's avatar
      [diagnostics] Support --turbo-profiling for builtins · 18c73676
      Seth Brenith authored
      Currently, if d8 is run with the --turbo-profiling flag, it prints info
      about every TurboFan-compiled function. This info includes the number of
      times that each basic block in the function was run. It also includes
      text representations of the function's schedule and code, so that the
      person reading the output can associate counters with blocks of code.
      
      The data about each function is currently stored in a
      BasicBlockProfiler::Data instance, which is attached to a list owned by
      the singleton BasicBlockProfiler. Each Data contains an
      std::vector<uint32_t> which represents how many times each block in the
      function has executed. The generated code for each block uses a raw
      pointer into the storage of that vector to implement incrementing the
      counter.
      
      With this change, if you compile with v8_enable_builtins_profiling and
      then run with --turbo-profiling, d8 will print that same info about
      builtins too.
      
      In order to generate code that can survive being serialized to a
      snapshot and reloaded, this change uses counters in the JS heap instead
      of a std::vector outside the JS heap. The steps for instrumentation are
      as follows:
      
      1. Between scheduling and instruction selection, add code to increment
         the counter for each block. The counters array doesn't yet exist at
         this point, and allocation is disallowed, so at this point the code
         refers to a special marker value.
      2. During finalization of the code, allocate a BasicBlockProfilingData
         object on the JS heap containing data equivalent to what is stored in
         BasicBlockProfiler::Data. This includes a ByteArray that is big
         enough to store the counters for each block.
      3. Patch the reference in the BuiltinsConstantsTableBuilder so that
         instead of referring to the marker object, it now refers to this
         ByteArray. Also add the BasicBlockProfilingData object to a list that
         is attached to the heap roots so it can be easily accessed for
         printing.
      
      Because these steps include modifying the BuiltinsConstantsTableBuilder,
      this procedure is only applicable to builtins. Runtime-generated code
      still uses raw pointers into std::vector instances. In order to keep
      divergence between these code paths to a minimum, most work is done
      referring to instances of BasicBlockProfiler::Data (the C++ class), and
      functions are provided to copy back and forth between that type and
      BasicBlockProfilingData (the JS heap object).
      
      This change is intended only to make --turbo-profiling work consistently
      on more kinds of functions, but with some further work, this data could
      form the basis for:
      - code coverage info for fuzzers, and/or
      - hot-path info for profile-guided optimization.
      
      Bug: v8:10470, v8:9119
      Change-Id: Ib556a5bc3abe67cdaa2e3ee62702a2a08b11cb61
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159738
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67944}
      18c73676
  7. 23 May, 2019 1 commit
  8. 21 May, 2019 1 commit
  9. 19 Dec, 2018 1 commit
  10. 14 Aug, 2018 1 commit
  11. 26 Jul, 2018 1 commit
  12. 04 Apr, 2018 1 commit
  13. 16 Mar, 2018 1 commit
  14. 15 Nov, 2017 1 commit
  15. 06 Jun, 2017 1 commit
    • Igor Sheludko's avatar
      [parser] Introduce SharedFunctionInfo::has_shared_name(). · 9a2c18f5
      Igor Sheludko authored
      Properly propagate the fact that the function has a statically known name from
      parser to SharedFunctionInfo objects. The empty string that has been set as
      name before this CL does not help to distinguish cases like:
        var o1 = { ''(){} };
        var o1 = { [foo()](){} };
      or
        var o2 = { get ''(){} };
        var o2 = { get [foo()](){} };
      
      This is a preliminary step for using different layouts for closure objects with
      and without computed names.
      
      TBR=bmeurer@chromium.org, marja@chromium.org
      
      Bug: v8:6459
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I10afa6f4bda7881c3714711a75f720f83c1d875d
      Reviewed-on: https://chromium-review.googlesource.com/522073
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#45744}
      9a2c18f5
  16. 31 Aug, 2016 1 commit
  17. 26 Aug, 2016 1 commit
  18. 11 Dec, 2015 1 commit
  19. 10 Dec, 2015 1 commit
    • jarin's avatar
      [turbofan] Make MachineType a pair of enums. · bb2a830d
      jarin authored
      MachineType is now a class with two enum fields:
      - MachineRepresentation
      - MachineSemantic
      
      Both enums are usable on their own, and this change switches some places from using MachineType to use just MachineRepresentation. Most notably:
      - register allocator now uses just the representation.
      - Phi and Select nodes only refer to representations.
      
      Review URL: https://codereview.chromium.org/1513543003
      
      Cr-Commit-Position: refs/heads/master@{#32738}
      bb2a830d
  20. 23 Sep, 2015 3 commits
  21. 09 Mar, 2015 1 commit
  22. 22 Jan, 2015 1 commit
  23. 23 Dec, 2014 1 commit
  24. 10 Nov, 2014 1 commit
  25. 30 Sep, 2014 2 commits
  26. 29 Sep, 2014 1 commit