This reverts commit eb65f35e96.
Reason for revert: Broke jetstream benchmark on android.
BUG=chromium:750828
Original change's description:
> [wasm] redirect wasm calls to js functions through a GCed table
>
> With this patch, rather than embedding the JSReceiver address directly
> in the WasmToJS wrappers, we put that in a fixed array with global handle
> scope and instead embed the location of the handle and the index in the
> wrapper. This ensures that the wrapper doesn't need to be patched if the
> GC kicks in. This is needed to get the WASM code off the GCed heap.
>
> R=mtrofin@chromium.org
>
> Bug:
> Change-Id: Ie5a77a78cdecec51b04f702c63b8e4285e6a2d8d
> Reviewed-on: https://chromium-review.googlesource.com/581682
> Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46884}
TBR=mtrofin@chromium.org,aseemgarg@google.com,aseemgarg@chromium.org,clemensh@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I26f49ee0a1fe73cc5d8852ded87b56638be39ebf
Reviewed-on: https://chromium-review.googlesource.com/596268
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47059}
We've been passing a context to the compiler, which turns out to be
solely used to determine if we're executing in a specific cctest configuration.
This change adds a configuration to the graph builder that we can use to
explicitly opt out of stack checks and traps. CcTests default to opting out,
except for the few that don't.
Bug:
Change-Id: I4724e31c2a62e9b3ab4feadb788287c374b39f53
Reviewed-on: https://chromium-review.googlesource.com/585779
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46943}
This reverts commit 862d605c13.
Reason for revert: fixed compile issue
Original change's description:
> Revert "[wasm] Consolidate function table representation."
>
> This reverts commit 4a45f35f26.
>
> Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/25471
>
> Original change's description:
> > [wasm] Consolidate function table representation.
> >
> > This CL avoids the need to reference the function tables (and signatures)
> > as either fixed arrays or vectors, preferring vectors.
> >
> > The only place we need fixed arrays is on the compiled module, to support
> > serialization. When we move off the GC heap, we'll also move away
> > from fixed arrays in that last case.
> >
> > The CL aids with getting wasm of the GC heap, by reducing the places
> > and representations we'll need to change when changing the way we
> > reference fixed tables.
> >
> > Bug:
> > Change-Id: Id4e43905a3df39062bf2839fa72dd5d9a0fe87da
> > Reviewed-on: https://chromium-review.googlesource.com/588334
> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#46917}
>
> TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
>
> Change-Id: Ie7d04f7ec74d6d0b3783df1c78c91c100ab784f4
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://chromium-review.googlesource.com/588627
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46918}
TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
Change-Id: Ic0ba8097c13f2b1afd263b6243360e8ab95ae474
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/588667
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46919}
This reverts commit 4a45f35f26.
Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/25471
Original change's description:
> [wasm] Consolidate function table representation.
>
> This CL avoids the need to reference the function tables (and signatures)
> as either fixed arrays or vectors, preferring vectors.
>
> The only place we need fixed arrays is on the compiled module, to support
> serialization. When we move off the GC heap, we'll also move away
> from fixed arrays in that last case.
>
> The CL aids with getting wasm of the GC heap, by reducing the places
> and representations we'll need to change when changing the way we
> reference fixed tables.
>
> Bug:
> Change-Id: Id4e43905a3df39062bf2839fa72dd5d9a0fe87da
> Reviewed-on: https://chromium-review.googlesource.com/588334
> Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46917}
TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
Change-Id: Ie7d04f7ec74d6d0b3783df1c78c91c100ab784f4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/588627
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46918}
This CL avoids the need to reference the function tables (and signatures)
as either fixed arrays or vectors, preferring vectors.
The only place we need fixed arrays is on the compiled module, to support
serialization. When we move off the GC heap, we'll also move away
from fixed arrays in that last case.
The CL aids with getting wasm of the GC heap, by reducing the places
and representations we'll need to change when changing the way we
reference fixed tables.
Bug:
Change-Id: Id4e43905a3df39062bf2839fa72dd5d9a0fe87da
Reviewed-on: https://chromium-review.googlesource.com/588334
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46917}
With this patch, rather than embedding the JSReceiver address directly
in the WasmToJS wrappers, we put that in a fixed array with global handle
scope and instead embed the location of the handle and the index in the
wrapper. This ensures that the wrapper doesn't need to be patched if the
GC kicks in. This is needed to get the WASM code off the GCed heap.
R=mtrofin@chromium.org
Bug:
Change-Id: Ie5a77a78cdecec51b04f702c63b8e4285e6a2d8d
Reviewed-on: https://chromium-review.googlesource.com/581682
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46884}
This allows to reuse the class e.g. in the baseline compiler.
R=titzer@chromium.org
Change-Id: I7251af16e8c74f267834a9cefb676edf3c9f3a07
Reviewed-on: https://chromium-review.googlesource.com/570020
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46735}
Signature maps should only be updated, but never copied. We had a bug
because we accidentally updated a copy of the map. This refactoring
prevents any such bugs in the future, and fixes more occurences where
we accidentally copied structs containing a signature map (the move-only
constraint also extends to all structs containing a signature map).
Drive-by: Make InstanceBuilder::NeedsWrappers const.
R=titzer@chromium.org
Bug: chromium:741750
Change-Id: Id919203d8c4078e608a1163e5c790c97d06a9753
Reviewed-on: https://chromium-review.googlesource.com/571791
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46728}
This is a reland of 5648aad553.
Previous compile error should be fixed by disabling strict aliasing
assumptions on gyp: https://chromium-review.googlesource.com/c/571806
Original change's description:
> [wasm] Don't store global handles in the interpreter
>
> Storing global handles in the interpreter is dangerous, because the
> global handles are strong roots into the heap. The interpreter itself is
> referenced from the heap via a Managed. Hence the interpreter keeps the
> instance alive, while the instance keeps the Managed alive. So the GC
> will never collect them.
>
> This CL refactors this to only store the handle to the instance object
> while executing in the interpreter, and clearing it when returning.
> It also removes the cache of import wrappers, as it should not be
> performance critical, but keeps lots of objects alive. If it turns out
> to be performance critical, we will have to reintroduce such a cache
> stored in the WasmDebugInfo object.
>
> R=titzer@chromium.org
> CC=ahaas@chromium.org
>
> Bug: chromium:610330
> Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb
> Reviewed-on: https://chromium-review.googlesource.com/567058
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46629}
TBR=titzer@chromium.org
Bug: chromium:610330
Change-Id: Ic7836b1b1a044a89f2138f0c76f92acd3a1b2f2b
Reviewed-on: https://chromium-review.googlesource.com/570578
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46679}
This reverts commit 5648aad553.
Reason for revert: Compile error on mips:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/10732
Original change's description:
> [wasm] Don't store global handles in the interpreter
>
> Storing global handles in the interpreter is dangerous, because the
> global handles are strong roots into the heap. The interpreter itself is
> referenced from the heap via a Managed. Hence the interpreter keeps the
> instance alive, while the instance keeps the Managed alive. So the GC
> will never collect them.
>
> This CL refactors this to only store the handle to the instance object
> while executing in the interpreter, and clearing it when returning.
> It also removes the cache of import wrappers, as it should not be
> performance critical, but keeps lots of objects alive. If it turns out
> to be performance critical, we will have to reintroduce such a cache
> stored in the WasmDebugInfo object.
>
> R=titzer@chromium.org
> CC=ahaas@chromium.org
>
> Bug: chromium:610330
> Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb
> Reviewed-on: https://chromium-review.googlesource.com/567058
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46629}
TBR=titzer@chromium.org,clemensh@chromium.org
Change-Id: Ifadfb885f937f37bb3eab4732a97f20ff40c2583
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:610330
Reviewed-on: https://chromium-review.googlesource.com/569962
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46630}
Storing global handles in the interpreter is dangerous, because the
global handles are strong roots into the heap. The interpreter itself is
referenced from the heap via a Managed. Hence the interpreter keeps the
instance alive, while the instance keeps the Managed alive. So the GC
will never collect them.
This CL refactors this to only store the handle to the instance object
while executing in the interpreter, and clearing it when returning.
It also removes the cache of import wrappers, as it should not be
performance critical, but keeps lots of objects alive. If it turns out
to be performance critical, we will have to reintroduce such a cache
stored in the WasmDebugInfo object.
R=titzer@chromium.orgCC=ahaas@chromium.org
Bug: chromium:610330
Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb
Reviewed-on: https://chromium-review.googlesource.com/567058
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46629}
This adds a convenience method for the common Smi to int conversion
pattern.
Bug:
Change-Id: I7d7b171c36cfec5f6d10c60f1d9c3e06e3aed0fa
Reviewed-on: https://chromium-review.googlesource.com/563205
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46516}
This CL refactors the internal representation of JavaScript-exposed
WebAssembly objects to be more like other such objects in V8. By introducing
a new instance type for each of the JS-exposed types, we get more robust
typechecking without using embedder fields (which were previously used
when these objects where instance type JS_API_OBJECT).
In addition to the new instance types, the subclasses X of JSObject
(WasmInstanceObject, WasmMemoryObject, WasmModuleObject, WasmTableObject)
now have appropriate Is##X() methods on Object and are now robust.
BUG=v8:6547
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
Review-Url: https://codereview.chromium.org/2964943002
Cr-Commit-Position: refs/heads/master@{#46475}
On x86, signalling NaNs get converted to quiet NaNs when they get push
on the stack and popped again. This happens in the code generation for
arm, specifically for the vmov instruction with the immediate parameter.
This CL replaces the vmov function in assembler-arm to take the
immediate as a uint64_t instead of a double, to guarantee that the bit
pattern does not change even if the parameter is a signalling NaN.
BUG=v8:6564
Change-Id: I062559f9a7ba8b0f560628e5c39621ca578c3e7d
Reviewed-on: https://chromium-review.googlesource.com/558964
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/master@{#46418}
The naming convention in v8 has trivial getters named like the field,
no 'get_' prefix, and dropping the '_' suffix of the field.
BUG=
Review-Url: https://codereview.chromium.org/2958283003
Cr-Commit-Position: refs/heads/master@{#46332}
It appears we actually get a compile time boost, and sometimes a
runtime boost, at the cost of some reloc info growth.
Bug:
Change-Id: I1d1dc48f364e6611f895ebd00f86451199dd8626
Reviewed-on: https://chromium-review.googlesource.com/544713
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46302}
The fuzzer has already been removed from chromium. In addition I removed
code which was only used by this fuzzer.
BUG=chromium:734550
R=clemensh@chromium.orgCC=mstarzinger@chromium.org
Change-Id: I2ff4614e4d64131412ead759318e5c38e38f5d3d
Reviewed-on: https://chromium-review.googlesource.com/542816
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46078}
- Now that there are no boolean vector types, we can directly test the
results of relational ops.
Bug: v8:6020
Change-Id: Id2139133ae3a548a9985a26a3427cbeddc6272a6
Reviewed-on: https://chromium-review.googlesource.com/536176
Reviewed-by: Aseem Garg <aseemgarg@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46075}
- Use correct prefixes for SIMD/Atomics ops
- S128 LoadMem/StoreMem should not use 0xc0/0xc1 opcodes, these are now
being used for sign extension
- S128 LoadMem/StoreMem should use prefixed opcodes
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2943773002
Cr-Commit-Position: refs/heads/master@{#46016}
- Eliminates S32x4Shuffle, S16x8Shuffle opcodes. All shuffles are subsumed
by S8x16Shuffle. This aligns us with the latest WASM SIMD spec.
LOG=N
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2923103003
Cr-Commit-Position: refs/heads/master@{#45929}
This gives the embedder more context for deciding whether code
generation should be allowed or not, or they can chose to include the
code in a report.
BUG=chromium:732736
R=ahaas@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ibbaa3d0574319d290f15565be3eed2ee4d3dda36
Reviewed-on: https://chromium-review.googlesource.com/532875
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45905}
Once a buffer has been externalized, V8 is no longer responsible for managing
the memory. The fact that V8 was freeing was leading to double free errors once
Blink's GC got around to freeing the buffer too.
Bug: chromium:730171, chromium:731046
Change-Id: Ib18a7e37cafd51bce0c5a983d5cf8f3e64eb2c13
Reviewed-on: https://chromium-review.googlesource.com/530132
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45882}
Avoid constructing zones and large zone objects when initializing
WasmCompilationUnit. The main reason we did that is so we can cache
the CEntryStub node, which requires a code object, obtainable only
on the main thread. We need that value, however, on background threads,
which is also where we need the aforementioned large objects. We only
need that for the WasmCompilationUnits being currently compiled, which
is a number proportional to the number of background threads provided
by the embedder. Specifically, one zone is needed only for the duration
of the background compilation, while the second zone needs to survive
past that, so the compilation results may be committed to the GC heap
as Code objects.
The problem with these large objects is that the first allocation
in a Zone is at minimum 8KB. We used to allocate 2 zones. For
modules with 200K functions, that means 3.2GB of memory pre-allocated
before any of it is actually needed.
This change attaches a Handle to the CEntryStub on the WasmCompilationUnits,
and delays zone creation to when needed. The change also adds a way to
cache CEntryStubs in a JSGraph from a given Code handle - limited to the
scenario needed by wasm (and removable once we get wasm off the GC heap,
which subsumes removing this dependency on CEntryStubs)
An additional constraint for this change is that we want it to be easily
back-mergeable to address chromium:723899.
For the wasm payload in question, collecting the max memory used by d8
using /usr/bin/time --format='(%Xtext+%Ddata %Mmax)', we get the
following numbers (in KB):
- unchanged: 3307480
- patch 1: 1807140 (45% reduction)
- patch 3: 1230320 (62% reduction from first)
- patch 5/6: 519368 (84% reduction from first)
Bug: chomium:732010, chromium:723899
Change-Id: I45b96792daf8a9c8dc47d45fb52da75945a41401
Reviewed-on: https://chromium-review.googlesource.com/530193
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45880}
In many places in WasmModule and contained structs we store references
into the wire bytes as pairs of offset and length.
This CL introduces a WireBytesRef struct which encapsulates these two
connected fields. This makes it easier to pass them and assign them as
one unit.
R=ahaas@chromium.org, mtrofin@chromium.org
BUG=v8:6474
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I4f2a40d848a51dc6f6f599f9253c3c6ed6e51627
Reviewed-on: https://chromium-review.googlesource.com/530687
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45859}
This is a testing-only function, which is semantically equivalent to a
SyncCompile followed by SyncInstantiate.
We add a new SyncCompileAndInstantiate function to do those two steps
in one go, and use this method instead.
For AsmJs modules, a new testing function CompileAndRunAsmWasmModule is
introduced.
This is part of our effort to reduce the number of special paths for
testing. It is connected with
https://chromium-review.googlesource.com/529210, but should not
conflict with it.
After landing both CLs, we can later also get rid of
InstantiateModuleForTesting.
R=ahaas@chromium.org, mtrofin@chromium.org
BUG=v8:6474
Change-Id: I7891e968370d5eb68803076ce2639c65a2799dcc
Reviewed-on: https://chromium-review.googlesource.com/529844
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45852}
This CL removes most occurences of "WASM" from outputs and comments in
the code. They are replaced either by "WebAssembly" or (especially in
comments) "wasm". These are the spellings officially proposed on
http://webassembly.org/.
R=ahaas@chromium.org
BUG=v8:6474
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Id39fa5e25591678263745a4eab266db546e65983
Reviewed-on: https://chromium-review.googlesource.com/529085
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45824}
- Eliminates b1x4, b1x8, and b1x16 as distinct WASM types.
- All vector comparisons return v128 type.
- Eliminates b1xN and, or, xor, not.
- Selects take a v128 mask vector and are now bit-wise.
- Adds a new test for Select, where mask is non-canonical (not 0's and -1's).
LOG=N
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2919203002
Cr-Commit-Position: refs/heads/master@{#45795}
Most prototype implementations are not fully supported in the
interpreter. This is the case at least for exception handling, simd, and
atomics. Any function can be redirected to the interpreter though,
either by passing --wasm-interpret-all, or by dynamically redirecting to
the interpreter for debugging.
Making the flags experimental keeps the fuzzer from playing around with
these flags.
Drive-by: Refactor tests which explicitly set the prototype flag to use
a new scope for that.
R=ahaas@chromium.org
BUG=chromium:727584
Change-Id: I67da79f579f1ac93c67189afef40c6524bdd4430
Reviewed-on: https://chromium-review.googlesource.com/519402
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45639}
Currently SIMD integer comparison ops are implemented using Lt/Le, this is
sub-optimal on Intel, because all compares are done using pcmpgt(d/w/b) that
clobber the destination register, and will need additional instructions to
when using Lt/Le as the base implementation. This CL proposes moving to Gt/Ge
as the underlying implementation as this will only require swapping operands
on MIPS and is consistent with x86/ARM instructions.
BUG=v8:6020
R=bbudge@chromium.org, bmeurer@chromium.org, bradnelson@chromium.org
Review-Url: https://codereview.chromium.org/2874403002
Cr-Commit-Position: refs/heads/master@{#45440}
The WebAssembly code now uses these new APIs to allocate memory with guard
regions. Guarded array buffers are no longer always external, which eliminates
a lot of special cases around WebAssembly memory.
Bug: chromium:720302
Change-Id: I355b74ac30a05a18c8b363bd256d57458742849f
Reviewed-on: https://chromium-review.googlesource.com/505715
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45436}
This makes sure that the order of exports as they appear in asm.js
modules is maintained globally (not just per function) while being
translated to a WASM module.
R=clemensh@chromium.org
TEST=mjsunit/asm/asm-validation
BUG=chromium:720586
Change-Id: I8b26d717ae2f88467d41670bced901f196c7b3fc
Reviewed-on: https://chromium-review.googlesource.com/503708
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45277}
- Currently if GrowMemory is called with pages = 0, an attempt is made to
unregister the ArrayBuffer even if it is external. Cleanup so all Detaching
of ArrayBuffer is centralized to one method, and can only be called fromJS.
- Gate creating WeakHandles to the memory on the buffer having guard pages
enabled. Currently creating a WeakHandle is gated only on if the buffer
is_external true. If a buffer is marked is_external = true to begin with,
the WeakHandle is created and the Finalizer is run causing the program to
crash.
BUG=chromium:717647
Review-Url: https://codereview.chromium.org/2867233002
Cr-Commit-Position: refs/heads/master@{#45238}
- S32x4Shuffle by decomposing into s-register moves if no patterns match.
- S16x8Shuffle, S8x16Shuffle implemented with vtbl if no patterns match.
LOG=N
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2856363003
Cr-Commit-Position: refs/heads/master@{#45210}
