1. 19 Mar, 2021 1 commit
  2. 05 Mar, 2021 1 commit
  3. 04 Feb, 2021 1 commit
  4. 11 Jan, 2021 1 commit
    • Clemens Backes's avatar
      [wasm][memory64] Fix Liftoff on 32-bit and add cctest · e48b5c6d
      Clemens Backes authored
      This adds a first execution test for memory64 in the form of a cctest.
      Several things are still not working correctly, hence this test only
      checks TurboFan on 64-bit systems, and Liftoff.
      
      Bounds checks in Liftoff are fixed to work correctly on 32-bit.
      Follow-up CLs will extend the test to also test TurboFan on 32-bit, the
      interpreter, and traps. All of those features still have issues.
      
      R=manoskouk@chromium.org
      
      Bug: v8:10949
      Change-Id: Ic7edcf3783421634fe2ec99eac6f257c557a29b5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2610968Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72014}
      e48b5c6d
  5. 16 Dec, 2020 2 commits
  6. 05 Oct, 2020 2 commits
  7. 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
  8. 24 Jul, 2020 1 commit
  9. 23 Jun, 2020 1 commit
  10. 09 Jun, 2020 1 commit
  11. 05 Jun, 2020 2 commits
    • Clemens Backes's avatar
      [wasm][debug] Fully tier up on Debugger.disable · 7637ed59
      Clemens Backes authored
      When the last debugger is disabled, we tier up the module to TurboFan.
      Doing this in the background creates problems with profiling, where the
      debugger is disabled before starting to profile, in order to guarantee
      profiling of top-tier code.
      
      Hence this CL changes the logic such that we only return from the
      {TierUpAllModulesPerIsolate} methods once tier up is complete. Since
      the DevTools frontend disables all debuggers before starting a profile,
      this will ensure that all new calls execute TurboFan code.
      Because of this change, the {TriggerRecompilation} method is renamed to
      {RecompileForTiering}.
      
      The test cases stay unchanged (do a busy wait until tier up is done),
      because in the multi-isolates tests it is not guaranteed that tier up is
      complete after disabling a single debugger.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10580
      Change-Id: I75c4b97825f856f562cfa656c11293d3b964898b
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2232539
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68212}
      7637ed59
    • Clemens Backes's avatar
      [wasm][interpreter] Remove threads support · 47e501e1
      Clemens Backes authored
      The wasm interpreter was always single-threaded, and there are no plans
      to change this. Still, there was a concept of threads, but with the
      hard-coded constraint that there is always exactly one of them.
      
      In order to clean up the code, and as a preparation to remove more
      unneeded functionality before moving the interpreter over to the test
      directory, this CL removes the concept of threads and merges the
      {ThreadImpl} class into {WasmInterpreterInternals}.
      
      Drive-by: Remove the dead {GetFrameCount} method.
      
      R=ahaas@chromium.org
      
      Bug: v8:10389
      Change-Id: If65cdd21b34ce8debf8ba0f24dbeacec15e0a1d7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2231354Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68204}
      47e501e1
  12. 12 May, 2020 1 commit
    • Clemens Backes's avatar
      Reland "[wasm][debug] Fix tier down for multiple isolates" · e62a7f76
      Clemens Backes authored
      This is a reland of 902f48bd, fixed
      to avoid lock inversion problems detected by TSan.
      
      Original change's description:
      > [wasm][debug] Fix tier down for multiple isolates
      >
      > If multiple isolates are using the same module, we need to keep it
      > tiered down as long as any isolate still has a debugger open.
      > Also, we cannot short-cut the {NativeModule::TierDown} method, since the
      > previously triggered tier down might not have finished yet.
      > For now, each isolate starts an independent tier down (i.e. a full
      > recompilation). We could optimize this later by skipping functions that
      > are already tiered down, or are already scheduled for tier down, but we
      > still need to wait for tier-down to finish on each isolate.
      >
      > R=thibaudm@chromium.org
      >
      > Bug: v8:10359
      > Change-Id: I7ea6a6f5d3977e48718ac5bc94f9831541f6173f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2190758
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67716}
      
      Bug: v8:10359
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Change-Id: Ie98cf073fc79e5c6991df6d4466de7b560274070
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2194451
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67754}
      e62a7f76
  13. 11 May, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][debug] Make recompilation isolate-independent · 14984372
      Clemens Backes authored
      Passing an isolate to {RecompileNativeModule} feels wrong, since
      compilation and the generated code are totally isolate-independent. In
      fact, the isolate is only used for updating counters.
      Instead of passing the counters instead, this CL just refactors the code
      to support a nullptr for the counters everywhere (some code paths
      already supported that). The few recompilation would not make a
      significant difference in the histograms anyway, and even have the risk
      of skewing the data.
      
      Drive-by 1: Rename {TierUp} to {StartTierUp} and update comments.
      Drive-by 2: Remove non-actionable TODO.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10359
      Change-Id: Ic027f939bbc55398b90784922130fe1fe5573b0c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2187638Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67708}
      14984372
  14. 06 May, 2020 1 commit
  15. 24 Apr, 2020 1 commit
  16. 20 Apr, 2020 1 commit
  17. 16 Apr, 2020 1 commit
    • Ng Zhi An's avatar
      [wasm] Fix wasm decoder for multi-byte opcodes · b48b82e7
      Ng Zhi An authored
      SIMD opcodes consist of the prefix byte, then an LEB128 encoded int. We
      were decoding this incorrectly as a fixed uint8. This fixes the decoder
      to properly handle multi bytes.
      
      In some cases, the multi byte logic is applied to all prefixed opcodes.
      This is not a problem, since for values < 0x80, the LEB encoding is a
      single byte, and decodes to the same int. If the prefix opcode has
      instructions with index >= 0x80, it would be required to be LEB128
      encoded anyway.
      
      There are a bunch of trivial changes to test-run-wasm-simd, to change
      the macro from BUILD to BUILD_V, the former only works for single byte
      opcodes, the latter is a new template-based macro that correct handles
      multi-byte opcodes. The only unchanged test is the shuffle fuzzer test,
      which builds its own sequence of bytes without using the BUILD macro.
      
      Bug: v8:10258
      Change-Id: Ie7377e899a7eab97ecf28176fd908babc08d0f19
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2118476
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67186}
      b48b82e7
  18. 14 Apr, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][debug] Store "for debugging" flag on compilation unit · e0433f7d
      Clemens Backes authored
      Before the "debug" flag was stored on the {CompilationEnv}. But each
      background compilation task only gets the {CompilationEnv} once when
      starting compilation, so by the time it picks up the "Liftoff for
      debugging" compilation jobs, it might still compile them without the
      debug flag being set. This leads to flakes in the "debug-step-into-wasm"
      test, because we won't stop in the function prologue when stepping in
      (because the function prologue does not check the "hook on function
      call" flag if debug mode was not enabled).
      
      This CL does not increase the size of a compilation unit, since both the
      tier and the debug flag only need a single byte each.
      
      As a nice side effect, this change allows us to remove the lock in
      {CreateCompilationEnv}, because no modifyable flag is read any more.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10410
      Change-Id: Ic296ea0c4dd1d4dedde119f0536e87e5d301b5a1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144116Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67115}
      e0433f7d
  19. 27 Mar, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][debug] Stage --debug-in-liftoff behind --future · 0f4d68da
      Clemens Backes authored
      There are only three tests with differing behaviour if Liftoff is used
      for debugging.
      This CL thus stages the --debug-in-liftoff flag behind --future (tested
      by the "future" variant) and excludes the three tests.
      This allows us to test the other (already working) tests for
      regressions, and iteratively shrinking down the list of failing tests.
      
      Drive-by: Tier down modules in tests before testing debugging features
      to avoid hitting a DCHECK in Liftoff recompilation for debugging.
      
      R=thibaudm@chromium.org, ecmziegler@chromium.org
      
      Bug: v8:10351
      Change-Id: I3b1dd1a29258ecf13c1f60020fb06358005558d4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122021Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66889}
      0f4d68da
  20. 23 Mar, 2020 1 commit
  21. 20 Mar, 2020 1 commit
    • Ng Zhi An's avatar
      [wasm-simd] New macro to build using vector of bytes · 1e40c682
      Ng Zhi An authored
      Introduces a new macro BUILD_V (v is for vector) that pushes bytes into
      a vector (instead of directly in an array initializer, see BUILD). This
      has the positive effect of being able to handle opcodes of multiple
      bytes (e.g. SIMD opcodes bigger that 0xfd80). Because of this "API"
      change, our helper macros in test-run-wasm-simd.cc and wasm-run-utils.h
      need to change too. So, we introduce new macros (suffixed by _V), that
      will call the appropriate lambdas defined in BUILD_V, that knows how to
      push bytes into the vector, and also can handle multi-byte opcodes.
      
      This design has a bit of duplication and ugliness, but was chosen to
      reduce the impact of existing tests. No restructuring of test code is
      required, we only need to add suffix _V.
      
      Note that we do not have multi-byte opcodes yet (in wasm-opcodes.h),
      this change will be breaking, and requires all the tests to be updated
      to use _V macros first.
      
      Bug: v8:10258
      Change-Id: I86638a548fe2f9714c1cfb3bd691fb7b49bfd652
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2107650
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66812}
      1e40c682
  22. 19 Mar, 2020 1 commit
  23. 12 Mar, 2020 1 commit
  24. 27 Feb, 2020 1 commit
  25. 24 Feb, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Extend debug side table for registers · 75931f18
      Clemens Backes authored
      This extends the debug side table to also store register locations in
      addition to constants and stack values.
      Previously, every value that was not constant was assumed to be spilled
      to the stack. This made sense, because without breakpoints we would only
      emit debug side table entries at call sites, where all registers are
      spilled.
      With breakpoints, this changes. At break locations, values might be live
      in registers.
      
      The logic to decide whether a value will live in the register or on the
      stack is extended, because we sometimes generate the debug side table
      entry at a point where the registers are not spilled yet. The debug side
      table entry creation needs to account for that, and assume that these
      registers will still be spilled.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10147, v8:10222
      Change-Id: I3b020dfaa29fc007047663706ee286180a996bfd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066960
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66407}
      75931f18
  26. 03 Feb, 2020 1 commit
    • Thibaud Michaud's avatar
      Reland "Reland "[wasm] Cache streaming compilation result"" · ab6c4669
      Thibaud Michaud authored
      This is a reland of 9781aa07
      
      Original change's description:
      > Reland "[wasm] Cache streaming compilation result"
      >
      > This is a reland of 015f379a
      >
      > Original change's description:
      > > [wasm] Cache streaming compilation result
      > >
      > > Before compiling the code section, check whether the
      > > bytes received so far match a cached module. If they do, delay
      > > compilation until we receive the full bytes, since we are likely to find
      > > a cache entry for them.
      > >
      > > R=clemensb@chromium.org
      > >
      > > Bug: v8:6847
      > > Change-Id: Ie5170d1274da3da6d52ff1b408abc7cb441bbe3c
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002823
      > > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#66000}
      >
      > Bug: v8:6847
      > Change-Id: I0b5acffa01aeb7dade3dc966392814383d900015
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2022951
      > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66047}
      
      Bug: v8:6847
      Change-Id: I272f56eee28010f34cc99df475164581c8b63036
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
      Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030741
      Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66081}
      ab6c4669
  27. 30 Jan, 2020 2 commits
  28. 27 Jan, 2020 2 commits
  29. 24 Jan, 2020 2 commits
  30. 23 Jan, 2020 2 commits
  31. 14 Jan, 2020 1 commit
    • Ng Zhi An's avatar
      [wasm-simd][liftoff] Support SIMD locals · ba14c2f3
      Ng Zhi An authored
      Add kWasmS128 to the list of supported types, and implement Fill for all
      the architectures so that LocalGet works.
      
      Add a new test file to contain tests that run only on Liftoff, and
      assert that the code is indeed compiled by Liftoff.
      We cannot rely on the nooptimization variant for testing
      because by default, if Liftoff compilation fails, it will fall back to
      Turbofan, and we accidentally get a test passing.
      
      We skip these tests on mips architecture that don't support SIMD, since
      there is no way to implement these, and we don't have a "lowering" phase
      for Liftoff.
      
      As we implement more of SIMD in Liftoff, we can add more
      tests to this file and ensure correctness. Future patches will introduce
      support for globals and params.
      
      Bug: v8:9909
      Change-Id: I7fc911f2d588d60c709ddb258b2efc1f22805fab
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1999470
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65768}
      ba14c2f3
  32. 03 Dec, 2019 1 commit
  33. 19 Jul, 2019 1 commit