1. 30 Jun, 2021 1 commit
  2. 17 Dec, 2020 1 commit
  3. 06 Aug, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Remove ExecutionTier::kInterpreter · 0c918bd8
      Clemens Backes authored
      The interpreter is not an execution tier in production any more. It's
      only used in tests.
      Thus, remove {ExecutionTier::kInterpreter} and instead add a
      {TestExecutionTier} that still has {kInterpreter}.
      
      If needed (in {TestingModuleBuilder::execution_tier()}), we translate
      back from {TestExecutionTier} to {ExecutionTier} (for {kLiftoff} and
      {kTurboFan} only).
      
      The {TraceMemoryOperation} method, which is shared between interpreter
      and production code, now receives a {base::Optional<ExecutionTier>}, and
      we will just pass en empty optional if called from the interpreter.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10389
      Change-Id: Ibe133b91e8dca6d6edbfaee5ffa0d7fe72ed6d64
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335186Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69260}
      0c918bd8
  4. 06 May, 2020 1 commit
    • Andreas Haas's avatar
      [wasm][liftoff][arm] Implement CompareExchange · 90fa771d
      Andreas Haas authored
      This CL implements all variants of CompareExchange on arm.
      
      Implementing 64-bit CompareExchange on arm requires a lot of registers,
      with the additional constraint that the low-word register of new_value
      and result have to have an even register code, and that the corresponding
      high-word registers have a register code that is by one higher than the
      register code of the low-word register.
      
      This register allocation is achieved by assigning fixed registers to
      all values.
      
      R=clemensb@chromium.org, v8-arm-ports@googlegroups.com
      
      Bug: v8:10108
      Change-Id: I2edfde15e80db0d45621a461793018d88e997431
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172791
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67592}
      90fa771d
  5. 05 May, 2020 1 commit
  6. 12 Mar, 2020 1 commit
  7. 04 Feb, 2020 1 commit
  8. 23 Jan, 2020 1 commit
    • Andreas Haas's avatar
      [turbofan] Don't assume that Word32AtomicPairBinops has a projection-0 · e15f5ba1
      Andreas Haas authored
      The instruction selector assumed for Word32AtomicPairBinop nodes that if
      there exists a Projection(1) user, then there also exists a
      Projection(0) user. This, however, is not the case, because TurboFan
      eliminates unreachable nodes. The missing projection node lead to a
      failed DCHECK in the register allocator.
      
      With this CL we allocate the right registers for the existing
      projections, and allocate the other needed registers as temp registers.
      
      R=gdeepti@chromium.org
      
      Bug: v8:10140
      Change-Id: I22331cae58f933e89dac6993fe3b21ff6502838a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2011829Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65941}
      e15f5ba1
  9. 22 Jan, 2020 1 commit
    • Andreas Haas's avatar
      [turbofan] Don't assume that Word32AtomicPairLoad has a projection-0 · e56a7edb
      Andreas Haas authored
      The instruction selector assumed for Word32AtomicPairLoad node that if
      there exists a Projection(1) user, then there also exists a
      Projection(0) user. This, however, is not the case, because TurboFan
      eliminates unreachable nodes. The missing projection node lead to a
      failed DCHECK in the register allocator.
      
      To fix the problem I use now the Word32AtomicPairLoad node directly to
      allocate the register. On ia32 I stop additionally to allocate unneeded
      temp registers.
      
      R=gdeepti@chromium.org
      CC=zhin@chromium.org
      
      Bug: chromium:1042379
      Change-Id: I79bd9f3f4672e147246a71c32b7c9b4dbd79b17f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002547
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65912}
      e56a7edb
  10. 31 Jul, 2019 1 commit
  11. 11 Apr, 2019 1 commit
  12. 01 Feb, 2019 1 commit
    • Clemens Hammacher's avatar
      [test] Modernize value helpers · f0d69fc9
      Clemens Hammacher authored
      This CL changes the usage pattern from
      FOR_XXX_VALUES(i) { Use(*i); }
      to
      FOR_XXX_VALUES(i) { Use(i); }
      which is way more intuitive.
      
      Note that the replacement in the uses was done via regular expression,
      so it's purely mechanical. In two locations I removed unneeded braces
      around the macro, because they confused clang-format.
      I plan to do more cleanups (remove redundant assignments within the
      FOR_XXX_VALUES body) in a follow-up CL.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:8562
      Change-Id: I4329bfcf34e5b077d19b50f4204ceb3b4340fe61
      Reviewed-on: https://chromium-review.googlesource.com/c/1449615
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59287}
      f0d69fc9
  13. 22 Jan, 2019 2 commits
  14. 18 Sep, 2018 1 commit
  15. 29 Aug, 2018 1 commit
    • Deepti Gandluri's avatar
      [compiler] Remove AtomicNarrow machine operators, macroize tests · 9a0f2546
      Deepti Gandluri authored
      The AtomicNarrow operations are currently used for wider 64-bit
      operations, that only operate on 32-bits of data or less
      (Ex:I64AtomicAdd8U). Removing these because this can be handled
      in int64-lowering by zeroing the higher order node.
      Explicitly zeroing these in code-gen is not
      required because -
      
       - The spec requires only the data exchange to be atomic, for narrow
         ops this uses only the low word.
       - The return values are not in memory, so are not visible to other
         workers/threads
      
      BUG:v8:6532
      
      Change-Id: I90a795ab6c21c70cb096f59a137de653c9c6a178
      Reviewed-on: https://chromium-review.googlesource.com/1194428Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarBen Smith <binji@chromium.org>
      Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55499}
      9a0f2546
  16. 21 Aug, 2018 1 commit
  17. 09 Aug, 2018 1 commit
  18. 02 Aug, 2018 1 commit
  19. 30 Jul, 2018 1 commit
  20. 10 Jul, 2018 3 commits
  21. 27 Apr, 2018 2 commits
  22. 16 Apr, 2018 1 commit
  23. 13 Apr, 2018 1 commit
  24. 09 Apr, 2018 1 commit
  25. 27 Mar, 2018 1 commit
  26. 07 Mar, 2018 1 commit
  27. 03 Mar, 2018 1 commit
  28. 02 Mar, 2018 1 commit