Skip to content

V
V8
Switch branch/tag
  1. 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
  3. 28 Oct, 2019 1 commit
  5. 17 Jul, 2019 1 commit
  7. 24 May, 2019 1 commit
  9. 29 Mar, 2019 1 commit
  11. 26 Nov, 2018 1 commit
  13. 20 Nov, 2018 1 commit
  15. 04 Sep, 2017 1 commit
  17. 27 Mar, 2017 2 commits
    • Ross McIlroy's avatar
      [TurboFan] Reserve space in scheduler node data for split nodes. · bdb4a8d3
      Ross McIlroy authored 
      When node splitting is enabled new nodes could be created during scheduling.
The Scheduler::node_data_ and Schedule::nodeid_to_block_ zone vectors
reserve enough space for the node count before splitting, however will
have to reallocate space when node splitting occurs. The vectors double
in space by default, meaning the peak zone usage is 3x the required amount
for these vectors as soon as a single node is split. Avoid this in the
common case by reserving 10% extra space for split nodes. The value
10% was choosen since it covers 98.7% of the optimized functions in Octane.

BUG=chromium:700364

Change-Id: Ibabd8d04cffd1eb08cc3b8a12b76892208ef3288
Reviewed-on: https://chromium-review.googlesource.com/458425
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44153}
      bdb4a8d3
    • Ross McIlroy's avatar
      [TurboFan] Lazily allocate scheduled_nodes vectors since most remain empty. · a059e87e
      Ross McIlroy authored 
      The scheduled_nodes_ vector is used to maintain a per-block list of
non-fixed nodes. For most blocks this list remains empty, so lazily
initialize it instead of pre-allocating to save memory.

Also pre-reserve an extra 10% of blocks to avoid reallocting space in the
vector when fusing floating control creates new basic blocks.

BUG=chromium:700364

Change-Id: I9876e6a42bc90c9bff5838620365c18609ed1ee9
Reviewed-on: https://chromium-review.googlesource.com/458919Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44152}
      a059e87e
  19. 21 Mar, 2017 1 commit
  21. 17 Oct, 2016 1 commit
  23. 10 Oct, 2016 1 commit
  25. 07 Oct, 2016 1 commit
  27. 06 Oct, 2016 1 commit
  29. 23 Sep, 2016 1 commit
  31. 22 Sep, 2016 1 commit
  33. 20 Sep, 2016 1 commit
  35. 09 Feb, 2015 1 commit
  37. 03 Feb, 2015 1 commit
  39. 23 Jan, 2015 1 commit
  41. 22 Jan, 2015 1 commit
  43. 02 Dec, 2014 2 commits
  45. 27 Nov, 2014 1 commit
  47. 26 Nov, 2014 1 commit
  49. 11 Nov, 2014 1 commit
  51. 05 Nov, 2014 1 commit
  53. 29 Oct, 2014 2 commits
  55. 23 Oct, 2014 2 commits
  57. 21 Oct, 2014 3 commits
  59. 13 Oct, 2014 3 commits
  61. 10 Oct, 2014 1 commit
  63. 30 Sep, 2014 1 commit