1. 31 Jan, 2019 2 commits
  2. 30 Jan, 2019 2 commits
  3. 29 Jan, 2019 2 commits
  4. 28 Jan, 2019 1 commit
  5. 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
  6. 22 Jan, 2019 2 commits
  7. 21 Jan, 2019 4 commits
    • Michael Starzinger's avatar
      [wasm] Simplify safepoint-table encoding. · 6091e270
      Michael Starzinger authored
      This removes the unused "argument count" field from the safepoint table
      as the field was unused by now and always contained the value zero.
      
      Also note that associating a callee's argument count with the call-site
      is not compatible with tail-call support. When tail-calling a function
      with a different number of arguments, the information associated with
      the call-site becomes stale. The number of arguments is a property of
      the callee, not of the call-site in the caller. For this reason the
      field in question is not usable to support reference types in function
      arguments (at least when tail-calls are also supported).
      
      R=ahaas@chromium.org
      
      Change-Id: If667d729267f2dd2642b755c54235cc08ca9b141
      Reviewed-on: https://chromium-review.googlesource.com/c/1402548Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58969}
      6091e270
    • Clemens Hammacher's avatar
      [Liftoff][arm] Avoid use of temp registers · ce2bfb8e
      Clemens Hammacher authored
      The temp registers might be needed by the assembler, so avoid using them
      in LiftoffAssembler. Use Liftoff cache registers instead. This might
      introduce additional spills if all registers are in use, but this is
      unlikely.
      
      This also simplifies the logic to ensure non-aliasing of certain
      registers.
      
      R=ahaas@chromium.org
      
      Bug: chromium:922933, v8:6600
      Change-Id: Ie929d9de0b6f4f41c6117d820b6a367dd0a342f7
      Reviewed-on: https://chromium-review.googlesource.com/c/1424862Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58961}
      ce2bfb8e
    • 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
    • Clemens Hammacher's avatar
      [Liftoff] Fix DCHECK error · f77299e1
      Clemens Hammacher authored
      Fix fixes a minor DCHECK error, which fired because usually only
      LiftoffRegisters of the same type should be compared against each
      other. In the RegisterReuseMap we store both register pairs and single
      registers, hence check for pair vs non-pair comparisons explicitly.
      
      R=ahaas@chromium.org
      
      Bug: v8:6600, chromium:922670
      Change-Id: I18beb61b6b1906cc42bcf6e7dfdd5eb803e874d7
      Reviewed-on: https://chromium-review.googlesource.com/c/1421921Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58956}
      f77299e1
  8. 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
  9. 17 Jan, 2019 2 commits
  10. 16 Jan, 2019 1 commit
    • Clemens Hammacher's avatar
      [assembler] Allow to pass custom buffer implementations · 1a3aab51
      Clemens Hammacher authored
      When generating an Assembler, you currently have two choices: Either
      let the Assembler allocate a growable internal buffer, which is owned
      by the Assembler. Or provide an externally allocated buffer, which
      cannot grow.
      This CL changes this interface to allow providing any implementation of
      a buffer. The provided buffer can be a view to an externally owned
      buffer, which still can grow.
      This will be used to split WebAssembly compilation and code submission.
      The buffer needs to be able to grow, but cannot be owned by the
      Assembler because it has to survive until the code is submitted.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:8689
      Change-Id: Ib6c5ebffc8b71d0778944abac34f02c5cc7dbd79
      Reviewed-on: https://chromium-review.googlesource.com/c/1411347
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58848}
      1a3aab51
  11. 15 Jan, 2019 1 commit
  12. 14 Jan, 2019 2 commits
  13. 11 Jan, 2019 2 commits
  14. 10 Jan, 2019 1 commit
  15. 09 Jan, 2019 2 commits
  16. 08 Jan, 2019 2 commits
  17. 07 Jan, 2019 3 commits
    • Clemens Hammacher's avatar
      [Liftoff] Avoid quadratic behaviour in stack transfers · 23a85a33
      Clemens Hammacher authored
      We currently iterate the list of unexecuted register moves repeatedly,
      always executing the moves whose destination register is not being used
      as source register any more. This can lead to quadratic execution times
      if only a small number of moves is processed in every iteration.
      
      This CL refactors this such that we iterate the moves at most three
      times: Once for executing moves which can be executed right away (fast
      path) and for computing the source register use counts. A second time
      to execute all remaining non-cyclic moves, and a third time to execute
      cyclic moves.
      During the second and third iteration, whenever we decrement the source
      register use count, we check whether it drops to zero and execute the
      respective move right away.
      
      R=ahaas@chromium.org
      
      Bug: v8:6600, v8:8423
      Change-Id: I503328f5ae5f0208e35d53c71b4c289d75799892
      Reviewed-on: https://chromium-review.googlesource.com/c/1397703
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58588}
      23a85a33
    • Clemens Hammacher's avatar
      [Liftoff] Change the way we store stack transfers · 96671ab2
      Clemens Hammacher authored
      Stack transfers consist of a number of register moves plus a number of
      register loads. We currently store both in separate vectors. This CL
      changes that to be stored in arrays indexed by the destination register
      (such that it behaves like a map). This avoids any dynamically growing
      structures.
      
      Measured locally, this speeds up stack transfer processing by ~10%,
      which translates to ~0.5% of overall Liftoff compilation time.
      
      R=ahaas@chromium.org
      
      Bug: v8:6600, v8:8423
      Change-Id: Id532960dcc12f228507ed75e392ad4c57710593f
      Reviewed-on: https://chromium-review.googlesource.com/c/1396278
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58587}
      96671ab2
    • Clemens Hammacher's avatar
      [Liftoff] Restructure execution of stack transfers · b962c071
      Clemens Hammacher authored
      This is a fully semantically preserving CL, it just moves code around a
      bit to make the follow-up CL easier to review.
      
      R=ahaas@chromium.org
      
      Bug: v8:6600, v8:8423
      Change-Id: I0de80b18faa3ae570894cbd8073c495a5731d255
      Reviewed-on: https://chromium-review.googlesource.com/c/1396096Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58569}
      b962c071
  18. 04 Jan, 2019 2 commits
  19. 03 Jan, 2019 5 commits
    • Clemens Hammacher's avatar
      [Liftoff] Use int for liftoff register codes · 0f867644
      Clemens Hammacher authored
      The number of registers is very small, so any integer type is big
      enough anyway. Just use the simplest one, which is int.
      
      R=ahaas@chromium.org
      
      Bug: v8:6600
      Change-Id: I9762a5c934848b810b7937ee603cd183f883d557
      Reviewed-on: https://chromium-review.googlesource.com/c/1394548Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58524}
      0f867644
    • Clemens Hammacher's avatar
      [Liftoff] Keep consistent register mapping in non-merged regions · 20b63300
      Clemens Hammacher authored
      We currently de-duplicate used registers also in regions which do not
      need merging. In those regions though it can never happen that we need
      to pass different values from any merge input. Apart from introducing
      unnecessary register moves, this also causes a DCHECK to fail, because
      we might later want to merge back different registers into one.
      
      Assume this initial stack state (where each letter is a register):
      [A B B C]
      If in any child block the two Bs get de-duplicated so something like
      [A B D C]
      then we run into trouble when merging back this state into the parent
      state, because both B and D would need to be put into B.
      In this case we can statically infer that B and D must hold the same
      value anyway, but having this situation does not make much sense in the
      first place, so the DCHECK fires correctly.
      
      R=titzer@chromium.org
      
      Bug: v8:8423, chromium:917412
      Change-Id: I24c36b062e04a134cf7051725afab98126753f31
      Reviewed-on: https://chromium-review.googlesource.com/c/1392190
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58522}
      20b63300
    • Clemens Hammacher's avatar
      [Liftoff] Fix moving stack values · 14faced4
      Clemens Hammacher authored
      On x64 the {kScratchRegister} cannot be held in a {LiftoffRegister},
      since it is not a valid cache register. Also, the code unnecessarily
      checked whether there is an unused cache register, but then didn't use
      it. Simplify the logic to always use the scratch register, just
      distinguish between 4-byte and 8-byte moves.
      On ia32 we did not move 64-bit values correctly if we didn't have
      unused registers and needed to move via the stack.
      
      R=titzer@chromium.org
      
      Bug: v8:6600, chromium:917588, chromium:917450
      Change-Id: I0bbe946c6ac8fca62f85711ae47afdac9c02ae6b
      Reviewed-on: https://chromium-review.googlesource.com/c/1391755Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58521}
      14faced4
    • Clemens Hammacher's avatar
      [Liftoff] Remove all computation of "half indexes" · 5ea59597
      Clemens Hammacher authored
      Instead, always pass an index and an enum pointing to either half.
      
      R=titzer@chromium.org
      
      Bug: v8:6600, v8:8562
      Change-Id: I7e73bd97bfc7ebf644b242980aa0a73cd5f18949
      Reviewed-on: https://chromium-review.googlesource.com/c/1392189
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58516}
      5ea59597
    • Clemens Hammacher's avatar
      [Liftoff][mips] Clean up "half stack slot" accesses · 84bda68f
      Clemens Hammacher authored
      Bring mips in line with the ia32 and arm implementions. Instead of
      computing the "half index" manually, pass the index and an enum
      pointing to either half.
      
      R=titzer@chromium.org
      
      Bug: v8:6600
      Change-Id: Id8812114df84fbddd4aa2570306526d291bface6
      Reviewed-on: https://chromium-review.googlesource.com/c/1392188
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58514}
      84bda68f
  20. 02 Jan, 2019 1 commit