1. 19 Oct, 2020 1 commit
    • Jakob Gruber's avatar
      [deoptimizer] Change deopt entries into builtins · 7f58ced7
      Jakob Gruber authored
      While the overall goal of this commit is to change deoptimization
      entries into builtins, there are multiple related things happening:
      
      - Deoptimization entries, formerly stubs (i.e. Code objects generated
        at runtime, guaranteed to be immovable), have been converted into
        builtins. The major restriction is that we now need to preserve the
        kRootRegister, which was formerly used on most architectures to pass
        the deoptimization id. The solution differs based on platform.
      - Renamed DEOPT_ENTRIES_OR_FOR_TESTING code kind to FOR_TESTING.
      - Removed heap/ support for immovable Code generation.
      - Removed the DeserializerData class (no longer needed).
      - arm64: to preserve 4-byte deopt exits, introduced a new optimization
        in which the final jump to the deoptimization entry is generated
        once per Code object, and deopt exits can continue to emit a
        near-call.
      - arm,ia32,x64: change to fixed-size deopt exits. This reduces exit
        sizes by 4/8, 5, and 5 bytes, respectively.
      
      On arm the deopt exit size is reduced from 12 (or 16) bytes to 8 bytes
      by using the same strategy as on arm64 (recalc deopt id from return
      address). Before:
      
       e300a002       movw r10, <id>
       e59fc024       ldr ip, [pc, <entry offset>]
       e12fff3c       blx ip
      
      After:
      
       e59acb35       ldr ip, [r10, <entry offset>]
       e12fff3c       blx ip
      
      On arm64 the deopt exit size remains 4 bytes (or 8 bytes in same cases
      with CFI). Additionally, up to 4 builtin jumps are emitted per Code
      object (max 32 bytes added overhead per Code object). Before:
      
       9401cdae       bl <entry offset>
      
      After:
      
       # eager deoptimization entry jump.
       f95b1f50       ldr x16, [x26, <eager entry offset>]
       d61f0200       br x16
       # lazy deoptimization entry jump.
       f95b2b50       ldr x16, [x26, <lazy entry offset>]
       d61f0200       br x16
       # the deopt exit.
       97fffffc       bl <eager deoptimization entry jump offset>
      
      On ia32 the deopt exit size is reduced from 10 to 5 bytes. Before:
      
       bb00000000     mov ebx,<id>
       e825f5372b     call <entry>
      
      After:
      
       e8ea2256ba     call <entry>
      
      On x64 the deopt exit size is reduced from 12 to 7 bytes. Before:
      
       49c7c511000000 REX.W movq r13,<id>
       e8ea2f0700     call <entry>
      
      After:
      
       41ff9560360000 call [r13+<entry offset>]
      
      Bug: v8:8661,v8:8768
      Change-Id: I13e30aedc360474dc818fecc528ce87c3bfeed42
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465834
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70597}
      7f58ced7
  2. 30 Sep, 2020 2 commits
    • Jakob Gruber's avatar
      Rename legacy code kinds · 29bcdaad
      Jakob Gruber authored
      CodeKind::OPTIMIZED_CODE -> TURBOFAN
      
      Kinds are now more fine-grained and distinguish between TF, TP, NCI.
      
      CodeKind::STUB -> DEOPT_ENTRIES_OR_FOR_TESTING
      
      Code stubs (like builtins, but generated at runtime) were removed from
      the codebase years ago, this is the last remnant. This kind is used
      only for deopt entries (which should be converted into builtins) and
      for tests.
      
      Change-Id: I67beb15377cb60f395e9b051b25f3e5764982e93
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440335
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70234}
      29bcdaad
    • Jakob Gruber's avatar
      [turboprop] Add TURBOPROP code kind · 75b8c238
      Jakob Gruber authored
      Turboprop-generated Code objects will now have the dedicated
      TURBOPROP code kind instead of OPTIMIZED_FUNCTION. When possible,
      the code kind is used as the source of truth instead of
      FLAG_turboprop. This is the initial step towards implementing
      tier-up from Turboprop to Turbofan.
      
      Future work: Rename OPTIMIZED_FUNCTION to TURBOFAN, rename STUB to
      DEOPT_ENTRIES_OR_FOR_TESTING, implement TP tier-up.
      
      No-Try: true
      Bug: v8:9684
      Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng
      Change-Id: I3c9308718d7e9a2b7e6796e7ea94f17e5ff84c0a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424140
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70213}
      75b8c238
  3. 28 Sep, 2020 1 commit
  4. 12 Aug, 2020 1 commit
    • Santiago Aboy Solanes's avatar
      [compiler] Have one unique PersistentHandles container · 64828a54
      Santiago Aboy Solanes authored
      The (now unique)PersistentHandles container follows this path:
        1) PersistentHandles created via PersistentHandlesScope inside of
           CompilationHandleScope
        2) Owned by OptimizedCompilationInfo
        3) Owned by JSHeapBroker
        4) Owned by the broker's LocalHeap
        5) Back to the broker for a brief moment (after tearing down the
          LocalHeap as part of exiting LocalHeapScope)
        6) Back to OptimizedCompilationInfo when exiting the LocalHeapScope.
      
      There is a special case in GenerateCodeForTesting where the JSHeapBroker
      will not be retired in that same method. In this case, we need to
      re-attach the PersistentHandles container to the JSHeapBroker.
      
      The identity map of the persistent & canonical handles also gets passed
      around like the persistent handles. The only difference is that is
      created in the CanonicalHandleScope (i.e step 1) is different).
      
      Bug: v8:7790
      Change-Id: I2da77a7e08f3fd360a46b606c5fbda08c0af27df
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332811
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69360}
      64828a54
  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
  6. 31 Jul, 2020 1 commit
  7. 14 Jul, 2020 1 commit
  8. 13 Jul, 2020 1 commit
  9. 15 Jun, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Add native_context_independent flags · f30b53bd
      Jakob Gruber authored
      ... to OptimizedCompilationInfo, BytecodeGraphBuilder, and
      JSHeapBroker.
      
      Also add first uses of these flags in pipeline.cc by skipping certain
      phases when nci is enabled. With this change, tests in the NCI variant
      will start to fail since generic lowering is not fully implemented.
      These implementations will follow incrementally in the next days.
      
      Bug: v8:8888
      Change-Id: I3f570fb92f09059d1f1f4015f88ffe80ccf746ad
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2239572
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68339}
      f30b53bd
  10. 10 Jun, 2020 1 commit
  11. 11 May, 2020 1 commit
  12. 06 May, 2020 1 commit
  13. 05 Nov, 2019 1 commit
  14. 17 Sep, 2019 1 commit
  15. 04 Sep, 2019 1 commit
  16. 03 Sep, 2019 2 commits
  17. 08 Jul, 2019 1 commit
  18. 05 Jul, 2019 1 commit
  19. 27 Jun, 2019 1 commit
  20. 12 Jun, 2019 1 commit
  21. 11 Jun, 2019 1 commit
  22. 29 May, 2019 1 commit
  23. 23 May, 2019 2 commits
  24. 22 May, 2019 1 commit
  25. 21 May, 2019 1 commit
  26. 17 May, 2019 1 commit
  27. 16 May, 2019 2 commits
  28. 09 May, 2019 1 commit
  29. 08 May, 2019 1 commit
  30. 29 Apr, 2019 2 commits
    • Clemens Hammacher's avatar
      [cleanup] Use Vector::begin instead of Vector::start · 4b0f9c85
      Clemens Hammacher authored
      Our {Vector} template provides both {start} and {begin} methods. They
      return exactly the same value. Since the {begin} method is needed for
      iteration, and is also what standard containers provide, this CL
      switches all uses of the {start} method to use {begin} instead.
      
      Patchset 1 was auto-generated by using this clang AST matcher:
          callExpr(
              callee(
                cxxMethodDecl(
                  hasName("start"),
                  ofClass(hasName("v8::internal::Vector")))
              ),
              argumentCountIs(0))
      
      Patchset 2 was created by running clang-format. Patchset 3 then
      removes the now unused {Vector::start} method.
      
      R=jkummerow@chromium.org
      TBR=mstarzinger@chromium.org,yangguo@chromium.org,verwaest@chromium.org
      
      Bug: v8:9183
      Change-Id: Id9f01c92870872556e2bb3f6d5667463b0e3e5c6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587381Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61081}
      4b0f9c85
    • Sigurd Schneider's avatar
      [regalloc] Make turbo_preprocess_ranges the default · edffb7d3
      Sigurd Schneider authored
      This CL removes the flag '--turbo-preprocess-ranges' and enables it by
      default.
      
      If FLAG_turbo_control_flow_aware_allocation is set,
      --turbo-preprocess-ranges is disabled and control flow aware
      allocation is enabled instead.
      
      Bug: v8:9088
      Change-Id: I81d56f15efc8f765e317aa828d27f415f8b7fd40
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585725
      Auto-Submit: Sigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61070}
      edffb7d3
  31. 03 Apr, 2019 1 commit
  32. 25 Mar, 2019 1 commit
    • Benedikt Meurer's avatar
      [tracing] Improve tracing signals for compilation/optimization. · a2af7e11
      Benedikt Meurer authored
      This adds OBJECT/SNAPSHOT trace events for Script and SharedFunctionInfo
      objects, logging their creation with appropriate information to make
      sense of them.
      
      Based on that we introduces five flow events to model the optimized
      compilation via tracing in the "disabled-by-default-v8.compile" category:
      
        - "v8.optimizingCompile.start" logs the creation of the
          PipelineCompilationJob (for TurboFan JavaScript optimization)
          with the "function" argument referring to the trace event
          object created for the SharedFunctionInfo.
        - "v8.optimzingCompile.prepare" logs the preparation of the
          PipelineCompilationJob on the main thread, also carrying the
          "function" argument. This connects the flow event to the actual
          tracing duration event associated with the preparation phases.
        - "v8.optimizingCompile.execute" logs the (usually concurrent)
          optimization of the TurboFan graph (again with "function").
        - "v8.optimizingCompile.finalize" logs the main thread phase which
          finalizes the optimized code and eventually installs it (in case
          of success).
        - "v8.optimizingCompile.end" signals the end of the
          PipelineCompilationJob, which carries the "compilationInfo",
          that contains the interesting bits of the OptimizedCompilationInfo,
          specifically whether the compile was successfull and which functions
          were inlined for example.
      
      This also adds two instant events "V8.AbortOptimization" and
      "V8.RetryOptimization" in "disabled-by-default-v8.compile" category
      that are emitted when TurboFan cannot optimize a certain function.
      In case of "V8.RetryOptimization", TurboFan might be able to optimize
      it later, whereas "V8.AbortOptimization" permanently disables the
      optimization of a given function. The JSON representation of this is
      
      ```js
      {
        "pid": 256639,
        "tid": 256639,
        "ts": 6935411377801,
        "tts": 159116,
        "ph": "I",
        "cat": "disabled-by-default-v8.compile",
        "name": "V8.AbortOptimization",
        "dur": 0,
        "tdur": 0,
        "args": {
          "reason": "Function is too big to be optimized",
          "function": {
            "id_ref": "0x600000001",
            "scope": "v8::internal::SharedFunctionInfo"
          }
        }
      },
      ```
      
      where the "function" refers to a previously emitted SNAPSHOT for the
      function in question. In the trace viewer it will show up as instant
      event under "v8.optimizingCompile.prepare" in case of the relevant
      example where optimization is disabled due to reaching the bytecode
      limit (as in the JSON above), i.e. it'll look something like this
      
        https://i.paste.pics/aafc2de9df10ea8f5acc1a761d80f07b.png
      
      for the example highlighted in the recent blog post
      
        https://ponyfoo.com/articles/javascript-performance-pitfalls-v8
      
      that describes the optimization limit. The "v8.optimizingCompile.end"
      duration event will also carry this information as part of the
      "compilationInfo" object, but specifically for CI tools, etc. it might
      be a whole lot easier to just look for the "V8.AbortOptimization"
      instant event.
      
      Bug: v8:8598, v8:9039
      Tbr: ulan@chromium.org
      Doc: bit.ly/v8-tracing-signals
      Change-Id: Ic87ac336004690c65b6b15ad73bc6fbd4b5f12c4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1511483
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60448}
      a2af7e11
  33. 22 Mar, 2019 1 commit
    • Sigurd Schneider's avatar
      Reland "Reland "[regalloc] Introduce deferred fixed ranges"" · 85017f04
      Sigurd Schneider authored
      This is a reland of 1ca08865
      
      Original change's description:
      > Reland "[regalloc] Introduce deferred fixed ranges"
      > 
      > This is a reland of b1769313
      > 
      > Original change's description:
      > > [regalloc] Introduce deferred fixed ranges
      > > 
      > > Fixed ranges are used to express register constraints in the
      > > allocator. This change splits these fixed ranges into one for
      > > normal code and deferred code. The former are handeled as before
      > > whereas the latter are only made visible while allocating
      > > registers for deferred code.
      > > 
      > > This prevents forward looking decisions in normal code to be
      > > impacted by register constraints from deferred code.
      > > 
      > > Change-Id: I67d562bb41166194e62765d5ab051bc961054fc7
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1477742
      > > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#60322}
      > 
      > Change-Id: I1a31150256eb5608db985b144aab7ea457169d0d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530810
      > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#60364}
      
      Change-Id: If4a956716e7e4de132f706be2c395cdfdc04ec94
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532328Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60408}
      85017f04
  34. 13 Feb, 2019 1 commit
  35. 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