1. 10 Aug, 2018 1 commit
  2. 09 Aug, 2018 1 commit
    • Junliang Yan's avatar
      s390: [wasm] Support 4GiB memories in Liftoff · 195f2f2a
      Junliang Yan authored
      Port 352e408b
      
      Original Commit Message:
      
          Add codegen support for up to 4GiB memories in Liftoff code.
      
          This CL also adds three new mjsunit tests that stress large WASM
          memories (1, 2, and 4 GiB) and checks that accesses near these
          boundaries properly generate traps.
      
          Note there is still some trickiness around the setting of:
            1.) the flag --wasm-max-mem-pages
            2.) wasm-limits.h kSpecMaxWasmMemoryPages = 65536
            3.) wasm-limits.h kV8MaxWasmMemoryPages = 32767
      
          In particular, the allocation of memories is still limited to
          3.) and the runtime flag can only lower this limit.
      
          The above means that the tests for 2GiB and 4GiB memories will silently
          OOM by design until 3.) is changed (though they currently pass with
          manual testing). I argue it is better to include these tests up front,
          since they will immediately trigger if their memory allocation succeeds.
      
          Therefore the plan is to lift the restriction on 3.) after removing
          all other other internal V8 limitations including array buffers and views.
      
      R=titzer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:7881
      LOG=N
      
      Change-Id: Ice70a9ac5a9a26b08cc77acb7deec98305574d01
      Reviewed-on: https://chromium-review.googlesource.com/1167914
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55026}
      195f2f2a
  3. 02 Jul, 2018 1 commit
  4. 28 Jun, 2018 1 commit
  5. 11 Jun, 2018 1 commit
  6. 07 Jun, 2018 1 commit
  7. 05 Jun, 2018 1 commit
  8. 18 May, 2018 1 commit
  9. 14 May, 2018 1 commit
  10. 03 May, 2018 1 commit
  11. 27 Apr, 2018 1 commit
  12. 26 Apr, 2018 1 commit
  13. 25 Apr, 2018 1 commit
  14. 24 Apr, 2018 1 commit
  15. 23 Apr, 2018 2 commits
  16. 20 Apr, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Simplify C calls · 8d2d0513
      Clemens Hammacher authored
      Instead of passing multiple pointers to input and output, or to two
      input values, just pass one pointer which holds all inputs and where
      the output is written.
      This also reduces the size of generated Turbofan graphs, since only one
      stack slot is needed and less arguments are passed to the call.
      It also fixes undefined behaviour, since we were passing a pointer e.g.
      as {uint64_t*}, but accessed it using {ReadUnalignedValue}. Now we pass
      an Address, which does not have any alignment constraints.
      
      R=ahaas@chromium.org
      
      Bug: v8:3770, v8:6600
      Change-Id: I54ef80b7e27f77587a9062560c0b3e01d6593e6d
      Reviewed-on: https://chromium-review.googlesource.com/1019147
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52702}
      8d2d0513
  17. 18 Apr, 2018 1 commit
  18. 16 Apr, 2018 1 commit
  19. 12 Apr, 2018 2 commits
  20. 09 Apr, 2018 2 commits
  21. 06 Apr, 2018 1 commit
  22. 05 Apr, 2018 5 commits
  23. 04 Apr, 2018 3 commits
    • Ben Titzer's avatar
      Revert "[wasm] Merge the WasmContext into WasmInstanceObject" · 8adb94fc
      Ben Titzer authored
      This reverts commit 57bf0bfe.
      
      Reason for revert: <INSERT REASONING HERE>
      
      Original change's description:
      > [wasm] Merge the WasmContext into WasmInstanceObject
      > 
      > This change makes lifetime management of WasmCode much simpler.
      > By using the WasmInstanceObject as the context for WASM code execution,
      > including the pointer to the memory base and indirect function tables,
      > this keeps the instance alive when WASM code is on the stack, since
      > the instance object is passed as a parameter and spilled onto the stack.
      > This is in preparation of sharing the code between instances and
      > isolates.
      > 
      > Bug: v8:7424
      > 
      > Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
      > Reviewed-on: https://chromium-review.googlesource.com/958520
      > Commit-Queue: Ben Titzer <titzer@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52361}
      
      TBR=mstarzinger@chromium.org,titzer@chromium.org,ahaas@chromium.org,clemensh@chromium.org
      
      Change-Id: I653e27b46dbc43ad773eda4292d521a508f42d79
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7424
      Reviewed-on: https://chromium-review.googlesource.com/995418Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52364}
      8adb94fc
    • Ben L. Titzer's avatar
      [wasm] Merge the WasmContext into WasmInstanceObject · 57bf0bfe
      Ben L. Titzer authored
      This change makes lifetime management of WasmCode much simpler.
      By using the WasmInstanceObject as the context for WASM code execution,
      including the pointer to the memory base and indirect function tables,
      this keeps the instance alive when WASM code is on the stack, since
      the instance object is passed as a parameter and spilled onto the stack.
      This is in preparation of sharing the code between instances and
      isolates.
      
      Bug: v8:7424
      
      Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
      Reviewed-on: https://chromium-review.googlesource.com/958520
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52361}
      57bf0bfe
    • Clemens Hammacher's avatar
      [Liftoff] Implement i64.add and i64.sub · 53eb8c51
      Clemens Hammacher authored
      This adds support for i64 addition and subtraction.
      
      R=titzer@chromium.org
      
      Bug: v8:6600
      Change-Id: If7ed762091b0ebd688eb2a8cac84e59b91c8a322
      Reviewed-on: https://chromium-review.googlesource.com/992316Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52351}
      53eb8c51
  24. 20 Mar, 2018 2 commits
  25. 19 Mar, 2018 1 commit
  26. 14 Mar, 2018 1 commit
    • Clemens Hammacher's avatar
      [Liftoff] Fix stack pointer corruption · cc862e69
      Clemens Hammacher authored
      During a C call, a previous value of the stack pointer is stored in a
      platform specific callee saved register. Loading the out argument of the
      C call might overwrite the value in that register, if the destination
      register collides with the platform specific register. Hence, do first
      use that register to restore the previous stack pointer, and only then
      load the out argument.
      Similarly, when pushing arguments to the stack, do first push all
      values and then set the platform specific register in order to avoid
      overwriting an argument value held in that register.
      
      Drive-by: Fix offset computations for parameters pushed to the stack
      for c calls.
      
      R=titzer@chromium.org
      
      Bug: chromium:820802,chromium:820896,chromium:820807,v8:6600
      Change-Id: If4567467b7912454f0bd2cad5927233c98894b03
      Reviewed-on: https://chromium-review.googlesource.com/959064Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51916}
      cc862e69
  27. 09 Mar, 2018 1 commit
    • Clemens Hammacher's avatar
      [Liftoff] Implement i32/i64 to f32 conversions · 907c7fad
      Clemens Hammacher authored
      This adds support for f32.convert_{s,u}/i{32,64}.
      On 32-bit platforms, i64 conversions are implemented by a call to a c
      function. Since the signature of this c function is very different to
      the currently used functions in Liftoff (in particular they contain an
      out parameter), this CL requires a major refactoring of how Liftoff
      generates c-calls.
      
      R=titzer@chromium.org
      
      Bug: v8:6600
      Change-Id: Iffb4d0263ca1ca3eb9c6216344220322cda16062
      Reviewed-on: https://chromium-review.googlesource.com/952122
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51841}
      907c7fad
  28. 05 Mar, 2018 2 commits
  29. 27 Feb, 2018 1 commit