SourcePosition::InliningId() refers to a the new table DeoptimizationInputData::InliningPositions(), which provides the following data for every inlining id:
- The inlined SharedFunctionInfo as an offset into DeoptimizationInfo::LiteralArray
- The SourcePosition of the inlining. Recursively, this yields the full inlining stack.
Before the Code object is created, the same information can be found in CompilationInfo::inlined_functions().
If SourcePosition::InliningId() is SourcePosition::kNotInlined, it refers to the outer (non-inlined) function.
So every SourcePosition has full information about its inlining stack, as long as the corresponding Code object is known. The internal represenation of a source position is a positive 64bit integer.
All compilers create now appropriate source positions for inlined functions. In the case of Turbofan, this required using AstGraphBuilderWithPositions for inlined functions too. So this class is now moved to a header file.
At the moment, the additional information in source positions is only used in --trace-deopt and --code-comments. The profiler needs to be updated, at the moment it gets the correct script offsets from the deopt info, but the wrong script id from the reconstructed deopt stack, which can lead to wrong outputs. This should be resolved by making the profiler use the new inlining information for deopts.
I activated the inlined deoptimization tests in test-cpu-profiler.cc for Turbofan, changing them to a case where the deopt stack and the inlining position agree. It is currently still broken for other cases.
The following additional changes were necessary:
- The source position table (internal::SourcePositionTableBuilder etc.) supports now 64bit source positions. Encoding source positions in a single 64bit int together with the difference encoding in the source position table results in very little overhead for the inlining id, since only 12% of the source positions in Octane have a changed inlining id.
- The class HPositionInfo was effectively dead code and is now removed.
- SourcePosition has new printing and information facilities, including computing a full inlining stack.
- I had to rename compiler/source-position.{h,cc} to compiler/compiler-source-position-table.{h,cc} to avoid clashes with the new src/source-position.cc file.
- I wrote the new wrapper PodArray for ByteArray. It is a template working with any POD-type. This is used in DeoptimizationInputData::InliningPositions().
- I removed HInlinedFunctionInfo and HGraph::inlined_function_infos, because they were only used for the now obsolete Crankshaft inlining ids.
- Crankshaft managed a list of inlined functions in Lithium: LChunk::inlined_functions. This is an analog structure to CompilationInfo::inlined_functions. So I removed LChunk::inlined_functions and made Crankshaft use CompilationInfo::inlined_functions instead, because this was necessary to register the offsets into the literal array in a uniform way. This is a safe change because LChunk::inlined_functions has no other uses and the functions in CompilationInfo::inlined_functions have a strictly longer lifespan, being created earlier (in Hydrogen already).
BUG=v8:5432
Review-Url: https://codereview.chromium.org/2451853002
Cr-Commit-Position: refs/heads/master@{#40975}
In captured stack traces, all lines and columns must be 1-based.
Even though this makes things a bit ugly, we have to comply also for
wasm locations, where line and column encode function index and byte
offset (both are originally 0-based).
If we don't comply, the frontend might complain, as e.g. DevTools does.
BUG=chromium:659715
R=yangguo@chromium.org, kozyatinskiy@chromium.orgCC=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2493943002
Cr-Commit-Position: refs/heads/master@{#40971}
According to the spec data segments are allowed even if the memory size
is zero. However, if one of the data segments has a length greater than
0, then module instantiation should fail.
I also changed the exception type in LoadDataSegments to TypeError,
because that's the exception type for all exceptions which can happen
during instantiation.
R=titzer@chromium.org, rossberg@chromium.org
TEST=cctest/test-run-wasm-module/EmptyMemoryEmptyDataSegment, cctest/test-run-wasm-module/EmptyMemoryNonEmptyDataSegment
Review-Url: https://codereview.chromium.org/2483053005
Cr-Commit-Position: refs/heads/master@{#40922}
This CL moves all heap-allocated WASM data structures, both ones
that are bonafide JSObjects and ones that are FixedArrays only, into a
consistent place with consistent layout. Note that not all accessors are complete, and I haven't fully spread the new static typing goodness
to all places in the code.
R=ahaas@chromium.org,rossberg@chromium.org
CC=gdeepti@chromium.org,mtrofin@chromium.org,clemensh@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2490663002
Cr-Commit-Position: refs/heads/master@{#40913}
The bounds check in LoadDataSegment was off by one. I also improved the
error message, and fixed an issue where data was initialized even if
the bounds check failed.
In InstantiateModuleForTesting I allow instantiation of modules without
exports. This check was legacy code from the time where instantiation
and execution was still combined in a single function.
R=titzer@chromium.org, rossberg@chromium.org
TEST=cctest/test-run-wasm-module/InitDataAtTheUpperLimit
Review-Url: https://codereview.chromium.org/2486183002
Cr-Commit-Position: refs/heads/master@{#40856}
The spec defines that indirect calls in WebAssembly code should cause a
validation error if no function table exists.
The CL contains the following changes:
1) Throw a validation error for indirect calls if the function table
not exist.
2) Do not create TF nodes to throw a runtime error for indirect calls
if the function table does not exist.
3) Fix existing unit tests by creating a dummy function table.
4) Add new a new test which tests that indirect calls without function
table cause a validation error.
R=rossberg@chromium.orgCC=titzer@chromium.org
TEST=unittests/AstDecoderTest.IndirectCallsWithoutTableCrash
Review-Url: https://codereview.chromium.org/2484623002
Cr-Commit-Position: refs/heads/master@{#40852}
We handle this case specially because otherwise we would have to do
complicated overflow detection.
R=titzer@chromium.org
TEST=cctest/test-run-wasm/RunWasmCompiled_LoadMaxUint32Offset
Review-Url: https://codereview.chromium.org/2490533003
Cr-Commit-Position: refs/heads/master@{#40844}
The memory leak is fixed by calling the GC at the end of the tests. The GC collects the WasmModuleWrapper objects, which deallocates WasmModule c++ object. For the mjsunit tests the GC is already called because of the --invoke_weak_callbacks flag.
BUG=chromium:662388
Review-Url: https://codereview.chromium.org/2476643003
Cr-Commit-Position: refs/heads/master@{#40822}
Reason for revert:
Speculative revert for blocking roll:
https://codereview.chromium.org/2479233002/
Original issue's description:
> [wasm] Indirect calls without function table cause validation errors.
>
> The spec defines that indirect calls in WebAssembly code should cause a
> validation error if no function table exists.
>
> The CL contains the following changes:
> 1) Throw a validation error for indirect calls if the function table
> not exist.
> 2) Do not create TF nodes to throw a runtime error for indirect calls
> if the function table does not exist.
> 3) Fix existing unit tests by creating a dummy function table.
> 4) Add new a new test which tests that indirect calls without function
> table cause a validation error.
>
> R=rossberg@chromium.org
> CC=titzer@chromium.org
>
> TEST=unittests/AstDecoderTest.IndirectCallsWithoutTableCrash
TBR=rossberg@chromium.org,titzer@chromium.org,ahaas@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2479283002
Cr-Commit-Position: refs/heads/master@{#40811}
The spec defines that indirect calls in WebAssembly code should cause a
validation error if no function table exists.
The CL contains the following changes:
1) Throw a validation error for indirect calls if the function table
not exist.
2) Do not create TF nodes to throw a runtime error for indirect calls
if the function table does not exist.
3) Fix existing unit tests by creating a dummy function table.
4) Add new a new test which tests that indirect calls without function
table cause a validation error.
R=rossberg@chromium.orgCC=titzer@chromium.org
TEST=unittests/AstDecoderTest.IndirectCallsWithoutTableCrash
Review-Url: https://codereview.chromium.org/2484623002
Cr-Commit-Position: refs/heads/master@{#40802}
The wasm interpreter crashed because it interpreted the table of
br_table as a table of uint8, but according to the spec it is a table of
varint32. Therefore the wasm interpreter misinterpreted 0x80 0x00 as 128
and not as 0, which caused a crash.
R=tizer@chromium.org
BUG=chromium:660262
TEST=cctest/test-run-wasm/RunWasmInterpreted_Regression_660262
Review-Url: https://codereview.chromium.org/2463063002
Cr-Commit-Position: refs/heads/master@{#40708}
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}
Use sparingly!
This doesn't add any really new functionality, other than making it more
convenient to do this.
This will primarily be used to wrap a WasmModule to be referenced from a
JSObject that represents an instance. There is one WasmModule C++ object
per parsed WasmModule, so this should not be more than a handful or a few
dozen in well-behaved programs.
R=rossberg@chromium.org,mlippautz@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2409173005
Cr-Commit-Position: refs/heads/master@{#40346}
A test where the deserialization data has a header, but the
header is invalid. This is in addition to the current test
where we have empty deserialization data.
BUG=
Review-Url: https://codereview.chromium.org/2418483002
Cr-Commit-Position: refs/heads/master@{#40321}
This incorporates recent feedback:
- simpler deserialization API by dropping the std::unique_ptr.
The only purpose there was communicating to the caller that they
own the buffer, and that the deserializer won't delete it. The new
design communicates that through a naming choice.
- renamed *UncompiledBytes to *WasmWireBytes
BUG=
Review-Url: https://codereview.chromium.org/2411263004
Cr-Commit-Position: refs/heads/master@{#40238}
This is needed for the asm.js -> WASM pipeline. A single exported
function is exported as __single_function__, but we still want to see
the correct function name on the stack, so the underlying wasm function
has to carry the original name.
R=ahaas@chromium.org, titzer@chromium.org
BUG=v8:4203
Review-Url: https://codereview.chromium.org/2406133003
Cr-Commit-Position: refs/heads/master@{#40159}
Updated the deserialization API to avoid copying uncompiled
bytes.
BUG=
Review-Url: https://codereview.chromium.org/2404673002
Cr-Commit-Position: refs/heads/master@{#40108}
One step closer to the informally-agreed upon specification
that structured cloning will always succeed, meaning, if
we fail to deserialize (e.g. because version mismatch in
serialized format and v8 version), we recompile.
As part of this work, the deserializer will need to become
more resilient to invalid input data, and fail graciously
rather than CHECK-ing. This CL addresses some of that,
sufficient to unblock the current serialization tests.
Subsequent CLs will add more testing and the appropriate
fixes.
BUG=639090
Review-Url: https://codereview.chromium.org/2395793003
Cr-Commit-Position: refs/heads/master@{#40058}
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}
