1. 08 May, 2019 1 commit
  2. 07 May, 2019 1 commit
  3. 06 May, 2019 1 commit
  4. 02 May, 2019 1 commit
  5. 30 Apr, 2019 1 commit
    • Mike Stanton's avatar
      Reland "[ptr-compr] New RelocInfo for compressed pointers." · ed319e84
      Mike Stanton authored
      Failure addressed by not exposing the new test to the jitless environment.
      (jgruber@ on TBR).
      
      New enum RelocInfo::COMPRESSED_EMBEDDED_OBJECT created to support
      compressed pointers in generated code. Enum name EMBEDDED_OBJECT
      changed to FULL_EMBEDDED_OBJECT.
      
      RelocInfo::[set_]target_object() abstract away the difference between
      FULL_EMBEDDED_OBJECT and COMPRESSED_EMBEDDED_OBJECT.
      
      Compressed embedded objects can only be created at this time on
      x64 with pointer compression turned on. Arm64 constant pools don't
      support compressed objects at this time.
      
      NOPRESUBMIT=true
      
      Bug: v8:7703
      TBR: jgruber@chromium.org
      Change-Id: Ifff53b041bab09b4b8c3e16085e5df4aa2b99f4f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588461Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61104}
      ed319e84
  6. 29 Apr, 2019 5 commits
  7. 26 Apr, 2019 1 commit
    • Ross McIlroy's avatar
      Revert "[csa] verify skipped write-barriers in MemoryOptimizer" · dd6c9536
      Ross McIlroy authored
      This reverts commit da7322c0.
      
      Reason for revert: Breaking the pointer compression bots, e.g.:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20pointer%20compression/3047
      
      Original change's description:
      > [csa] verify skipped write-barriers in MemoryOptimizer
      > 
      > With very few exceptions, this verifies all skipped write-barriers in
      > CSA and Torque, showing that the MemoryOptimizer together with some
      > type information on the stored value are enough to avoid unsafe skipped
      > write-barriers.
      > 
      > Changes to CSA:
      > SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
      > MemoryOptimizer by default.
      > Type information about the stored values (TNode<Smi>) is exploited to
      > safely skip write barriers for stored Smi values.
      > In some cases, the code is re-structured to make it easier to consume
      > for the MemoryOptimizer (manual branch and load elimination).
      > 
      > Changes to the MemoryOptimizer:
      > Improve the MemoryOptimizer to remove write barriers:
      > - When the store happens to a CSA-generated InnerAllocate, by ignoring
      >   Bitcasts and additions.
      > - When the stored value is the HeapConstant of an immortal immovable root.
      > - When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
      > - Fast C-calls are treated as non-allocating.
      > - Runtime calls can be white-listed as non-allocating.
      > 
      > Remaining missing cases:
      > - C++-style iterator loops with inner pointers.
      > - Inner allocates that are reloaded from a field where they were just stored
      >   (for example an elements backing store). Load elimination would fix that.
      > - Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
      >   We could handle that in Torque.
      > - Double-aligned allocations, which are not lowered in the MemoryOptimizer
      >   but in CSA.
      > 
      > Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
      > can be handled by overload resolution (in Torque and C++).
      > 
      > R=​jarin@chromium.org
      > TBR=mvstanton@chromium.org
      > 
      > Change-Id: I0af9b710673f350e0fe81c2e59f37da93c024b7c
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571414
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61016}
      
      TBR=mvstanton@chromium.org,jarin@chromium.org,tebbi@chromium.org
      
      Change-Id: I36877cd6d08761726ef8dce8a3e3f2ce3eebe6cf
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585732Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61038}
      dd6c9536
  8. 25 Apr, 2019 1 commit
    • Tobias Tebbi's avatar
      [csa] verify skipped write-barriers in MemoryOptimizer · da7322c0
      Tobias Tebbi authored
      With very few exceptions, this verifies all skipped write-barriers in
      CSA and Torque, showing that the MemoryOptimizer together with some
      type information on the stored value are enough to avoid unsafe skipped
      write-barriers.
      
      Changes to CSA:
      SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
      MemoryOptimizer by default.
      Type information about the stored values (TNode<Smi>) is exploited to
      safely skip write barriers for stored Smi values.
      In some cases, the code is re-structured to make it easier to consume
      for the MemoryOptimizer (manual branch and load elimination).
      
      Changes to the MemoryOptimizer:
      Improve the MemoryOptimizer to remove write barriers:
      - When the store happens to a CSA-generated InnerAllocate, by ignoring
        Bitcasts and additions.
      - When the stored value is the HeapConstant of an immortal immovable root.
      - When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
      - Fast C-calls are treated as non-allocating.
      - Runtime calls can be white-listed as non-allocating.
      
      Remaining missing cases:
      - C++-style iterator loops with inner pointers.
      - Inner allocates that are reloaded from a field where they were just stored
        (for example an elements backing store). Load elimination would fix that.
      - Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
        We could handle that in Torque.
      - Double-aligned allocations, which are not lowered in the MemoryOptimizer
        but in CSA.
      
      Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
      can be handled by overload resolution (in Torque and C++).
      
      R=jarin@chromium.org
      TBR=mvstanton@chromium.org
      
      Change-Id: I0af9b710673f350e0fe81c2e59f37da93c024b7c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571414
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61016}
      da7322c0
  9. 12 Apr, 2019 1 commit
  10. 03 Apr, 2019 2 commits
  11. 01 Apr, 2019 1 commit
  12. 26 Mar, 2019 2 commits
  13. 25 Mar, 2019 4 commits
    • 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
    • Benedikt Meurer's avatar
      [turbofan] Remove duplicated optimization limit. · 077e49a1
      Benedikt Meurer authored
      Before this change we had essentially two optimization limits, one hard
      limit in the TurboFan pipeline (128KiB), and a soft limit in the runtime
      profiler (60KiB). The hard limit was only relevant to --always-opt and
      other internal test infrastructure, and the soft limit was always
      enforced on regular JavaScript, but didn't properly disable further
      optimization for the function (so for example --trace-opt would
      continuesly report attempts to optimize the function).
      
      Now with this change we only have the hard limit, set to 60KiB, in the
      TurboFan pipeline and use that consistently.
      
      Bug: v8:8598
      Change-Id: I9e2ae7cb67de4a2256d3a7b9c3aee3dab60c2ec1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1538127
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60436}
      077e49a1
    • Benedikt Meurer's avatar
      [tracing] Log precise TurboFan/Wasm phase information via Tracing. · 27258eb8
      Benedikt Meurer authored
      This extends the existing PipelineStatistics in the TurboFan pipeline
      (also used for Wasm) to emit trace events for the various phases of the
      (optimized) compilation. This works for "disabled-by-default-v8.compile"
      and "disabled-by-default-v8.wasm" categories.
      
      We also rename the existing phase names to match the naming convention
      for the V8 trace events (starting with either "V8.TF" or "V8.Wasm") to
      make it easy to spot and categorize them in the trace viewer.
      
      This can be seen in action here
      
        https://i.paste.pics/a33c0e3942ff707af44f67ed4bac46b0.png
      
      taken from a run of Octane/TypeScript.
      
      Bug: v8:8598
      Change-Id: Id40092ee8afc8d998532f8641780052769cad320
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1538121Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60433}
      27258eb8
    • Mathias Bynens's avatar
      [compiler] Fix “TurboFan” casing in logged output · f927e319
      Mathias Bynens authored
      Bug: v8:8834
      Change-Id: Ie879ae77f0601682dcd17a61f3a18f49eb78fbee
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1535833
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60423}
      f927e319
  14. 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
  15. 21 Mar, 2019 1 commit
    • Sigurd Schneider's avatar
      Revert "Reland "[regalloc] Introduce deferred fixed ranges"" · 21a471f2
      Sigurd Schneider authored
      This reverts commit 1ca08865.
      
      Reason for revert: Regressions across the board
      
      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}
      
      TBR=jarin@chromium.org,sigurds@chromium.org,herhut@chromium.org
      
      Change-Id: Id8ad6c39774e38dd67decea997e08a4c58c452ec
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532327Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60381}
      21a471f2
  16. 20 Mar, 2019 1 commit
    • Sigurd Schneider's avatar
      Reland "[regalloc] Introduce deferred fixed ranges" · 1ca08865
      Sigurd Schneider authored
      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: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60364}
      1ca08865
  17. 19 Mar, 2019 2 commits
  18. 12 Mar, 2019 1 commit
  19. 27 Feb, 2019 1 commit
  20. 25 Feb, 2019 1 commit
  21. 21 Feb, 2019 1 commit
    • Stephan Herhut's avatar
      [regalloc] Add two spill modes. · 9b1ab6f8
      Stephan Herhut authored
      This change adds two spilling modes: SpillAtDefinition and SpillDeferred.
      The former is the known spilling mode where we spill at definition. The
      latter spills only in deferred code regions. This is implemented based on
      control flow aware allocation and its invariants.
      
      The effect is mostly the same as splintering with the exception of
      forward looking allocation decisions still being impacted by register
      constraints in deferred code.
      
      Change-Id: Ia708e5765dd095196a8127deb2d8bec950d37e04
      Reviewed-on: https://chromium-review.googlesource.com/c/1437118Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Stephan Herhut <herhut@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59759}
      9b1ab6f8
  22. 19 Feb, 2019 1 commit
  23. 04 Feb, 2019 1 commit
  24. 01 Feb, 2019 1 commit
  25. 30 Jan, 2019 2 commits
    • Jakob Gruber's avatar
      Explicitly store the code layout in CodeDesc · ad3546ab
      Jakob Gruber authored
      This is an initial step towards clarifying the layout of the
      instruction area. As follow-ups, we should remove additional
      safepoint and handler table offset parameters, and perhaps alter
      Code::safepoint_table_offset (handler_table) semantics to always
      contain a real offset and avoid the magic 0 signifying nonexistent
      tables.
      
      Bug: v8:8758
      Change-Id: I9f54629ff3ddad69904b0e1ce2a58e047397aa15
      Reviewed-on: https://chromium-review.googlesource.com/c/1434036
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59202}
      ad3546ab
    • Stephan Herhut's avatar
      [regalloc] Land control flow aware allocation · 66771f42
      Stephan Herhut authored
      This change lands a change to the register allocator. Other than
      classical linear scan, we now take control flow events into account
      when deciding spill descisions.
      
      The basic idea is to restore the state of a predecessor on entry
      of a successor. In the case of multiple predecessors, we use
      heuristics to compute the new state based on the predecessors.
      
      The main addition to the machinery is to support unspilling
      live ranges and to undo live range splitting in certain cases.
      
      Currently, disabled behind a flag.
      
      Change-Id: I37a70c948be826a90d8b806a52856ad81f475573
      Reviewed-on: https://chromium-review.googlesource.com/c/1426129
      Commit-Queue: Stephan Herhut <herhut@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59195}
      66771f42
  26. 29 Jan, 2019 3 commits
  27. 25 Jan, 2019 1 commit
    • Andreas Haas's avatar
      [wasm][anyref] Support anyref stack parameters · 258371bd
      Andreas Haas authored
      Anyref parameters can exist across GC runs. Therefore the GC has to
      know where anyref parameters are on the stack so that it can mark them
      in its marking phase, and update them in the compaction phase.
      
      Already in a previous CL we grouped all anyref parameters so that they
      can be found more easily in a stack frame, see
      https://crrev.com/c/1371827. In this CL we implement the stack scanning
      itself.
      
      Note that anyref parameters are not scanned while iterating over the
      caller's frame (to which they actually belong), but while iterating
      over the callee's frame. The reason is that with tail-calls, only the
      callee knows how many tagged stack parameters (aka anyref parameters)
      there are.
      
      R=mstarzinger@chromium.org
      also-by=mstarzinger@chromium.org
      
      Bug: v8:7581
      Change-Id: I7a41ce11d06c0d420146fdb0bb8d5606f28824d7
      Reviewed-on: https://chromium-review.googlesource.com/c/1424955
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59099}
      258371bd