1. 07 Aug, 2020 2 commits
  2. 06 Aug, 2020 1 commit
    • Andreas Haas's avatar
      [wasm] Check size of tables dynamically · 47434265
      Andreas Haas authored
      We used to check the size of tables at compile time, and threw a
      CompilationError if a given size exceeded the implementation-defined
      limit. However, the spec defines that an error should only be thrown
      when the implementation-defined limit is reached, which is either at
      instantiation time of during runtime at a table.grow.
      
      With this CL the V8 implementation becomes spec compliant in this
      regard.
      
      R=jkummerow@chromium.org
      
      Bug: v8:10556
      Change-Id: I7d0e688b385a65e4060a569e5ab1dec68947ceea
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2326331
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69267}
      47434265
  3. 05 Aug, 2020 2 commits
    • Manos Koukoutos's avatar
      [wasm-gc] Allow reference types to function signatures · a61aaed9
      Manos Koukoutos authored
      Changes:
      - Remove restriction that function types cannot be used as ref types.
      - Introduce WasmModule::has_type().
      - Remove deferred signature checks in module-decoder. Instead, check if
        type indices are out of bounds in consume_value_type (was bugged
        before).
      - Remove obsolete GetCanonicalRttIndex.
      - Refine type of ref.func.
      - Statically check immediate type against table type for call_indirect.
      - Dynamic check for call_indirect should only happen when for funcref
        (currently the only function supertype).
      - Allocate a different map per function signature (with Map::Copy).
      - Introduce function type equivalence and (trivial) subtyping.
      - Add a few elementary tests.
      
      Bug: v8:7748
      Change-Id: If57d0bfd856c9eb3784191f3de423f53dfd26ef1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335190
      Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69250}
      a61aaed9
    • Clemens Backes's avatar
      [wasm] Switch compilation to Jobs API · 0c837e83
      Clemens Backes authored
      Use the new jobs API for WebAssembly compilation. This avoids having to
      schedule as many background tasks as there are worker threads. Instead
      the one job specifies the maximum concurrency, which changes dynamically
      as new compile jobs become available.
      This also avoids the artificial deadline we used to ensure that other
      tasks get some share of the CPU resources if needed.
      
      Even though this CL moves actual wasm function completely over to the
      Jobs API, other similar tasks (like wrapper compilation) are still using
      the Task API and need to be ported in a follow-up CL.
      Also, we are still using the same priority for baseline compilation and
      tier up. We should split this in a follow-up CL to have two jobs with
      different priorities. This will also allow us to only block on baseline
      compilation where we currently block on both.
      
      R=ahaas@chromium.org
      CC=gab@chromium.org
      
      Bug: chromium:1101340
      Change-Id: I5656697753346e5fdb15d578425cdb949ac6e364
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Cq-Include-Trybots: luci.chromium.try:linux-rel
      Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2280100
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69239}
      0c837e83
  4. 28 Jul, 2020 1 commit
  5. 24 Jul, 2020 1 commit
  6. 21 Jul, 2020 2 commits
  7. 15 Jul, 2020 1 commit
  8. 10 Jul, 2020 1 commit
  9. 09 Jul, 2020 3 commits
  10. 08 Jul, 2020 1 commit
  11. 29 Jun, 2020 2 commits
  12. 26 Jun, 2020 2 commits
    • Shu-yu Guo's avatar
      Revert "[wasm-gc] Implement rtt.sub" · 30456566
      Shu-yu Guo authored
      This reverts commit 04ce88ea.
      
      Reason for revert: TSAN failure: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/32135
      
      Original change's description:
      > [wasm-gc] Implement rtt.sub
      > 
      > RTTs are internally represented as Maps. To store supertype information,
      > this patch introduces a WasmTypeInfo object, which is installed on Wasm
      > objects' Maps and points at both the off-heap type information and the
      > parent RTT.
      > In this patch, rtt.sub always creates a fresh RTT. The canonicalization
      > that the proposal requires will be implemented later.
      > 
      > Bug: v8:7748
      > Change-Id: I8286dd11f520966155cd95c2bd844ec34fccd131
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2260566
      > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#68564}
      
      TBR=ulan@chromium.org,jkummerow@chromium.org,tebbi@chromium.org
      
      Change-Id: I311732e1ced4de7a58b87d4a9b6056e0d62aa986
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7748
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2270734Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68567}
      30456566
    • Jakob Kummerow's avatar
      [wasm-gc] Implement rtt.sub · 04ce88ea
      Jakob Kummerow authored
      RTTs are internally represented as Maps. To store supertype information,
      this patch introduces a WasmTypeInfo object, which is installed on Wasm
      objects' Maps and points at both the off-heap type information and the
      parent RTT.
      In this patch, rtt.sub always creates a fresh RTT. The canonicalization
      that the proposal requires will be implemented later.
      
      Bug: v8:7748
      Change-Id: I8286dd11f520966155cd95c2bd844ec34fccd131
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2260566
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68564}
      04ce88ea
  13. 25 Jun, 2020 1 commit
    • Andreas Haas's avatar
      Reland "[wasm] Re-exported globals preserve their identity" · 1e4282db
      Andreas Haas authored
      This is a reland of f7a1932e
      
      There was a wpt test in Chrome that expected the incorrect behavior.
      I disable the test in https://crrev.com/c/2264418 so that we can land
      the fix here.
      
      Original change's description:
      > [wasm] Re-exported globals preserve their identity
      >
      > V8 fails a recently added spec test that when an imported global get
      > re-exported, it should preserve its identity. This CL fixes the behavior
      > in V8.
      >
      > Drive-by change: fix the object printer of globals: a global which
      > stores a reference type only has a tagged buffer, a global which stores
      > a value type only has an untagged buffer.
      >
      > R=clemensb@chromium.org
      >
      > Bug: v8:10556
      > Change-Id: I949d147fe4395610cfec6cf60082e1faecb23036
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235702
      > Commit-Queue: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#68513}
      
      Bug: v8:10556
      Change-Id: I8e1b08fc9f72dde166cba167e6e320e714796769
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2264097Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68552}
      1e4282db
  14. 24 Jun, 2020 3 commits
  15. 18 Jun, 2020 1 commit
    • Manos Koukoutos's avatar
      [wasm-gc] Change ValueType representation to account for new types · 52f65296
      Manos Koukoutos authored
      Motivation:
      Changes to the typed function references and gc proposals solidified
      the notion of heap type, clarified nullable vs. non-nullable reference
      types, and introduced rtts, which contain an integer depth field in
      addition to a heap type. This required us to overhaul our ValueType
      representation, which results in extensive changes.
      
      To keep this CL "small", we do not try to implement the binary encoding
      as described in the proposals, but rather devise a simpler one of our
      own (see below). Also, we do not try to implement additional
      functionality for the new types.
      
      Changes:
      - Introduce HeapType. Move heap types from ValueType to HeapType.
      - Introduce Nullability for reference types.
      - Rework ValueType helper methods.
      - Introduce rtts in ValueType with an integer depth field. Include depth
        in the ValueType encoding.
      - Make the constructor of ValueType private, instead expose static
        functions which explicitly state what they create.
      - Change every switch statement on ValueType::Kind. Sometimes, we need
        nested switches.
      - Introduce temporary constants in ValueTypeCode for nullable types,
        use them for decoding.
      - In WasmGlobalObject, split 'flags' into 'raw_type' and 'is_mutable'.
      - Change IsSubtypeOfRef to IsSubtypeOfHeap and implement changes in
        subtyping.
      - kWasmFuncRef initializers are now non-nullable. Initializers are
        only required to be subtypes of the declared global type.
      - Change tests and fuzzers as needed.
      
      Bug: v8:7748
      Change-Id: If41f783bd4128443b07e94188cea7dd53ab0bfa5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247657
      Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68408}
      52f65296
  16. 16 Jun, 2020 1 commit
  17. 10 Jun, 2020 1 commit
  18. 09 Jun, 2020 1 commit
  19. 05 Jun, 2020 1 commit
  20. 03 Jun, 2020 1 commit
    • Andreas Haas's avatar
      [wasm] Introduce v8.wasm.detailed trace event category · d529da01
      Andreas Haas authored
      This CL repurposes the v8.wasm trace event category, and introduces
      additionally the v8.wasm.detailed category.
      
      The v8.wasm category is enabled by default and captures core wasm events
      like validation, compilation, instantiation, and important operations
      like grow-memory and tier-up timings.
      
      The v8.wasm.detailed category is disabled by default. It captures all
      events the previous v8.wasm category captured, like compilation of
      single functions, time needed for register allocation, ...
      
      This CL splits these categories to allow enabling the v8.wasm category
      in telemetry benchmarks to calculate compile time and other metrics
      from traces of telemetry runs.
      
      R=ecmziegler@chromium.org
      
      Bug: chromium:1084929
      Change-Id: Ida58b8f344b0ccb6ee1210e259c3e0e993eff497
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2210230
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarEmanuel Ziegler <ecmziegler@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68156}
      d529da01
  21. 27 May, 2020 1 commit
  22. 08 May, 2020 1 commit
  23. 07 May, 2020 1 commit
  24. 06 May, 2020 1 commit
  25. 28 Apr, 2020 1 commit
  26. 17 Apr, 2020 1 commit
  27. 31 Mar, 2020 1 commit
  28. 12 Mar, 2020 1 commit
  29. 11 Mar, 2020 3 commits
    • Andreas Haas's avatar
      Reland "[wasm] Do memory.copy bounds check in C++ code" · 126f1ee1
      Andreas Haas authored
      The return value of {memory_copy_wrapper} was defined as {bool} in
      the original CL. When compiled with clang, the full return register is
      written when {true} or {false} is returned. With msvc, however, the
      return value is written as a single byte, without zero-extension. In
      generated code, the full return register is used and therefore stale
      bytes in the return register caused problems.
      
      With this CL the return value is changed to {uint32_t}. This enforces
      zero-extension of the return value and thereby fixes the issue.
      
      R=clemensb@chromium.org
      
      Bug: v8:10281
      Change-Id: I628d01cfd7193fa960a7ccdf0d9fd896f510cd3e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096626
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66666}
      126f1ee1
    • Clemens Backes's avatar
      Revert "[wasm] Do memory.copy bounds check in C++ code" · b8eeb071
      Clemens Backes authored
      This reverts commit c475e704.
      
      Reason for revert: Fails on MSVC: https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/12805
      
      Original change's description:
      > [wasm] Do memory.copy bounds check in C++ code
      > 
      > In the existing implementation we first did a bounds check in generated
      > code, and then called a simple C++ function to do the actual copying.
      > With this CL now we pass the WasmInstanceObject to the C++ function in
      > addition to the memory.copy parameters. Thereby we can do the bounds
      > check in C++, which is much easier, less error prone, and which also
      > speeds up code generation and reduces code size. Performance should not
      > be worse, because we were already doing the call to C++ anyways.
      > 
      > R=​clemensb@chromium.org
      > 
      > Bug: v8:10281
      > Change-Id: I24488d92056f0b5df27a61783a274895bd37cc24
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093434
      > Commit-Queue: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66655}
      
      TBR=ahaas@chromium.org,clemensb@chromium.org
      
      Change-Id: Ic2491f635a292e004f6c95498a045ba102138dc5
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10281
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096623
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66658}
      b8eeb071
    • Andreas Haas's avatar
      [wasm] Do memory.copy bounds check in C++ code · c475e704
      Andreas Haas authored
      In the existing implementation we first did a bounds check in generated
      code, and then called a simple C++ function to do the actual copying.
      With this CL now we pass the WasmInstanceObject to the C++ function in
      addition to the memory.copy parameters. Thereby we can do the bounds
      check in C++, which is much easier, less error prone, and which also
      speeds up code generation and reduces code size. Performance should not
      be worse, because we were already doing the call to C++ anyways.
      
      R=clemensb@chromium.org
      
      Bug: v8:10281
      Change-Id: I24488d92056f0b5df27a61783a274895bd37cc24
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093434
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66655}
      c475e704