1. 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
  2. 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
  3. 06 May, 2020 1 commit
  4. 24 Apr, 2020 1 commit
  5. 20 Apr, 2020 1 commit
  6. 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
  7. 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
  8. 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
  9. 23 Mar, 2020 1 commit
  10. 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
  11. 19 Mar, 2020 1 commit
  12. 12 Mar, 2020 1 commit
  13. 27 Feb, 2020 1 commit
  14. 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
  15. 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
  16. 30 Jan, 2020 2 commits
  17. 27 Jan, 2020 2 commits
  18. 24 Jan, 2020 2 commits
  19. 23 Jan, 2020 2 commits
  20. 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
  21. 03 Dec, 2019 1 commit
  22. 19 Jul, 2019 1 commit
  23. 21 Jun, 2019 1 commit
  24. 23 May, 2019 1 commit
  25. 22 May, 2019 1 commit
    • Andreas Haas's avatar
      [wasm][anyref] Cache export wrappers per signature · d56ee2e3
      Andreas Haas authored
      Up until now, we cached export wrappers per export index. With the
      anyref proposal potentially many more functions will need export
      wrappers, e.g. any function that is stored in a table, and any
      function accessed by the new ref.func instruction.
      
      With this CL, we change the caching scheme an do the caching per
      signature. Thereby we can guarantee that any export wrapper which
      potentially exists can be stored in the cache.
      
      For cctests which use wasm-run-utils, we don't know the size of the
      cache anymore ahead of time. However, we assume that no more than
      5 signatures will be used in any cctest. If this assumption is not
      true, we can just adjust the number.
      
      The cache is now accessed in all code paths where we need an export
      wrapper.
      
      Bug: chromium:962850
      
      Change-Id: I32df60dfa7801d1e71f7d837da091f388198af1f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1615247
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61752}
      d56ee2e3
  26. 21 May, 2019 1 commit
  27. 07 May, 2019 1 commit
  28. 11 Apr, 2019 1 commit
  29. 05 Apr, 2019 1 commit
    • Ben Smith's avatar
      Reland "[wasm] Implement table.init for interpreter" · 9010424f
      Ben Smith authored
      This is a reland of 63608968
      
      The previous CL failed on Windows, but it was a general bug. The
      dropped_elem_segments was not being set on the instance properly in
      cctests, so`table.init` instructions would fail by reading uninitialized
      data.
      
      I took this opportunity to also add an implementation of
      `elem.drop` in the interpreter, and ported the JS tests for those too.
      
      Original change's description:
      > [wasm] Implement table.init for interpreter
      >
      > This also fixes CheckCallViaJS when a trap occurs. In that case, the
      > trap callback is called instead of an exception being thrown, so if it
      > isn't handled, a bogus result will be returned instead.
      >
      > Bug: v8:8965
      > Change-Id: I560e89f353756df23c062fb8c9484d9971c19253
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1539078
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Ben Smith <binji@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#60473}
      
      Bug: v8:8965
      Change-Id: Ia547d9530b7ca67fde5bd94539f49153b796e82d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1547142
      Commit-Queue: Ben Smith <binji@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60664}
      9010424f
  30. 03 Apr, 2019 1 commit
  31. 02 Apr, 2019 1 commit
  32. 27 Mar, 2019 1 commit
  33. 26 Mar, 2019 2 commits
  34. 21 Mar, 2019 2 commits
    • Ben Smith's avatar
      [wasm] Implement bulk memory table.copy in interpreter · 8a7f562e
      Ben Smith authored
      Most of the mjsunit/wasm/table-copy.js tests have been ported to
      cctests, so they can be tested with all execution tiers.
      
      Bug: v8:8965
      Change-Id: I448719be30a4b2bddb9e2cffb4c74d3134db2f50
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1529548
      Commit-Queue: Ben Smith <binji@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60396}
      8a7f562e
    • Ben Smith's avatar
      [wasm] Call through dispatch table in interpreter · 1a88414c
      Ben Smith authored
      When running wasm tests, the interpreter previously used a static
      collection of function indexes stored in WasmTable to perform
      call_indirect calls internal to that module. This has the wrong behavior
      if the table is changed (via WasmTableObject::Set, `table.copy`, or
      `table.init`).
      
      This CL changes the cctests to always generate an intepreter entry for
      all functions, and stores those entries in the dispatch table. This
      allows us to use the same execution path as for non-testing code.
      
      The interpreter entry compiler needed to be changed to support
      multi-value returns too, since a 64-bit integer return value may be
      lowered to two 32-bit integer returns.
      
      Bug: v8:9016
      Change-Id: I277df21ffde5c2eee0b691fcc9bab2b1a43eeffc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1531137
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60380}
      1a88414c