Skip to content

V
V8
Switch branch/tag
  1. 31 Mar, 2017 1 commit
  3. 30 Mar, 2017 1 commit
  5. 29 Mar, 2017 1 commit
    • Andreas Haas's avatar
      [wasm] Consider void returns in the int64-lowering · 151cad81
      Andreas Haas authored 
      The int64-lowering lowers return nodes which return one int64 value into
a return node which returns two int32 values. For this lowering it has
to adjust the input count of the return operator.

The existing code assumed that if the signature of a function said that
the return type is int64, then all return nodes have int64 inputs.
However, with a recent CL we also introduced void returns. With this CL
I check if the number of inputs of a return node changes with the
DefaultLowering, and only if the number of inputs changes, then I check
if I also have to change the operator of the return node.

R=mstarzinger@chromium.org
TEST=mjsunit/regress/wasm/regression-6164
BUG=v8:6164

Change-Id: I004ab1b4be942cc045719f306705d95b48707a1c
Reviewed-on: https://chromium-review.googlesource.com/461941Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44232}
      151cad81
  7. 27 Mar, 2017 3 commits
  9. 22 Mar, 2017 1 commit
  11. 20 Mar, 2017 2 commits
  13. 06 Mar, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Fix code specialization for empty memory buffer · 7d8a3028
      Clemens Hammacher authored 
      From asm.js code we might get an empty ArrayBuffer as heap memory. In
this case, both the old memory start and the new memory start will be
nullptr. The size however has to be patched from default_size to 0.

This CL changes code specialization to be able to either patch memory
references, or patch memory sizes or both.

R=titzer@chromium.org, ahaas@chromium.org
BUG=chromium:698587

Change-Id: I4d9d811d75cb83842f23df317e8e7fc02aeb5146
Reviewed-on: https://chromium-review.googlesource.com/450257
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43613}
      7d8a3028
  15. 21 Feb, 2017 1 commit
  17. 16 Feb, 2017 1 commit
    • Andreas Haas's avatar
      [turbofan] For Word32Shl optimizations only consider the last 5 bits of the shift · 5f1661aa
      Andreas Haas authored 
      One optimization in the machine-operator-reducer did not consider that
that word32 shift left instructions only consider the last 5 bits of
the shift input.

The issue only occurs for WebAssembly because in JavaScript we always
add a "& 0xf" on the shift value to the TurboFan graph.

For additional background: The JavaScript and WebAssembly spec both
say that only the last 5 bits of the shift value are used in the
word32-shift-left operation. This means that an "x << 0x29", in the
code is actually executed as "x << 0x09". Therefore the changes in
this CL are okay because they mask the last 5 bit of the shift value.

BUG=chromium:689450

Change-Id: Id92f298ed6d7f1714b109b3f4fbcecd5ac6d30f7
Reviewed-on: https://chromium-review.googlesource.com/439312Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43245}
      5f1661aa
  19. 08 Feb, 2017 1 commit
    • Andreas Haas's avatar
      [x64] Consider both operands when emitting the REX prefix for testb. · 59bb1886
      Andreas Haas authored 
      The testb instruction requires the REX prefix when either of its
operands uses a register with the high bit set. The existing code only
considered the register operand. In the test case the REX prefix was not
emitted because the testb instruction had the register operand RAX which
does not have the high bit set. The REX prefix was necessary though
because the memory operand used R8, which has the high bit set.

R=bmeurer@chromium.org
BUG=chromium:688876

Change-Id: Ib214bebbe75965664f2aea530e29afa95a54f44f
Reviewed-on: https://chromium-review.googlesource.com/439145
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43030}
      59bb1886
  21. 26 Jan, 2017 2 commits
  23. 25 Jan, 2017 1 commit
    • clemensh's avatar
      [wasm] Fix check failure on invalid name section · 0ec3a264
      clemensh authored 
      After decoding an invalid function name (e.g. OOB), we stored the parsed
offset and length into the WasmFunction anyway, resulting in a runtime
CHECK failure later on.
This CL fixes this, and adds a regression test.

R=titzer@chromium.org
CC=mtrofin@chromium.org, bradnelson@chromium.org
BUG=chromium:684858

Review-Url: https://codereview.chromium.org/2656713003
Cr-Commit-Position: refs/heads/master@{#42654}
      0ec3a264
  25. 24 Jan, 2017 1 commit
  27. 19 Jan, 2017 1 commit
  29. 18 Jan, 2017 3 commits
  31. 10 Jan, 2017 1 commit
  33. 09 Jan, 2017 1 commit
  35. 19 Dec, 2016 1 commit
    • yangguo's avatar
      [serializer] do not serialize script wrappers. · 07fa0f49
      yangguo authored 
      The scenario here: the asm function fails asm validation,
so we emit a message. In doing so, we create a JSValue wrapper for
the script object that we cache on the script object. This wrapper
is context-dependent and causes the code serializer to choke.

R=mtrofin@chromium.org, titzer@chromium.org
BUG=chromium:674446,chromium:673321

Review-Url: https://codereview.chromium.org/2586943003
Cr-Commit-Position: refs/heads/master@{#41794}
      07fa0f49
  37. 15 Dec, 2016 1 commit
    • mtrofin's avatar
      [wasm] disable serialization for asm-wasm · 77b50a8e
      mtrofin authored 
      Determine if the scope of the function to be serialized includes asm-
wasm, and if so, bypass serialization, since we do not support it in
that scenario.

In this change, we do so regardless of whether the asm-wasm path was
successful. This is so we keep the design simple, since the guidance
to developers, moving forward, is to use wasm.

BUG=643595

Review-Url: https://codereview.chromium.org/2573193002
Cr-Commit-Position: refs/heads/master@{#41704}
      77b50a8e
  39. 08 Dec, 2016 1 commit
  41. 22 Nov, 2016 1 commit
  43. 21 Nov, 2016 2 commits
  45. 08 Nov, 2016 1 commit
  47. 26 Oct, 2016 1 commit
  49. 19 Oct, 2016 2 commits
    • titzer's avatar
      [wasm] Use a Managed<WasmModule> to hold metadata about modules. · 418b239f
      titzer authored 
      This CL refactors the handling of metadata associated with WebAssembly
modules to reduce the duplicate marshalling of data from the C++ world
to the JavaScript world. It does this by wrapping the C++ WasmModule*
object in a Foreign that is rooted from the on-heap WasmCompiledModule
(which is itself just a FixedArray). Upon serialization, the C++ object
is ignored and the original WASM wire bytes are serialized. Upon
deserialization, the C++ object is reconstituted by reparsing the bytes.

This is motivated by increasing complications in implementing the JS
API, in particular WebAssembly.Table, which must perform signature
canonicalization across instances.

Additionally, this CL implements the proper base + offset initialization
behavior for tables.

R=rossberg@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org,yangguo@chromium.org
BUG=v8:5507, chromium:575167, chromium:657316

Review-Url: https://chromiumcodereview.appspot.com/2424623002
Cr-Commit-Position: refs/heads/master@{#40434}
      418b239f
    • ahaas's avatar
      [turbofan] Use uint32 to store the number of control outputs instead of uint16. · 2f3ca961
      ahaas authored 
      Using uint32 to store the the number of control outputs allows WebAssembly switches to have more than 2^16 case.

BUG=v8:5531
TEST=mjsunit/regress/wasm/regression-5531
R=titzer@chromium.org

Review-Url: https://chromiumcodereview.appspot.com/2425983002
Cr-Commit-Position: refs/heads/master@{#40420}
      2f3ca961
  51. 13 Oct, 2016 2 commits
  53. 07 Oct, 2016 1 commit
  55. 05 Oct, 2016 3 commits
  57. 04 Oct, 2016 1 commit
    • mtrofin's avatar
      [wasm] explicitly mark off unlinked wasm module instances · c938f0df
      mtrofin authored 
      This fixes a gc stress bug. We cannot rely on an ordering of
clearing of the weak cells, so we explicitly reset the weak
link to the owning instance, when finalizing a compiled
module. In turn, this serves as a reliable signal when GCs
happen while instantiating, allowing us to correctly link the
new instance.

BUG=chromium:652425

Review-Url: https://codereview.chromium.org/2393443003
Cr-Commit-Position: refs/heads/master@{#39964}
      c938f0df