This is preparation for using TF to create builtins that handle variable number of
arguments and have to remove these arguments dynamically from the stack upon
return.
The gist of the changes:
- Added a second argument to the Return node which specifies the number of stack
slots to pop upon return in addition to those specified by the Linkage of the
compiled function.
- Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
handles all tail-call cases except where the return value type differs, this fallback
was not really useful and in fact caused unexpected behavior with variable
sized argument popping, since it wasn't possible to materialize a Return node
with the right pop count from the TailCall without additional context.
- Modified existing Return generation to pass a constant zero as the additional
pop argument since the variable pop functionality
LOG=N
Review-Url: https://codereview.chromium.org/2446543002
Cr-Commit-Position: refs/heads/master@{#40699}
Reason for revert:
Seems to break arm64 sim debug and blocks roll:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/3294
Original issue's description:
> [turbofan] Support variable size argument removal in TF-generated functions
>
> This is preparation for using TF to create builtins that handle variable number of
> arguments and have to remove these arguments dynamically from the stack upon
> return.
>
> The gist of the changes:
> - Added a second argument to the Return node which specifies the number of stack
> slots to pop upon return in addition to those specified by the Linkage of the
> compiled function.
> - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
> handles all tail-call cases except where the return value type differs, this fallback
> was not really useful and in fact caused unexpected behavior with variable
> sized argument popping, since it wasn't possible to materialize a Return node
> with the right pop count from the TailCall without additional context.
> - Modified existing Return generation to pass a constant zero as the additional
> pop argument since the variable pop functionality
>
> LOG=N
TBR=bmeurer@chromium.org,mstarzinger@chromium.org,epertoso@chromium.org,danno@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
NOPRESUBMIT=true
Review-Url: https://codereview.chromium.org/2473643002
Cr-Commit-Position: refs/heads/master@{#40691}
This is preparation for using TF to create builtins that handle variable number of
arguments and have to remove these arguments dynamically from the stack upon
return.
The gist of the changes:
- Added a second argument to the Return node which specifies the number of stack
slots to pop upon return in addition to those specified by the Linkage of the
compiled function.
- Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
handles all tail-call cases except where the return value type differs, this fallback
was not really useful and in fact caused unexpected behavior with variable
sized argument popping, since it wasn't possible to materialize a Return node
with the right pop count from the TailCall without additional context.
- Modified existing Return generation to pass a constant zero as the additional
pop argument since the variable pop functionality
LOG=N
Review-Url: https://codereview.chromium.org/2446543002
Cr-Commit-Position: refs/heads/master@{#40678}
The wasm specification does not fully specify the binary representation
of NaN: the sign bit can be non-deterministic. The wasm-code fuzzer
found a test case where the wasm interpreter and the compiled code
produce a different sign bit for a NaN, and as a consequence they
produce different results.
With this CL the interpreter tracks whether it executed an instruction
which can produce a NaN, which are div and sqrt instructions. The
fuzzer uses this information and compares the result of the interpreter
with the result of the compiled code only if there was no instruction
which could have produced a NaN.
R=titzer@chromium.org
TEST=cctest/test-run-wasm-interpreter/TestMayProduceNaN
BUG=chromium:657481
Review-Url: https://chromiumcodereview.appspot.com/2438603003
Cr-Commit-Position: refs/heads/master@{#40474}
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}
This adds more useful information to the v8-heap-stats tool.
BUG=v8:5489
Review-Url: https://codereview.chromium.org/2394213003
Cr-Commit-Position: refs/heads/master@{#40361}
Imports and exports in 0xC can be much more than functions, including
tables, memories, and globals. This CL refactors the underlying
organization of imports and exports to support these new import types.
BUG=
Committed: https://crrev.com/599f8a83420346d9cba5ff97bd2a7520468207b6
Review-Url: https://codereview.chromium.org/2390113003
Cr-Original-Commit-Position: refs/heads/master@{#40033}
Cr-Commit-Position: refs/heads/master@{#40050}
Imports and exports in 0xC can be much more than functions, including
tables, memories, and globals. This CL refactors the underlying
organization of imports and exports to support these new import types.
BUG=
Review-Url: https://codereview.chromium.org/2390113003
Cr-Commit-Position: refs/heads/master@{#40033}
[0xC] Convert to stack machine semantics.
[0xC] Use section codes instead of names.
[0xC] Add elements section decoding.
[0xC] Decoding of globals section.
[0xC] Decoding of memory section.
[0xC] Decoding of imports section.
[0xC] Decoding of exports section.
[0xC] Decoding of data section.
[0xC] Remove CallImport bytecode.
[0xC] Function bodies have an implicit block.
[0xC] Remove the bottom label from loops.
[0xC] Add signatures to blocks.
[0xC] Remove arities from branches.
Add tests for init expression decoding.
Rework compilation of import wrappers and how they are patched.
Rework function indices in debugging.
Fix ASM->WASM builder for stack machine.
Reorganize asm.js foreign functions due to import indices change.
R=ahaas@chromium.org,rossberg@chromium.org,bradnelson@chromium.org
BUG=chromium:575167
LOG=Y
Committed: https://crrev.com/76eb976a67273b8c03c744f64ad850b0432554b9
Review-Url: https://codereview.chromium.org/2345593003
Cr-Original-Commit-Position: refs/heads/master@{#39678}
Cr-Commit-Position: refs/heads/master@{#39795}
Reason for revert:
Main suspect for tsan:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/11893
Also changes layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/10036
+mips builder:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/4032
Original issue's description:
> [wasm] Master CL for Binary 0xC changes.
>
> [0xC] Convert to stack machine semantics.
> [0xC] Use section codes instead of names.
> [0xC] Add elements section decoding.
> [0xC] Decoding of globals section.
> [0xC] Decoding of memory section.
> [0xC] Decoding of imports section.
> [0xC] Decoding of exports section.
> [0xC] Decoding of data section.
> [0xC] Remove CallImport bytecode.
> [0xC] Function bodies have an implicit block.
> [0xC] Remove the bottom label from loops.
> [0xC] Add signatures to blocks.
> [0xC] Remove arities from branches.
> Add tests for init expression decoding.
> Rework compilation of import wrappers and how they are patched.
> Rework function indices in debugging.
> Fix ASM->WASM builder for stack machine.
> Reorganize asm.js foreign functions due to import indices change.
>
> R=ahaas@chromium.org,rossberg@chromium.org,bradnelson@chromium.org
> BUG=chromium:575167
> LOG=Y
>
> Committed: https://crrev.com/76eb976a67273b8c03c744f64ad850b0432554b9
> Cr-Commit-Position: refs/heads/master@{#39678}
TBR=ahaas@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org,rossberg@chromium.org,bradnelson@google.com,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:575167
Review-Url: https://codereview.chromium.org/2361053004
Cr-Commit-Position: refs/heads/master@{#39685}
[0xC] Convert to stack machine semantics.
[0xC] Use section codes instead of names.
[0xC] Add elements section decoding.
[0xC] Decoding of globals section.
[0xC] Decoding of memory section.
[0xC] Decoding of imports section.
[0xC] Decoding of exports section.
[0xC] Decoding of data section.
[0xC] Remove CallImport bytecode.
[0xC] Function bodies have an implicit block.
[0xC] Remove the bottom label from loops.
[0xC] Add signatures to blocks.
[0xC] Remove arities from branches.
Add tests for init expression decoding.
Rework compilation of import wrappers and how they are patched.
Rework function indices in debugging.
Fix ASM->WASM builder for stack machine.
Reorganize asm.js foreign functions due to import indices change.
R=ahaas@chromium.org,rossberg@chromium.org,bradnelson@chromium.org
BUG=chromium:575167
LOG=Y
Review-Url: https://codereview.chromium.org/2345593003
Cr-Commit-Position: refs/heads/master@{#39678}
This is some initial cleanup to keep /src clean. The
AccountingAllocator is actually exclusively used by zones and this
common subfolder makes that more clear.
BUG=v8:5409
Review-Url: https://codereview.chromium.org/2344143003
Cr-Commit-Position: refs/heads/master@{#39558}
test-run-wasm-module cctests broken in debug since recent refactoring changes for moving Compilation/Instantiation off the module object (https://codereview.chromium.org/2320723005). The problem here is that SetupIsolateForWasm tries to add the same property to a module_object multiple times and hits a DCHECK when this property is found on a lookup.
- Fixed to use the setup method only once when CcTest::InitIsolateOnce is used.
- Move setup method to test as this is only used for cctests/fuzzers. The install method should take care of this in the regular JS pipeline.
R=mtrofin@chromium.org, ahaas@chromium.org
Review-Url: https://codereview.chromium.org/2342263002
Cr-Commit-Position: refs/heads/master@{#39484}
Adds InterpreterCompilationJob as a sub-class of
CompilationJob, to enable off-thread bytecode
generation. Currently only used in
Interpreter::MakeBytecode.
As part of this change, CompilationJob is modified
to make it less specific to optimized compilation,
renaming the phases as follows:
- CreateGraph -> PrepareJob
- OptimizeGraph -> ExecuteJob
- GenerateCode -> FinalizeJob
RegisterWeakObjectsInOptimizedCode is also moved out
of CompilationJob and instead becomes a static function
on Compiler.
BUG=v8:5203
Committed: https://crrev.com/1fb6a7e697e8bc5b4af51647553741f966e00cdc
Committed: https://crrev.com/785990e9fc0dd9a9d963d25d0bed2909165e4ca9
Committed: https://crrev.com/d7c6195c4c5cdc080caa74dfe2ae9ecab69bea73
Review-Url: https://codereview.chromium.org/2240463002
Cr-Original-Original-Original-Commit-Position: refs/heads/master@{#38662}
Cr-Original-Original-Commit-Position: refs/heads/master@{#38668}
Cr-Original-Commit-Position: refs/heads/master@{#38725}
Cr-Commit-Position: refs/heads/master@{#38778}
Reason for revert:
Revert again...
Original issue's description:
> [Interpreter] Introduce InterpreterCompilationJob
>
> Adds InterpreterCompilationJob as a sub-class of
> CompilationJob, to enable off-thread bytecode
> generation. Currently only used in
> Interpreter::MakeBytecode.
>
> As part of this change, CompilationJob is modified
> to make it less specific to optimized compilation,
> renaming the phases as follows:
> - CreateGraph -> PrepareJob
> - OptimizeGraph -> ExecuteJob
> - GenerateCode -> FinalizeJob
>
> RegisterWeakObjectsInOptimizedCode is also moved out
> of CompilationJob and instead becomes a static function
> on Compiler.
>
> BUG=v8:5203
>
> Committed: https://crrev.com/1fb6a7e697e8bc5b4af51647553741f966e00cdc
> Committed: https://crrev.com/785990e9fc0dd9a9d963d25d0bed2909165e4ca9
> Committed: https://crrev.com/d7c6195c4c5cdc080caa74dfe2ae9ecab69bea73
> Cr-Original-Original-Commit-Position: refs/heads/master@{#38662}
> Cr-Original-Commit-Position: refs/heads/master@{#38668}
> Cr-Commit-Position: refs/heads/master@{#38725}
TBR=mstarzinger@chromium.org,jkummerow@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2260583002
Cr-Commit-Position: refs/heads/master@{#38727}
Adds InterpreterCompilationJob as a sub-class of
CompilationJob, to enable off-thread bytecode
generation. Currently only used in
Interpreter::MakeBytecode.
As part of this change, CompilationJob is modified
to make it less specific to optimized compilation,
renaming the phases as follows:
- CreateGraph -> PrepareJob
- OptimizeGraph -> ExecuteJob
- GenerateCode -> FinalizeJob
RegisterWeakObjectsInOptimizedCode is also moved out
of CompilationJob and instead becomes a static function
on Compiler.
BUG=v8:5203
Committed: https://crrev.com/1fb6a7e697e8bc5b4af51647553741f966e00cdc
Committed: https://crrev.com/785990e9fc0dd9a9d963d25d0bed2909165e4ca9
Review-Url: https://codereview.chromium.org/2240463002
Cr-Original-Original-Commit-Position: refs/heads/master@{#38662}
Cr-Original-Commit-Position: refs/heads/master@{#38668}
Cr-Commit-Position: refs/heads/master@{#38725}
Reason for revert:
Breaks Win64 bot
Original issue's description:
> [Interpreter] Introduce InterpreterCompilationJob
>
> Adds InterpreterCompilationJob as a sub-class of
> CompilationJob, to enable off-thread bytecode
> generation. Currently only used in
> Interpreter::MakeBytecode.
>
> As part of this change, CompilationJob is modified
> to make it less specific to optimized compilation,
> renaming the phases as follows:
> - CreateGraph -> PrepareJob
> - OptimizeGraph -> ExecuteJob
> - GenerateCode -> FinalizeJob
>
> RegisterWeakObjectsInOptimizedCode is also moved out
> of CompilationJob and instead becomes a static function
> on Compiler.
>
> BUG=v8:5203
>
> Committed: https://crrev.com/1fb6a7e697e8bc5b4af51647553741f966e00cdc
> Committed: https://crrev.com/785990e9fc0dd9a9d963d25d0bed2909165e4ca9
> Cr-Original-Commit-Position: refs/heads/master@{#38662}
> Cr-Commit-Position: refs/heads/master@{#38668}
TBR=mstarzinger@chromium.org,jkummerow@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2251673003
Cr-Commit-Position: refs/heads/master@{#38669}
Adds InterpreterCompilationJob as a sub-class of
CompilationJob, to enable off-thread bytecode
generation. Currently only used in
Interpreter::MakeBytecode.
As part of this change, CompilationJob is modified
to make it less specific to optimized compilation,
renaming the phases as follows:
- CreateGraph -> PrepareJob
- OptimizeGraph -> ExecuteJob
- GenerateCode -> FinalizeJob
RegisterWeakObjectsInOptimizedCode is also moved out
of CompilationJob and instead becomes a static function
on Compiler.
BUG=v8:5203
Committed: https://crrev.com/1fb6a7e697e8bc5b4af51647553741f966e00cdc
Review-Url: https://codereview.chromium.org/2240463002
Cr-Original-Commit-Position: refs/heads/master@{#38662}
Cr-Commit-Position: refs/heads/master@{#38668}
Reason for revert:
Failing on Win64 bot:
https://build.chromium.org/p/client.v8/builders/V8%20Win64/builds/12061/steps/Check/logs/regress-635429
Original issue's description:
> [Interpreter] Introduce InterpreterCompilationJob
>
> Adds InterpreterCompilationJob as a sub-class of
> CompilationJob, to enable off-thread bytecode
> generation. Currently only used in
> Interpreter::MakeBytecode.
>
> As part of this change, CompilationJob is modified
> to make it less specific to optimized compilation,
> renaming the phases as follows:
> - CreateGraph -> PrepareJob
> - OptimizeGraph -> ExecuteJob
> - GenerateCode -> FinalizeJob
>
> RegisterWeakObjectsInOptimizedCode is also moved out
> of CompilationJob and instead becomes a static function
> on Compiler.
>
> BUG=v8:5203
>
> Committed: https://crrev.com/1fb6a7e697e8bc5b4af51647553741f966e00cdc
> Cr-Commit-Position: refs/heads/master@{#38662}
TBR=mstarzinger@chromium.org,jkummerow@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2249153002
Cr-Commit-Position: refs/heads/master@{#38663}
Adds InterpreterCompilationJob as a sub-class of
CompilationJob, to enable off-thread bytecode
generation. Currently only used in
Interpreter::MakeBytecode.
As part of this change, CompilationJob is modified
to make it less specific to optimized compilation,
renaming the phases as follows:
- CreateGraph -> PrepareJob
- OptimizeGraph -> ExecuteJob
- GenerateCode -> FinalizeJob
RegisterWeakObjectsInOptimizedCode is also moved out
of CompilationJob and instead becomes a static function
on Compiler.
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2240463002
Cr-Commit-Position: refs/heads/master@{#38662}
This patch updates internal data structures used by V8 to support
multiple indirect function tables (WebAssembly/design#682). But, since
this feature is post-MVP, the functionality is not directly exposed and
parsing/generation of WebAssembly is left unchanged. Nevertheless, it
is being used in an experiment to implement fine-grained control flow
integrity based on C/C++ types.
BUG=
Review-Url: https://codereview.chromium.org/2174123002
Cr-Commit-Position: refs/heads/master@{#38110}
To correctly support instantiating a compiled module multiple times, we clone the
compiled module each time we create an instance, since some of the data is specific
to the instance - e.g. export code, wasm functions, indirect table.
BUG=v8:5072
Review-Url: https://codereview.chromium.org/2134593002
Cr-Commit-Position: refs/heads/master@{#37692}
Reland of https://codereview.chromium.org/2034093002 (reverted by
https://codereview.chromium.org/2080153002).
Original commit message:
Implement WASM support on big-endian platforms. WASM has
an implicit requirement that it is running on little-endian
machine. We achieve WASM support on BE by keeping data
in memory in little-endian order, and changing data
endianness before storing to memory and after loading from
memory.
BUG=
Review-Url: https://codereview.chromium.org/2083523002
Cr-Commit-Position: refs/heads/master@{#37373}
This reverts commit 1eb1dfabe4.
The original compilation separation change avoided associating a heap
for the wasm instance if memory was not provided, nor needed. The
grow memory CL assumed the old behavior, where a memory buffer was
always present, but may have had a zero size.
The 2CLS landed shortly after one another. We decided to treat the
grow memory as the race condition winner, so this CL here re-lands
compilation separation, plus adjusts grow memory to deal with
the undefined mem buffer.
BUG=
Review-Url: https://codereview.chromium.org/2102193003
Cr-Commit-Position: refs/heads/master@{#37352}
Support for serializing/deserializing the compiled wasm module.
We want to reuse the javascript snapshotting mechanics, at least in the
short term, when we still use the JS heap for the compiled wasm code.
Given that a module may be compiled in one v8 instance and then
instantiated later, in a different instance, whatever information we need
at instantiation time must also be serializable.
We currently hold on to the un-decoded wasm bytes, for enabling
debugging scenarios. This imposes a ~20% penalty on the memory
requirements of the wasm compiled code. We do not need this data
otherwise, for runtime, and it is sensible to consider eventually loading it
on demand. Therefore, I intentionally avoided relying on it and re-
decoding the wasm module data, and instead saved the information
necessary to support instantiation.
Given how whatever we need to persist must be serializable, the CL
uses a structure made out of serializable objects (fixed arrays mostly)
for storing this information. I preferred going this route rather than
adding more wasm-specific support to the serializer, given that we want
to eventually move off the JS heap, and therefore the serializer.
Additionally, it turns out this extra information is relatively not complex:
minimal structure, little nesting depth, mostly simple data like numbers
or byte blobs, or opaque data like compiled functions.
This CL also moves export compilation ahead of instantiation time.
This change added a helper getter to FixedArray, to make typed retrieval
of elements easier.
BUG=
Review-Url: https://codereview.chromium.org/2094563002
Cr-Commit-Position: refs/heads/master@{#37348}
Yanking out in an effort to reduce dependencies. We probably want to
separate codegen into instance-specific and module-generic purpose -
eventually.
BUG=
Review-Url: https://codereview.chromium.org/2085863003
Cr-Commit-Position: refs/heads/master@{#37126}
Reason for revert:
[Sheriff] Speculative revert for crashes on chrubuntu chromebooks:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm/builds/320
Original issue's description:
> Implement WASM big-endian support.
>
> Implement WASM support on big-endian platforms. WASM has
> an implicit requirement that it is running on little-endian
> machine. We achieve WASM support on BE by keeping data
> in memory in little-endian order, and changing data
> endianness before storing to memory and after loading from
> memory.
>
> BUG=
>
> Committed: https://crrev.com/d3f3f6c8186b2a53f0c539f7bba0c3708c4d83f9
> Cr-Commit-Position: refs/heads/master@{#37065}
TBR=titzer@chromium.org,akos.palfi@imgtec.com,balazs.kilvady@imgtec.com,jyan@ca.ibm.com,ivica.bogosavljevic@imgtec.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=
Review-Url: https://codereview.chromium.org/2080153002
Cr-Commit-Position: refs/heads/master@{#37091}
Compilation of wasm functions happens before instantiation. Imports are linked afterwards, at instantiation time. Globals and memory are also
allocated and then tied in via relocation at instantiation time.
This paves the way for implementing Wasm.compile, a prerequisite to
offering the compiled code serialization feature.
Currently, the WasmModule::Compile method just returns a fixed array
containing the code objects. More appropriate modeling of the compiled module to come.
Opportunistically centralized the logic on how to update memory
references, size, and globals, since that logic is the exact same on each
architecture, except for the actual storing of values back in the
instruction stream.
BUG=v8:5072
Review-Url: https://codereview.chromium.org/2056633002
Cr-Commit-Position: refs/heads/master@{#37086}
