Commit Graph

20 Commits

Author SHA1 Message Date
yangguo
07fa0f4967 [serializer] do not serialize script wrappers.
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}
2016-12-19 10:53:02 +00:00
mtrofin
77b50a8e12 [wasm] disable serialization for asm-wasm
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}
2016-12-15 05:06:54 +00:00
gdeepti
0061089aa0 [wasm] Update WasmMemoryObject correctly when module memory is exported.
BUG=chromium:670683

R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2548223002
Cr-Commit-Position: refs/heads/master@{#41603}
2016-12-08 20:30:54 +00:00
mtrofin
7a1ad0c581 [turbofan] Regalloc validator: support same block pending assessment
Previous fuzzer fix broke the case when the pending assessment came from the same
block. In that case, the assessments table does not have an entry yet for the block,
because we register only when we're done processing a block.

BUG=667745

Review-Url: https://codereview.chromium.org/2519973004
Cr-Commit-Position: refs/heads/master@{#41193}
2016-11-22 17:31:06 +00:00
mtrofin
71144e5aa6 [turbofan] Use correct block when tracing pending assessments in regalloc verifier
The verifier needs to use the block and assessments in that block corresponding to
a predecessor of a "pending" assessment. Not doing that causes incorrect
assessments when 2 locations are swapped.

BUG=665402

Review-Url: https://codereview.chromium.org/2515803002
Cr-Commit-Position: refs/heads/master@{#41159}
2016-11-21 22:21:14 +00:00
eholk
d0fe942d23 [wasm] Throw a RangeError if Wasm memory could not be allocated.
This fixes a bug found by the fuzzer where we would attempt to
dereference a null handle if memory allocation failed. In this case,
the failure was because the amount of memory requested was above V8's
hardcoded limit.

BUG= https://bugs.chromium.org/p/chromium/issues/detail?id=666741

Review-Url: https://codereview.chromium.org/2514983002
Cr-Commit-Position: refs/heads/master@{#41158}
2016-11-21 21:58:53 +00:00
gdeepti
625767df91 [wasm] Linear/Exported memory maximum property should be set when maximum is defined.
- When module bytes have a memory maximum defined, compiled module object should set maximum memory
 - Exported memory objects should set maximum value on the memory objects
 - Update tests to use declared maximum values.

R=ahaas@chromium.org

Review-Url: https://codereview.chromium.org/2474333003
Cr-Commit-Position: refs/heads/master@{#40820}
2016-11-08 09:55:27 +00:00
titzer
3f207617d7 [wasm] Binary 0xD: update encoding of opcodes, types, and add immediates.
R=ahaas@chromium.org,rossberg@chromium.org,binji@chromium.org,bradnelson@chromium.org
BUG=chromium:575167, chromium:659591

Review-Url: https://codereview.chromium.org/2440953002
Cr-Commit-Position: refs/heads/master@{#40600}
2016-10-26 16:56:49 +00:00
titzer
418b239f0b [wasm] Use a Managed<WasmModule> to hold metadata about modules.
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}
2016-10-19 13:07:22 +00:00
ahaas
2f3ca961c7 [turbofan] Use uint32 to store the number of control outputs instead of uint16.
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}
2016-10-19 07:25:51 +00:00
ahaas
fa1f9c37d1 [wasm] Do not generate a loop stack check upon a decoder error.
A decoder error sets builder_ to null, which causes builder_->StackCheck
to segfault.

R=titzer@chromium.org

TEST=mjsunit/regress/wasm/loop-stack-check

Review-Url: https://codereview.chromium.org/2416873002
Cr-Commit-Position: refs/heads/master@{#40271}
2016-10-13 14:33:11 +00:00
ahaas
0e1f6d8bfc [wasm] Do not create TF nodes during verification
BUG=chromium:654377
TEST=mjsunit/regress/wasm/regression-654377
R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2403013002
Cr-Commit-Position: refs/heads/master@{#40246}
2016-10-13 08:21:47 +00:00
gdeepti
19dab886a4 [wasm] Simd128 types should not be available in asmjs modules.
- Added gating code in the module-decoder to allow SIMD code only when
 it can be decoded correctly
 - SIMD128 values should not be exported to JS
 - Try/Catch should not be available in asmjs modules
 - Trivial fixes for S128  values

BUG=chromium:648079

R=ahaas@chromium.org, titzer@chromium.org, bradnelson@chromium.org

Review-Url: https://codereview.chromium.org/2400863003
Cr-Commit-Position: refs/heads/master@{#40067}
2016-10-07 07:52:19 +00:00
ahaas
aa93e6ca95 [wasm] Call a runtime function for a MemorySize instruction.
The implementation of MemorySize with RelocatableInt32Constants is
problematic if MemorySize is placed close to a GrowMemory instruction in
the code. The use of a runtime function guarantees that the order in
which MemorySize and GrowMemory is executed is correct.

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

Committed: https://crrev.com/2c12a9a42d454a36fcd2931fa458d72832eeb689
Review-Url: https://codereview.chromium.org/2386183004
Cr-Original-Commit-Position: refs/heads/master@{#39972}
Cr-Commit-Position: refs/heads/master@{#39980}
2016-10-05 09:12:08 +00:00
ahaas
9701e79127 Revert of [wasm] Call a runtime function for a MemorySize instruction. (patchset #2 id:20001 of https://codereview.chromium.org/2386183004/ )
Reason for revert:
Patch problem

Original issue's description:
> [wasm] Call a runtime function for a MemorySize instruction.
>
> The implementation of MemorySize with RelocatableInt32Constants is
> problematic if MemorySize is placed close to a GrowMemory instruction in
> the code. The use of a runtime function guarantees that the order in
> which MemorySize and GrowMemory is executed is correct.
>
> R=titzer@chromium.org
> BUG=chromium:651961
> TEST=mjsunit/regress/wasm/regression-651961
>
> Committed: https://crrev.com/2c12a9a42d454a36fcd2931fa458d72832eeb689
> Cr-Commit-Position: refs/heads/master@{#39972}

TBR=titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:651961

Review-Url: https://codereview.chromium.org/2391223002
Cr-Commit-Position: refs/heads/master@{#39973}
2016-10-05 06:12:18 +00:00
ahaas
2c12a9a42d [wasm] Call a runtime function for a MemorySize instruction.
The implementation of MemorySize with RelocatableInt32Constants is
problematic if MemorySize is placed close to a GrowMemory instruction in
the code. The use of a runtime function guarantees that the order in
which MemorySize and GrowMemory is executed is correct.

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

Review-Url: https://codereview.chromium.org/2386183004
Cr-Commit-Position: refs/heads/master@{#39972}
2016-10-05 06:06:58 +00:00
mtrofin
c938f0df22 [wasm] explicitly mark off unlinked wasm module instances
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}
2016-10-04 21:23:24 +00:00
mtrofin
aff5ab1132 [wasm] fix for GC during instantiation.
BUG=chromium:651070

Review-Url: https://codereview.chromium.org/2371403003
Cr-Commit-Position: refs/heads/master@{#39848}
2016-09-29 04:24:42 +00:00
mtrofin
df490c3484 [wasm] Fix for cloning module heap size value
The module size is encoded as a HeapNumber, and needs to be
explicitly cloned.

BUG=chromium:647649

Review-Url: https://codereview.chromium.org/2347333002
Cr-Commit-Position: refs/heads/master@{#39845}
2016-09-29 00:48:28 +00:00
mtrofin
7d008c0d1b [wasm] moved regression test under test/mjsunit/regression/wasm
We'd like wasm regressions to live under a subfolder of the mjsunit
regression folder.

BUG=

Review-Url: https://codereview.chromium.org/2344373002
Cr-Commit-Position: refs/heads/master@{#39483}
2016-09-17 00:29:10 +00:00