Skip to content

V
V8
Switch branch/tag
  1. 20 Jan, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Rename type BailoutId to BytecodeOffset · 727d22be
      Jakob Gruber authored 
      This reflects the actual contents of the type, which is an offset into
the bytecode (or certain marker values). Historically, in the days of
FCG the bailout id used to refer to node ids - this is why certain
tracing output still calls the bailout id 'node id' and 'ast id'.
These spots will be fixed in a follow-up CL.

This change is mechanical:

 git grep -l BailoutId | while read f; do \
  sed -i 's/BailoutId/BytecodeOffset/g' $f; done

With a manual component of updating the DeoptimizationData method
name from 'BytecodeOffset' to 'GetBytecodeOffset'.

Bug: v8:11332
Change-Id: I956b947a480bf52263159c0eb1e895360bcbe6d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639754
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72189}
      727d22be
  3. 30 Nov, 2020 1 commit
  5. 05 Aug, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Replace CompilationTarget with a new Code::Kind value · c51041f4
      Jakob Gruber authored 
      With the new Turbofan variants (NCI and Turboprop), we need a way to
distinguish between them both during and after compilation. We
initially introduced CompilationTarget to track the variant during
compilation, but decided to reuse the code kind as the canonical spot to
store this information instead.

Why? Because it is an established mechanism, already available in most
of the necessary spots (inside the pipeline, on Code objects, in
profiling traces).

This CL removes CompilationTarget and adds a new
NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine
various things about a given code kind (e.g.: does this code kind
deopt?).

As a (very large) drive-by, refactor both Code::Kind and
AbstractCode::Kind into a new CodeKind enum class.

Bug: v8:8888
Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69244}
      c51041f4
  7. 22 Jul, 2020 2 commits
    • 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
    • Jakob Gruber's avatar
      [nci] Spawn dedicated NCI compilation jobs · 991fc239
      Jakob Gruber authored 
      This CL introduces a new pipeline mode in which each optimization
triggers both a Turbofan and an NCI compilation job. The TF code is
installed, the NCI code is inserted into the code cache for future
consumption by other contexts.

--turbo-nci enables this mode.

The old configuration (with NCI replacing TF) is still available under
the --turbo-nci-as-highest-tier flag. This flag remains useful for
testing purposes.

Drive-by: Refactor tracing in compiler.cc.

Bug: v8:8888
Change-Id: I62522e61788762250ff717eef84eae914e266f3b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2299360
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68983}
      991fc239
  9. 14 Jul, 2020 1 commit
  11. 22 Jan, 2020 1 commit
  13. 09 Jan, 2020 1 commit
  15. 20 Dec, 2019 1 commit
  17. 17 Dec, 2019 2 commits
  19. 13 Sep, 2019 1 commit
  21. 30 Jul, 2019 1 commit
  23. 18 Jun, 2019 1 commit
  25. 17 Jun, 2019 1 commit
  27. 24 May, 2019 1 commit
  29. 23 May, 2019 1 commit
  31. 02 May, 2019 1 commit
  33. 01 Apr, 2019 1 commit
  35. 12 Mar, 2019 1 commit
  37. 29 Jan, 2019 3 commits
  39. 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
  41. 21 Jan, 2019 1 commit
    • Clemens Hammacher's avatar
      Reland "[wasm] Split compilation in three stages" · 6c2e35b9
      Clemens Hammacher authored 
      This is a reland of 4e1d7c87.
Failure on arm and arm64 is fixed by https://crrev.com/c/1411885.

Original change's description:
> [wasm] Split compilation in three stages
>
> In order to refactor ownership between objects in wasm compilation, the
> compilation (executed by background tasks) is split in three stages:
> getting a compilation unit (while holding a mutex), executing the work
> (without any mutex and without keeping the NativeModule alive), and
> submitting the work (with a mutex again).
>
> This CL prepares this design by splitting compilation from submission.
> Both steps are still executed right after each other. This will be
> changed in a follow-up CL.
>
> R=titzer@chromium.org
> CC=mstarzinger@chromium.org
>
> Bug: v8:8689
> Change-Id: I2f92aee8e2f2d45470d8c63314ed026341630902
> Reviewed-on: https://chromium-review.googlesource.com/c/1414920
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58929}

TBR=titzer@chromium.org

Bug: v8:8689
Change-Id: I58ff07d0e0ac8df0f6ee23c416f992954f4673d2
Reviewed-on: https://chromium-review.googlesource.com/c/1422748Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58959}
      6c2e35b9
  43. 18 Jan, 2019 2 commits
    • Michael Achenbach's avatar
      Revert "[wasm] Split compilation in three stages" · b7cc4f7a
      Michael Achenbach authored 
      This reverts commit 4e1d7c87.

Reason for revert:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20arm%20-%20sim%20-%20debug/14986

Original change's description:
> [wasm] Split compilation in three stages
> 
> In order to refactor ownership between objects in wasm compilation, the
> compilation (executed by background tasks) is split in three stages:
> getting a compilation unit (while holding a mutex), executing the work
> (without any mutex and without keeping the NativeModule alive), and
> submitting the work (with a mutex again).
> 
> This CL prepares this design by splitting compilation from submission.
> Both steps are still executed right after each other. This will be
> changed in a follow-up CL.
> 
> R=​titzer@chromium.org
> CC=​mstarzinger@chromium.org
> 
> Bug: v8:8689
> Change-Id: I2f92aee8e2f2d45470d8c63314ed026341630902
> Reviewed-on: https://chromium-review.googlesource.com/c/1414920
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58929}

TBR=titzer@chromium.org,clemensh@chromium.org

Change-Id: Ic3d0287b354ef5f834b76bc2cdc096d2231f4477
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8689
Reviewed-on: https://chromium-review.googlesource.com/c/1422917Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58932}
      b7cc4f7a
    • Clemens Hammacher's avatar
      [wasm] Split compilation in three stages · 4e1d7c87
      Clemens Hammacher authored 
      In order to refactor ownership between objects in wasm compilation, the
compilation (executed by background tasks) is split in three stages:
getting a compilation unit (while holding a mutex), executing the work
(without any mutex and without keeping the NativeModule alive), and
submitting the work (with a mutex again).

This CL prepares this design by splitting compilation from submission.
Both steps are still executed right after each other. This will be
changed in a follow-up CL.

R=titzer@chromium.org
CC=mstarzinger@chromium.org

Bug: v8:8689
Change-Id: I2f92aee8e2f2d45470d8c63314ed026341630902
Reviewed-on: https://chromium-review.googlesource.com/c/1414920Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58929}
      4e1d7c87
  45. 12 Dec, 2018 1 commit
  47. 07 Dec, 2018 3 commits
  49. 15 Nov, 2018 1 commit
  51. 14 Nov, 2018 2 commits
  53. 29 Oct, 2018 1 commit
  55. 04 Sep, 2018 2 commits
  57. 23 Aug, 2018 1 commit
    • Ben L. Titzer's avatar
      [wasm] Remove WasmCompilationData · 1a5df8eb
      Ben L. Titzer authored 
      The WasmCompilationData was a struct that served as an input/output
mechanism for communicating with the code generator. In particular,
it contained a flag for enabling runtime exception for WASM in the code
generator and it also gathered the protected instruction info from
the code generator to be communicated to the WasmCodeManager.

This CL inlines the exception support flag into OptimizedCompilationInfo
and the protected instruction information into the code generator,
along the lines of other flags and data structures created by the
code generator.

R=mstarzinger@chromium.org

Change-Id: If436636067f1a829a095310a73045fe3301cb694
Reviewed-on: https://chromium-review.googlesource.com/1186409
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55358}
      1a5df8eb
  59. 16 Jul, 2018 1 commit
  61. 10 Jul, 2018 1 commit
    • Michael Starzinger's avatar
      [wasm] Add proper --turbo-stats-wasm flag. · dfffde4a
      Michael Starzinger authored 
      This gathers TurboFan compilation statistics for WebAssembly separately
from the JavaScript statistics. It is a preparation to having multiple
Isolates trigger TurboFan compilations in a shared engine. By adding
compilation statistics to the engine, their lifetime is independent of
any particular Isolate.

R=ahaas@chromium.org

Change-Id: I1bd0fbe6d6bde65ca813ccfd1154558ea6cddb07
Reviewed-on: https://chromium-review.googlesource.com/1131121
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54357}
      dfffde4a