1. 09 Mar, 2022 3 commits
    • Clemens Backes's avatar
      Reland "[asm] Reject import calls with too many parameters" · 9b810b9f
      Clemens Backes authored
      This is a reland of commit a664aef0.
      The test is made ~25x faster by using integer parameters instead of
      floating point.
      
      Original change's description:
      > [asm] Reject import calls with too many parameters
      >
      > The asm parser was missing a check for too many parameters for calls to
      > imported functions. For regular functions this check implicitly existed
      > because the limit was checked at the function declaration, and the call
      > site needs to match the declared parameter count.
      >
      > R=mslekova@chromium.org
      >
      > Bug: chromium:1302596
      > Change-Id: I0d35e70a66d682ee8fdecf5c8ea4d2b1419ce684
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3509393
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79415}
      
      Bug: chromium:1302596
      Change-Id: I138561742b38939a1c2c9a69a6fa508d4f3a028d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3513613Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79424}
      9b810b9f
    • Clemens Backes's avatar
      Revert "[asm] Reject import calls with too many parameters" · 9d96ebbb
      Clemens Backes authored
      This reverts commit a664aef0.
      
      Reason for revert: Times out on CFI: https://cr-buildbucket.appspot.com/build/8820170241901030897
      
      Original change's description:
      > [asm] Reject import calls with too many parameters
      >
      > The asm parser was missing a check for too many parameters for calls to
      > imported functions. For regular functions this check implicitly existed
      > because the limit was checked at the function declaration, and the call
      > site needs to match the declared parameter count.
      >
      > R=​mslekova@chromium.org
      >
      > Bug: chromium:1302596
      > Change-Id: I0d35e70a66d682ee8fdecf5c8ea4d2b1419ce684
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3509393
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79415}
      
      Bug: chromium:1302596
      Change-Id: I743647f739e0cc93b2e99145086dbbb7d2660c79
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3512853
      Auto-Submit: Clemens Backes <clemensb@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/main@{#79417}
      9d96ebbb
    • Clemens Backes's avatar
      [asm] Reject import calls with too many parameters · a664aef0
      Clemens Backes authored
      The asm parser was missing a check for too many parameters for calls to
      imported functions. For regular functions this check implicitly existed
      because the limit was checked at the function declaration, and the call
      site needs to match the declared parameter count.
      
      R=mslekova@chromium.org
      
      Bug: chromium:1302596
      Change-Id: I0d35e70a66d682ee8fdecf5c8ea4d2b1419ce684
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3509393Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79415}
      a664aef0
  2. 18 Feb, 2022 1 commit
  3. 13 Jan, 2022 1 commit
  4. 16 Dec, 2021 1 commit
  5. 08 Nov, 2021 1 commit
  6. 05 Nov, 2021 1 commit
    • Manos Koukoutos's avatar
      [wasm][fuzzer] Complex init. expressions in JS testcase · 74d9a764
      Manos Koukoutos authored
      We enable struct.new and array.init initializer expressions in the JS
      testcase generated by --wasm-fuzzer-gen-test. We needed to make some
      changes in the WasmInitExpr class, and to implement a new interface for
      the WasmFullDecoder, which constructs a WasmInitExpr.
      Changes:
      - Make WasmInitExpr a ZoneObject. Use a pointer for its operands_ field.
        This is needed so WasmInitExpr is trivially copiable, and thus usable
        as a Value type in WasmFullDecoder.
      - Implement a WasmFullDecoder interface in wasm-fuzzer-common that
        constructs a WasmInitExpr. Use it to decode initializers in the
        module generated by the fuzzer.
      - Change AppendInitExpr to take a WasmInitExpr as argument.
      - Fix an issue with printing of struct definitions.
      - Change initializer expression used for structs to struct.new_with_rtt.
        This is consistent with the currently used structural types.
      
      Bug: v8:11954
      Change-Id: I65a87cc98701a54f32500be192b3b6eef2ff6c8c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3257712Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77730}
      74d9a764
  7. 26 Oct, 2021 1 commit
  8. 27 Sep, 2021 1 commit
  9. 31 Aug, 2021 1 commit
    • Manos Koukoutos's avatar
      [wasm] Support reftypes tables in WasmModuleBuilder · 797e4afe
      Manos Koukoutos authored
      WasmModuleBuilder is a class that is used to build Wasm modules in the
      asm.js parser, in the fuzzer, as well as some tests. When it comes to
      Wasm tables, WasmModuleBuilder currently supports only basic tables
      (before the reftypes proposal) using an ad-hoc indirect-function index
      vector.
      This CL adds proper support for element sections and tables that use
      them in the full potential of the reftypes extension. The new
      functionality will only be used in the fuzzer and potentially some tests
      in the future. Along this, we drop some functionality from
      WasmModuleBuilder that was only used in tests and is redundant with the
      new architecture.
      Additionally, we remove tables other than externref and funcref from the
      fuzzer (which were not supported properly or used anyway). We will
      reintroduce them at a later time.
      
      Bug: v8:11954
      Change-Id: I0a4f6e7b63b6e3d9f7da03b5202fbf14d8678332
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3122162
      Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76597}
      797e4afe
  10. 06 Jul, 2021 1 commit
  11. 01 Jul, 2021 1 commit
  12. 24 Jun, 2021 3 commits
  13. 21 Jun, 2021 1 commit
  14. 18 Jun, 2021 1 commit
  15. 14 Jun, 2021 1 commit
  16. 07 Jun, 2021 1 commit
  17. 25 May, 2021 1 commit
    • Clemens Backes's avatar
      [wasm] Clean up spec'ed max memory vs dynamic max · 2d04a627
      Clemens Backes authored
      There are two different limits for the maximum memory size in
      WebAssembly:
      1) A 4GB limit which is the same on all platforms, and is observable for
      JS programs. It is used to limit the allowed declared maximum size of a
      wasm memory.
      2) A potentially lower limit (2GB on 32-bit systems, 4GB otherwise)
      which can be further limited using a command-line flag. This limit is
      used whenever actually allocating or growing a wasm memory. This limit
      is not directly observable, but we make sure that no wasm memory will
      ever be bigger than this limit.
      
      The second limit is the one we should check against when allocating or
      growing memory, while the first limit should be used when validating
      a module (or the parameters for WebAssembly.Memory). The compiler can
      rely on no memory being bigger than the second limit, which again is
      never bigger than the first limit.
      
      This CL adds some more documentation to the two limits, and cleans up
      all usages.
      This also makes {kPlatformMaxPages} and {kMaxMemoryPagesAtRuntime}
      obsolete.
      
      R=jkummerow@chromium.org
      
      Bug: chromium:1207263
      Change-Id: I43541aafd3f497d1c368bd9400e9bc667bdfd3d9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2910787
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74742}
      2d04a627
  18. 29 Mar, 2021 1 commit
  19. 25 Feb, 2021 1 commit
  20. 26 Nov, 2020 1 commit
  21. 11 Nov, 2020 1 commit
  22. 03 Nov, 2020 1 commit
  23. 02 Nov, 2020 1 commit
  24. 20 Oct, 2020 1 commit
  25. 29 Sep, 2020 1 commit
  26. 24 Sep, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Remove --wasm-max-mem-pages-growth flag · 5f265c33
      Clemens Backes authored
      This unifies {max_initial_mem_pages} and {max_maximum_mem_pages} into
      {max_mem_pages}.
      The {CompilationEnv} constructor was incorrectly using the former
      instead of the latter anyway. This did not really matter though, since
      they typically have the same value.
      Also, there is not a single test that sets --wasm-max-mem-pages-growth.
      
      R=manoskouk@chromium.org
      CC=jkummerow@chromium.org
      
      Bug: v8:10949
      Change-Id: Ib7ab9b4c239d50b72013087eda5a214829c90369
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2426619Reviewed-by: 's avatarManos Koukoutos <manoskouk@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70114}
      5f265c33
  27. 28 Aug, 2020 1 commit
  28. 14 Aug, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Change OffThreadIsolate to LocalIsolate · f1589bbe
      Leszek Swirski authored
      This patch introduces a new LocalIsolate and LocalFactory, which use
      LocalHeap and replace OffThreadIsolate and OffThreadFactory. This allows
      us to remove those classes, as well as the related OffThreadSpace,
      OffThreadLargeObjectSpace, OffThreadHeap, and OffThreadTransferHandle.
      OffThreadLogger becomes LocalLogger.
      
      LocalHeap behaves more like Heap than OffThreadHeap did, so this allows
      us to additionally remove the concept of "Finish" and "Publish" that the
      OffThreadIsolate had, and allows us to internalize strings directly with
      the newly-concurrent string table (where the implementation can now move
      to FactoryBase).
      
      This patch also removes the off-thread support from the deserializer
      entirely, as well as removing the LocalIsolateWrapper which allowed
      run-time distinction between Isolate and OffThreadIsolate. LocalHeap
      doesn't support the reservation model used by the deserializer, and we
      will likely move the deserializer to use LocalIsolate unconditionally
      once we figure out the details of how to do this.
      
      Bug: chromium:1011762
      
      Change-Id: I1a1a0a72952b19a8a4c167c11a863c153a1252fc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315990
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69397}
      f1589bbe
  29. 24 Jul, 2020 1 commit
    • Leszek Swirski's avatar
      [compiler] Off-thread finalize each function immediately · 198deea2
      Leszek Swirski authored
      Allow "iterative" finalization when off-thread finalization is enabled,
      meaning that each compiled function is finalized immediately after
      compilation, rather than all functions being first compiled and then
      finalized.
      
      This is what we do on the main thread, and it reduces peak Zone memory
      usage by being able to discard empty compilation Zones earlier.
      
      One necessary functionality for this was being able to defer the
      finalization of asm.js functions until the main thread pause, since
      they can't be finalized off-thread -- previously we would just bail
      out of doing the off-thread finalization if any inner function was
      asm.js.
      
      Bug: chromium:1011762
      Change-Id: I21ff69d62eaa93b5ff908624b7115601e36f70f1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282536Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69032}
      198deea2
  30. 17 Jul, 2020 1 commit
    • Clemens Backes's avatar
      [asm] Fix use-after-free in ZoneVectors · 7887ae6f
      Clemens Backes authored
      The AsmParser kept pointers into ZoneVectors, which were accessed even
      after those vector might have grown. For regular vectors, this would be
      a use-after-free; with ZoneVectors it is technically allowed, since the
      old memory stays alive. This will change with
      https://crrev.com/c/2302895, which zaps zone memory which is
      deallocated. Eventually, we might want to reuse large deallocations in
      zone memory, hence this "use after free" needs to be fixed.
      
      This CL fixes the issue by explicitly re-allocating in the zone instead
      of using ZoneVectors. This makes sure that the old memory stays alive.
      This is kind of a quick-fix, but since asm.js is more or less deprecated
      anyway (in favor of Wasm), it's OK if this code does not profit from
      future ZoneVector memory re-use optimizations.
      
      Drive-by: Move field initializers to the field declaration.
      
      R=ishell@chromium.org
      
      Bug: v8:10717
      Change-Id: I56c1feb49d05080e78a6620273b55b4e18156254
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2304581Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68917}
      7887ae6f
  31. 10 Jul, 2020 1 commit
  32. 09 Jul, 2020 1 commit
    • Manos Koukoutos's avatar
      [wasm-gc] Refactoring in preparation of generalizing WasmInitExpr · 01e59c4b
      Manos Koukoutos authored
      Motivation: With rtt.sub now allowed in constant expressions, we have
      to generalize WasmInitExpr to be able to handle expressions with
      operands. This CL prepares the ground for this change and adds no
      functionality.
      
      Changes:
      - ValueType::heap_representation and HeapType::representation now
        return HeapType::Representation.
      - Add ValueType::is_rtt().
      - WasmInitExpr:
        - Make kind private. Rename val -> operator, make it private. Add
          accessors.
        - Rename kGlobalIndex -> kGlobalGet.
        - Squash global_index and function_index into index.
        - Add heap_type Immediate. Use it for RefNullConst. TypeOf in
          module-decoder.cc can now fully determine the type of a
          WasmInitExpr.
        - Add class constructors/static method constructors for each Operator
          kind.
        - Delete copy constructor. WasmInitExpr will use std::unique_ptr for
          its operands.
      - consume_init_expr now uses a stack.
      - A few minor improvements.
      
      Bug: v8:7748
      Change-Id: I3ba3ee7ac2d6bc58e887790c37110ceb80658985
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2284483
      Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68759}
      01e59c4b
  33. 10 Jun, 2020 1 commit
  34. 06 May, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Unify compiler.cc finalization logic · 58b12f63
      Leszek Swirski authored
      This patch unfies the finalization logic between the various unoptimized
      compilation paths in compiler.cc, taking the various post-processings and
      fixups needed for off-thread finalization and performing them in the same
      order for the other finalizations.
      
      It also unifies the general compilation path between streaming script
      compilation, main-thread script compilation, and main-thread lazy
      compilation, making the main-thread paths both use an iterative execution
      and finalization, and making all three use the same job helper methods
      and overall finalization helper.
      
      Bug: chromium:1011762
      Change-Id: Ibe56f6d2f75a2deffbe9e0b600ded8a02293b722
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172790
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67609}
      58b12f63
  35. 24 Apr, 2020 1 commit
  36. 01 Apr, 2020 1 commit
    • Clemens Backes's avatar
      [asm] Fix double literals without dots · 7bb686a9
      Clemens Backes authored
      Double literals without dots should still be parsed as double constants,
      not unsigned constants. The static_cast would remove the fractional
      part, making constants like "1e-15" come out as "0" unsigned constants.
      
      The precise semantics is not spec'ed, so we still consider literals like
      "1e1" to be unsigned, and only switch to double if there is a fractional
      part.
      
      R=ecmziegler@chromium.org
      
      Bug: chromium:1065635
      Change-Id: I0aac018058a149632e0849572d19fdcc7b2af7aa
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2126922Reviewed-by: 's avatarEmanuel Ziegler <ecmziegler@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66949}
      7bb686a9