1. 31 Jan, 2022 1 commit
  2. 10 Jun, 2021 2 commits
  3. 09 Jun, 2021 2 commits
  4. 08 Jun, 2021 1 commit
  5. 04 Jun, 2021 1 commit
    • Manos Koukoutos's avatar
      [wasm] Implement EvaluateInitExpression · dc3f7f81
      Manos Koukoutos authored
      So far, initializer-expression evaluation was tied to setting global
      values. We now need it to operate independently of globals, so that we
      can implement new constant expressions like struct.new, which need their
      arguments to be computed before they can be initialized.
      
      Changes:
      - Move type computation of WasmInitExpr into WasmInitExpr::type.
      - Fix WasmInitExpr::type kRttSub case for rtts without depth.
      - Introduce InstanceBuilder::EvaluateInitExpression().
      - Rename InstanceBuilder::GetRawGlobalPointer() ->
        GetRawUntaggedGlobalPointer().
      - Simplify InstanceBuilder::InitGlobals using EvaluateInitExpression().
      - Introduce ValueType::is_numeric.
      - Add Simd128(byte*) constructor.
      - Introduce WasmValue::CopyTo() for numeric types.
      
      Change-Id: Ic502b611f3998187abd9fc6ec377c2954c27abdc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2939982
      Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74949}
      dc3f7f81
  6. 05 May, 2021 1 commit
    • Manos Koukoutos's avatar
      [wasm] Complete element segment features for reftypes/typed-funcref · 37579df7
      Manos Koukoutos authored
      Main changes:
      - Allow global.get in elements segments with expressions-as-elements.
      - Allow element segments with types other than funcref.
      
      Detailed changes:
      - Move WasmInitExpr to its own file. Add stream opearator << support.
      - Simplify type of PrintCollection.
      - Make WasmElemSegment use an array of WasmInitExpr's over the previous
        ad-hoc implementation. Move null_index to WasmModuleBuilder.
      - Refactor consume_element_segment_header. Make it return a
        WasmElemSegment.
      - Refactor consume_element_expr. Make it return a WasmInitExpr.
      - Refactor DecodeElementSection. Make it invoke
        consume_element_segment_header, then populate its element array.
      - Update module-instantiate.cc to handle global.get elements.
      - Fix bug in wasm-objects.cc where the wrong type index was passed into
        module()->has_signature()
      - Adapt and add tests.
      
      Change-Id: I5abfbe424dbb750ee2dca59f91c451ffcb79f95f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2857959
      Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74374}
      37579df7
  7. 22 Mar, 2021 1 commit
  8. 16 Mar, 2021 1 commit
  9. 12 Mar, 2021 1 commit
  10. 05 Mar, 2021 1 commit
  11. 12 Oct, 2020 1 commit
  12. 24 Sep, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][memory64] Fix types used for bounds checks · 618a2888
      Clemens Backes authored
      The memory offset is read as a u64 in the memory64 proposal, independent
      of the actual type of the memory. The actual memory size of a module (at
      runtime) can only be within intptr_t/uintptr_t range though. This
      assumption was already used when constructing the TurboFan graph, but
      the C++ types did not reflect it yet.
      
      This CL fixes that:
      
      1) Use uint64_t type for bounds checks (only within the method for now,
         callers still pass a uint32_t).
      2) Use uintptr_t for storing the minimum and maximum possible memory
         size at runtime (in CompilationEnv); clamp memory sizes to values
         that can actually happen at runtime.
      
      R=manoskouk@chromium.org
      
      Bug: v8:10949
      Change-Id: I6559f9a3abc2aa338eba4618479456f6efb5e772
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2426405Reviewed-by: 's avatarManos Koukoutos <manoskouk@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70121}
      618a2888
  13. 23 Sep, 2020 1 commit
  14. 09 Jun, 2020 1 commit
  15. 24 Oct, 2019 1 commit
  16. 16 Jul, 2019 1 commit
  17. 01 Jul, 2019 2 commits
  18. 21 Jun, 2019 1 commit
  19. 24 May, 2019 1 commit
  20. 23 May, 2019 2 commits
  21. 03 Apr, 2019 1 commit
    • Michael Starzinger's avatar
      [wasm] Add support for "br_on_exn" in the interpreter. · 46a99b07
      Michael Starzinger authored
      This adds preliminary support for handling the "br_on_exn" opcode in the
      interpreter. It also makes "catch" and "rethrow" use a proper exception
      reference instead of a dummy value.
      
      To that end this also adds {Handle<>} as a new kind of {WasmValue} which
      is intended to pass reference values (e.g. "anyref" or "except_ref") to
      the runtime system. Therefore lifetime of such a {WasmValue} is directly
      coupled to any surrounding {HandleScope}.
      
      For now we just store {Handle<>} directly on the simulated operand stack
      of the interpreter. This is of course bogus, since the surrounding scope
      does not outlive the interpreter activation. Decoupling the lifetime of
      the operand stack from a {HandleScope} will be done in a follow-up CL.
      
      As a drive-by this change also implements support for the "ref_null" and
      the "ref_is_null" opcodes as a proof-of-concept that the new {WasmValue}
      is also applicable to the "anyref" reference type.
      
      R=clemensh@chromium.org
      TEST=cctest/test-run-wasm-interpreter/ReferenceTypeLocals
      BUG=v8:8091,v8:7581
      
      Change-Id: I2307e0689a19c4aab1d67f1ba6742cb3cc31aa3c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1550299
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60598}
      46a99b07
  22. 01 Aug, 2018 1 commit
  23. 25 May, 2018 1 commit
  24. 18 May, 2018 1 commit
  25. 02 Feb, 2018 1 commit
  26. 26 Oct, 2017 1 commit
  27. 23 Oct, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] [interpreter] Box floats for certain operations · 319b7868
      Clemens Hammacher authored
      There are wasm operations which operate on floats or double, but they
      need to preserve the exact bit pattern. Thus they cannot be stored and
      passed as float or double, since that might flip the signaling NaN bit.
      This CL extends WasmValue to store floats and doubles as bit pattern,
      and adds accessors to extract them as Float32 or Float64.
      The interpreter is changed to execute certain operations (i32.abs,
      i32.neg, i64.abs, i64.neg, f32.reinterpret/i32, f64.reinterpret/i64) on
      boxed floats.
      
      R=titzer@chromium.org
      
      Bug: v8:6954
      Change-Id: I0251d1a67b6caf593194d4eb292a325cdd3f20cf
      Reviewed-on: https://chromium-review.googlesource.com/730716
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48819}
      319b7868
  28. 18 Jul, 2017 1 commit