std::vector can never store const types, as the stored type has to be
either copy-constructable or move-constructable.
std::vector<const X> does not compile and makes no sense if you think
about it.
Thus remove the TODO to use such a vector.
R=ahaas@chromium.org
Change-Id: Ieb00a31872f04c720d2ef90b70452c18e79f0a5d
Reviewed-on: https://chromium-review.googlesource.com/503148
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45260}
During computation of the side table, ignore stack effects of
instructions following any unconditional jump in the same block
(|unreachable|, |br|, |br_table| or |return| jump out of the block).
Without this fix, the current stack height might underflow, or we compute an
unnecessarily large max_stack_height_. Note that those instruction will
never get executed anyway.
Hence, we don't need to store any side table information for such
unreachable code.
R=rossberg@chromium.org
BUG=chromium:716936, chromium:715990
Change-Id: I282f7f18ba1b972a112210e692f6cd05cf32308c
Reviewed-on: https://chromium-review.googlesource.com/493266
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45059}
Executing the |end| opcode of a loop assumed that the stack height was
being reset to the height at start of the loop. Hence we were ignoring
the arity of the loop.
During computation of the side table, the arity of the label associated
with the loop was explicitly set to 0, such that a |br| instruction to
that label would not transfer any values.
It turns out though that we need to remember the arity in order to
precompute the correct stack height when executing the |end| opcode of
a loop.
Also, add a regression test.
R=rossberg@chromium.org
BUG=chromium:716936
Change-Id: Ib3a559998f1ce5f8fcd7b94af1426637b3e48f86
Reviewed-on: https://chromium-review.googlesource.com/493286
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45041}
This reduces the amount of special paths for testing.
Setup the memory used for testing exactly the same way as in real world.
Also, always connect the interpreter to the instance being executed,
and to the existing WasmInstance struct. This keeps information
synchronized between interpreter and test runner.
These changes allow us to execute e.g. GrowMemory from cctests either
in the interpreter or in compiled code.
R=ahaas@chromium.org
Change-Id: Id4726d061f3cdba789275350f500d769d27d2d63
Reviewed-on: https://chromium-review.googlesource.com/488561
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44966}
With fix for architectures where x<<32 != x.
Original change's description:
> [base] Introduce RoundUpToPowerOfTwo64
>
> And fix RoundUpToPowerOfTwo32 to return 1 for the input 0.
> 0 is no power of two.
> Beside being the correct value, this also avoids a special case in the
> (new) fast path using the number of leading zeros.
>
> R=jochen@chromium.org, ahaas@chromium.org
>
> Change-Id: I87173495e13b334954bcebbb55724fb666dfa809
> Reviewed-on: https://chromium-review.googlesource.com/488143
> Reviewed-by: Jochen Eisinger <jochen@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44925}
TBR=ahaas@chromium.org,jochen@chromium.org,clemensh@chromium.org,v8-reviews@googlegroups.com
Change-Id: I7b4719d84a419bb7b38e3b5c9d6d183275087ace
Reviewed-on: https://chromium-review.googlesource.com/488981
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44951}
When branching to a loop header, we were trying to copy over {arity}
values from the value stack. This is correct for block labels, but not
for loops. When branching back to a loop header, no values need to be
transferred.
R=ahaas@chromium.org
BUG=chromium:715454
Change-Id: I90d806de63d039abf8dcac1abec057860c8f69ca
Reviewed-on: https://chromium-review.googlesource.com/488146
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44949}
This reverts commit 9ceaf21272.
Reason for revert: Fails on arm: http://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20debug/builds/2950/steps/Check/logs/Bits.RoundUpToPowerOf..
Original change's description:
> [base] Introduce RoundUpToPowerOfTwo64
>
> And fix RoundUpToPowerOfTwo32 to return 1 for the input 0.
> 0 is no power of two.
> Beside being the correct value, this also avoids a special case in the
> (new) fast path using the number of leading zeros.
>
> R=jochen@chromium.org, ahaas@chromium.org
>
> Change-Id: I87173495e13b334954bcebbb55724fb666dfa809
> Reviewed-on: https://chromium-review.googlesource.com/488143
> Reviewed-by: Jochen Eisinger <jochen@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44925}
TBR=ahaas@chromium.org,jochen@chromium.org,clemensh@chromium.org,v8-reviews@googlegroups.com,wasm-v8@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: Ib353ee0a944316da6f919bac3bb88d4f95d98ea0
Reviewed-on: https://chromium-review.googlesource.com/488365
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44935}
And fix RoundUpToPowerOfTwo32 to return 1 for the input 0.
0 is no power of two.
Beside being the correct value, this also avoids a special case in the
(new) fast path using the number of leading zeros.
R=jochen@chromium.org, ahaas@chromium.org
Change-Id: I87173495e13b334954bcebbb55724fb666dfa809
Reviewed-on: https://chromium-review.googlesource.com/488143
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44925}
The interpreter used a ZoneVector<WasmVal> to model the value stack.
Thus, at each single pop to the stack, a bounds check was performed,
and the storage was potentially extended.
This CL changes this to pre-allocate enough space for the stack of a
function when a new frame is entered. This avoids any checks for pushs
and pops.
Instead of storing a ZoneVector<WasmVal>, we store WasmVal* directly.
The maximum value stack size is precomputed together with the control
transfer side table.
This CL speeds up interpreted execution by 15% on average (measured
locally on a Z840).
R=ahaas@chromium.org
BUG=v8:5822
Change-Id: If949f7ee5233d874cd6a04b7dde2d7b4a95e45ea
Reviewed-on: https://chromium-review.googlesource.com/488061
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44902}
Instead of dynamically tracking the block nesting, precompute the
information statically.
The interpreter was already using a side table to store the pc diff for
each break, conditional break and others. The information needed to
adjust the stack was tracked dynamically, however. This CL also
precomputes this information, as it is statically known.
Instead of just storing the pc diff in the side table, we now store the
pc diff, the stack height diff and the arity of the target block.
Local measurements show speedups of 5-6% on average, sometimes >10%.
R=ahaas@chromium.org
BUG=v8:5822
Change-Id: I986cfa989aabe1488f2ff79ddbfbb28aeffe1452
Reviewed-on: https://chromium-review.googlesource.com/485482
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44837}
This CL implements the proposed change to show information about
WebAssembly values and call frames via the inspector interface.
Each interpreted WebAssembly frame will have two scopes: A global scope
showing information about the memory (to be extended for globals), and
a local scope showing information about parameters, local variables, and
stack values.
Names of local variables will be added later.
R=ahaas@chromium.org, yangguo@chromium.org
BUG=v8:6245,v8:5822
Change-Id: I0a35fddd0a353933c86adf62083233b08098a2c7
Reviewed-on: https://chromium-review.googlesource.com/474865
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44633}
The local variables were parsed two times, which in fact doubled the
amount of local variables allocated for each called function.
This was costing memory and performance. As the additional local
variables were never used, we did not recognize this before.
Add a test case for locals and stack values of interpreted frames.
R=ahaas@chromium.org
BUG=v8:5822
Change-Id: Ie5cb8d8f5441edee6abb46aa6bebef4a033d582b
Reviewed-on: https://chromium-review.googlesource.com/474749
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44602}
Similar to WasmInterpreter::Thread, we now also use the pimpl idiom for
InterpretedFrame, hiding the implementation completely in the .cc file.
This allows us to store just two things per InterpretedFrameImpl: The
corresponding thread, and the frame index.
The external interface changes to always return a std::unique_ptr,
because the object layout is not known via the public interface, hence
objects cannot be stack allocated. They also cannot be copied or passed
by value.
The frame inspection interface will be tested after another fix in
https://chromium-review.googlesource.com/474749.
R=ahaas@chromium.org
BUG=v8:5822
Change-Id: I7b109da73df745fac97ec72cb0cf4f0ad71e5da9
Reviewed-on: https://chromium-review.googlesource.com/472887
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44600}
The Run() method ran in chunks of {kRunSteps} steps till completion or
breakpoint, while Step() executed exactly one step.
This CL removes the {kRunSteps} concept, and instead allows to pass the
number of steps to run to the Run() method. Step() just calls Run(1).
R=ahaas@chromium.org
BUG=chromium:708457,v8:5822
Change-Id: I03f7f4da4e0d0e72337399206f1c49ff0f1f041a
Reviewed-on: https://chromium-review.googlesource.com/469846
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44443}
In the C++ wasm interpreter, we decode LEB encoded immediates each time
we execute the respective instruction. The whole instruction sequence
was validated before, thus we know that all integers are valid.
This CL refactors several Decoder methods to allow for either checked
or unchecked decoding. In the checked case, an error is set if a check
fails, in the unchecked case, a DCHECK will fail.
This improves performance of the interpreter by 20.5%.
R=ahaas@chromium.org
BUG=v8:5822
Change-Id: If69efd4f6fbe19d84bfc2f4aa000f429a8e22bf5
Reviewed-on: https://chromium-review.googlesource.com/468786
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44406}
Make sure that we call the destructors on all embedded object by
replacing the WasmInterpreterInternals::Delete method by an actual
destructor. This way, the compiler automatically calls destructors on
all embedded objects, in particular the IdentityMap in the CodeMap.
This change also requires to release managed objects *before*
tearing down the heap, because the wasm interpreter, referenced via
Managed<>, contains global handles. When those are destroyed, the
isolate still needs to be intact.
Drive-by: Fix include guard in managed.h.
R=ahaas@chromium.org, ulan@chromium.org, mvstanton@chromium.org
BUG=v8:5822
Change-Id: I9a067f037e013c84e4d697a1e913b27c683bb529
Reviewed-on: https://chromium-review.googlesource.com/466187
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44368}
When calling imported functions, we were always using the global object
as receiver. This is incorrect for strict functions, which should have
undefined as receiver.
This CL fixes this also for the interpreter, making us pass
test/mjsunit/wasm/receiver.js with --wasm-interpret-all.
R=ahaas@chromium.org
BUG=v8:5822
TEST=test/mjsunit/wasm/receiver
Change-Id: Ib7d637083245f67b668c11540e3c3473bc167129
Reviewed-on: https://chromium-review.googlesource.com/465986
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44346}
For OOB checks on memory accesses, we first subtracted the size of the
type to load/store from the memory size, and then compared against this
effective_size. If the memory size is smaller than the size of the type,
this would lead to an integer underflow, and we would try to load the
value.
This CL fixes this, and adds a test case for this.
R=ahaas@chromium.org
BUG=v8:5822
Change-Id: I26fcba0be7343c88b8459d029b0c0af095d2466a
Reviewed-on: https://chromium-review.googlesource.com/465946
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44345}
A DCHECK was failing if we unwind an activation which is not the
bottom-most. This CL fixes this and adds a test for this.
R=ahaas@chromium.org
BUG=v8:5822
Change-Id: Ib69116b4c45a7b2a0d6cab97ad984dfdcda55918
Reviewed-on: https://chromium-review.googlesource.com/464788
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44332}
grow_memory was working from test cases, but not in combination with
compiled code. This CL makes the effect of grow_memory executed either
in the interpreter or compiled code always be reflected in both
execution environments.
It also adds a %RedirectToWasmInterpreter runtime function for testing
this interaction.
R=ahaas@chromium.orgCC=gdeepti@chromium.org
BUG=v8:5822
Change-Id: I3e7c184c42ef655d1c30d2e0dddad7fb783455fc
Reviewed-on: https://chromium-review.googlesource.com/463506
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44297}
Add a limit to the number of nested call frames in the C++ wasm
interpreter.
Both the size of the value stack as well as the size of the block stack
are limited per call frame. Thus, a limit on only the call frame stack
is enough to limit the overall memory consumption of one interpreter
instance.
R=ahaas@chromium.org
BUG=v8:5822
Change-Id: If9f7e547cd1d003bc2ae3c7586ece6b3cf3be587
Reviewed-on: https://chromium-review.googlesource.com/463486
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44296}
We were not implementing the specified ToWebAssemblyValue coercion at
all. This caused a failure on arm architectures.
R=ahaas@chromium.org
BUG=v8:5822
TEST=mjsunit/wasm/interpreter
Change-Id: Ic77cfd13007d45308bafa285d517f3820a3b1c80
Reviewed-on: https://chromium-review.googlesource.com/461859
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44185}
We were notifying the debug event listeners after every 1000 steps.
This CL fixes this to only notify them if we actually paused because of
a hit breakpoint.
R=ahaas@chromium.org
BUG=v8:5822
Change-Id: I00e36b89307c7e761ceb24ccdb3157056cfb8178
Reviewed-on: https://chromium-review.googlesource.com/459480
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44175}
This CL adds support for indirect function calls to the interpreter. It
can indirectly call other wasm function in the same instance, which are
then executed in the interpreter, or call imported functions.
Implementing this required some refactoring:
- The wasm interpreter now unwraps import wrappers on demand, instead
of unwrapping all of them on instantiation and storing a vector of
handles. This also avoids the DeferredHandleScope completely, instead
we just store two global handles in the code map.
- The interpreter gets the code table, function tables and signature
tables directly from the attached wasm instance object. This ensures
that the interpreter sees all updates to tables that might have been
performed by external code.
- There is now common functionality for calling a code object. This is
used for direct calls to imported functions and for all indirect
calls. As these code objects can also be wasm functions which should
be executed in the interpreter itself, I introduce a struct to hold
the outcome of calling the code object, or a pointer to
InterpreterCode to be called in the interpreter.
R=ahaas@chromium.org
BUG=v8:5822
Change-Id: I20fb2ea007e79e5fcff9afb4b1ca31739ebcb83f
Reviewed-on: https://chromium-review.googlesource.com/458417
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44059}
This CL makes the interpreter reentrant by allowing different
activations to be live at the same time. The wasm interpreter keeps a
list of activations and stores the stack height at the start of each
activation. This information is used to unwind just one activation, or
show the right portion of the interpreter stack for each interpreter
entry frame.
The WasmDebugInfo object stores a mapping from frame pointer (of the
interpreter entry) to the activation id in order to identify the
activation based on the physical interpreter entry frame.
R=titzer@chromium.org, ahaas@chromium.org
BUG=v8:5822
Change-Id: Ibbf93f077f907213173a92e0a2f7f3556515e8eb
Reviewed-on: https://chromium-review.googlesource.com/453958
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43976}
If an exception is thrown and the wasm interpreter entry frame is
unwound, also the internal frames in the interpreter need to be unwound.
We did not do so before, leaving a corrupted internal state of the wasm
interpreter. Thus reusing it would fail.
This CL fixes this and adds a test which reenters a previously unwound
wasm interpreter. It checks that this works and the correct stack is
returned.
This test also requires support for calling an imported function which
throws, so this change is also included here.
R=ahaas@chromium.org, titzer@chromium.org
BUG=v8:5822
Change-Id: I12fb843f7a371a4e618b4ac63ed3299667a03a82
Reviewed-on: https://chromium-review.googlesource.com/453938
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43937}
This behaviour was missing before. If a trap is encountered in the
interpreter, we now throw the right error. With test.
R=titzer@chromium.org, ahaas@chromium.org
BUG=v8:5822
Change-Id: I09c23d15fcde32ec586fb6d3094a5ec49155a9a2
Reviewed-on: https://chromium-review.googlesource.com/453839
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43859}
When instantiating the wasm interpreter for debugging, we unwrap all
wasm-to-js wrappers and store the callable objects. The handles are
stored in a DeferredHandleScope and deleted when the InterpreterHandle
(store in WasmDebugInfo) is freed.
A call to an imported function reads the arguments from the stack,
converts them to JS objects, calls the callable, converts back the
return value and pushes it onto the stack.
Reentering the interpreter from the calles JS code is not permitted
yet, but will be in a follow-up CL.
Also, indirect calls to imported functions will have to follow.
R=titzer@chromium.org, ahaas@chromium.org
BUG=v8:5822
Change-Id: I66c35053bccb6cf8d416606e4f840d888ccb3b65
Reviewed-on: https://chromium-review.googlesource.com/453838
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43855}
This is a cleanup in preparation to implement calling imported
functions via the wasm interpreter.
For imported functions, we do not create entries in the
interpreter_code_ vector any more.
I also simplified the interface and removed unused or redundant return
values. More things are now DCHECKed instead of bailing out.
Also, we previously had two PushFrame methods: One is supposed to
initialize the interpreter from external code (i.e. adds the first
frame to the stack), the other one is used to push new frames on the
frame stack for called functions. This CL renames the first to
InitFrame, and makes it use the second one. The other remaining user is
the DoCall method.
R=titzer@chromium.org
BUG=v8:5822
Change-Id: Id09ff1e3256428fbd8c955e4664507a0c3167e53
Reviewed-on: https://chromium-review.googlesource.com/453482
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43793}
Instead of storing call_pc and ret_pc, store just one pc. This
simplifies frame inspection (no distinction between top frame and other
frames). The previous ret_pc can easily be computed from the stored pc,
since we know that we must be at a indirect or direct call site when
returning to a previous frame.
It also slightly simplifies the upcoming CL to call imported functions,
which would also have to set the call_pc.
R=titzer@chromium.org, ahaas@chromium.org
BUG=v8:5822
Change-Id: I5876c09ec36450dc1474a760282fd5e41eab38be
Reviewed-on: https://chromium-review.googlesource.com/453159
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43777}
Test the wasm interpreter entry stub by creating two wasm functions A
and B, make A pass arguments to B, then redirect B to be executed in the
interpreter.
Test different number and types or arguments.
BUG=v8:5822
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2651793003
Cr-Commit-Position: refs/heads/master@{#43353}
Apparently it happens quite easily that different NaNs are produced in
the interpreter than in the execution of the compiled code. This
non-determinism caused problems for the fuzzer which compares the
equality of the results of the interpreter and the compiled code.
I decided therefore to refactor the detection of non-determinism in the
interpreter. Instead of tracking whether potentially non-deterministic
NaNs were produced, I track now whether potentially non-deterministic
NaNs could have been observed. The only way the NaN non-determinism can
be observed is by observing the non-deterministic bit pattern of the
NaN. AFAICT the only way to observe the bit pattern is with a
I(32|64)_REINTERPRET_F(32|64) instruction or with a F(32|64)_STORE
followed by a load. Therefore I flag an execution as potentially
non-deterministic when either a NaN is reinterpreted to an int, or when
a NaN is stored to memory.
R=titzer@chromium.org, eholk@chromium.org
BUG=682180
Review-Url: https://codereview.chromium.org/2671803002
Cr-Commit-Position: refs/heads/master@{#42917}
Always execute the implicit return if we fell off the function bytes.
This is not considered an additional "step" as it is not executing a
wasm instruction.
Otherwise, we might pause at an invalid position (one after the
function bytes).
R=titzer@chromium.org
BUG=v8:5822
Review-Url: https://codereview.chromium.org/2650293003
Cr-Commit-Position: refs/heads/master@{#42730}
Implement stepping by remembering the current step action in the wasm
interpreter handle in WasmDebugInfo, and using it when continuing
execution in the interpreter.
The control flow is as follows: After module compilation, the user sets
a breakpoint in wasm. The respective function is redirected to the
interpreter and the breakpoint is set on the interpreter. When it is
hit, we notify all debug event listeners, which might prepare stepping.
When returning from these listeners, before continuing execution, we
check whether stepping was requested and continue execution in the
interpreter accordingly.
Stepping from Wasm to JS and vice versa will be implemented and tested
in a follow-up CL. Testing this requires breakpoints and stepping in
Wasm to be exposed via the inspector interface, such that we can write
an inspector test. This mixed JS-Wasm-execution is hard to set up in a
cctest.
R=titzer@chromium.org, yangguo@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2649533002
Cr-Commit-Position: refs/heads/master@{#42624}
The hardcoded constant caused a problem for the wasm fuzzer because
when the maximum memory was allocated in a test case, clusterfuzz ran
out of memory. with the command line flag we can set a lower limit
for the fuzzer.
The flag has the value of the constant as its default value, so that
for everything but the fuzzers nothing should change.
R=titzer@chromium.org
BUG=chromium:676888
Review-Url: https://codereview.chromium.org/2626313003
Cr-Commit-Position: refs/heads/master@{#42599}
As required by C++11, this CL changes the zone allocator to be able to
construct and destroy arbitrary types, and accept arbitrary arguments
for construct, passing them via perfect forwarding.
I also change some push_back to emplace_back. Some of those did not
compile before.
R=ishell@chromium.org, titzer@chromium.org
Review-Url: https://codereview.chromium.org/2646873004
Cr-Commit-Position: refs/heads/master@{#42597}
Frame inspection is currently limited to locations of execution.
Further details like local variables or stack content will follow later.
The FrameInspector now stores a pointer to the interpreted wasm frame,
and redirects certain requests there, just as for deoptimized frames.
Hitting breakpoints is now also supported for wasm frames.
R=yangguo@chromium.org, titzer@chromium.org
BUG=v8:5822
Review-Url: https://codereview.chromium.org/2629823003
Cr-Commit-Position: refs/heads/master@{#42551}
Reason for revert:
compilation problems on mips
Original issue's description:
> [wasm] Fix I32ReinterpretF32 and I64ReinterpretF64 on ia32.
>
> On ia32 return statements in C++ automatically convert signalling NaNs
> to quiet NaNs, even when bit_cast is used. This CL removes all uses of
> bit_cast<float> and bit_cast<double> in the wasm compiler and wasm
> interpreter.
>
> R=titzer@chromium.org, clemensh@chromium.org
>
> Review-Url: https://codereview.chromium.org/2639353002
> Cr-Commit-Position: refs/heads/master@{#42512}
> Committed: 7739affa5bTBR=clemensh@chromium.org,titzer@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/2645693003
Cr-Commit-Position: refs/heads/master@{#42514}
On ia32 return statements in C++ automatically convert signalling NaNs
to quiet NaNs, even when bit_cast is used. This CL removes all uses of
bit_cast<float> and bit_cast<double> in the wasm compiler and wasm
interpreter.
R=titzer@chromium.org, clemensh@chromium.org
Review-Url: https://codereview.chromium.org/2639353002
Cr-Commit-Position: refs/heads/master@{#42512}
As no one will ever try to allocate a Thread directly, we can just make
Thread a proxy of ThreadImpl by reinterpret_casting between both types.
This allows to not mention ThreadImpl in the header at all, and to
define it in an anonymous namespace in the implementation, allowing for
more optimizations.
It also saves runtime, as no memory load is needed to forward from
Thread to ThreadImpl, and we do not need to allocate ThreadImpl objects
on the heap.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2643443002
Cr-Commit-Position: refs/heads/master@{#42450}
We used dynamic dispatch before, which has considerable runtime
overhead. Pimpl (a.k.a. opaque pointer) has the same memory overhead
of one additional pointer, but less runtime overhead.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2639013002
Cr-Commit-Position: refs/heads/master@{#42442}
The special treatment is not required anymore because the wasm spec
changed and NaNs do not have to be preserved anymore. In addition, it
may introduce non-determinism which confused the fuzzers.
R=titzer@chromium.org
BUG=chromium:681033
Review-Url: https://codereview.chromium.org/2630293002
Cr-Commit-Position: refs/heads/master@{#42359}
Separated:
- decoding of locals
- loop assignment analysis
- determination of opcode length
as statics that work on a Decoder. Neither need the context of a
Module, and were used in scenarios where one wasn't available either.
Changed BodyLocalDecls to match the usecases for the type. In all but
one (a printer), we want the list (in order of declaration, with
repetitions) of types of locals.
Removed a now-unnecessary constructor for the WasmFullDecoder.
BUG=
Review-Url: https://codereview.chromium.org/2610813009
Cr-Commit-Position: refs/heads/master@{#42115}
This is more renaming work to comply with the naming in the public
design repository. E.g. types are called "value types" and we no longer
refer to ASTs.
R=clemensh@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2594993002
Cr-Commit-Position: refs/heads/master@{#41891}
The current CHECK/DCHECK implementation fails statically if a signed
value is compared against an unsigned value. The common solution is to
cast on each caller, which is tedious and error-prone (might hide bugs).
This CL implements signed vs. unsigned comparisons by executing up to
two comparisons. For example, if i is int32_t and u is uint_32_t, a
DCHECK_LE(i, u) would create the check
i <= 0 || static_cast<uint32_t>(i) <= u.
For checks against constants, at least one of the checks can be removed
by compiler optimizations.
The tradeoff we have to make is to sometimes silently execute an
additional comparison. And we increase code complexity of course, even
though the usage is just as easy (or even easier) as before.
The compile time impact seems to be minimal:
I ran 3 full compilations for Optdebug on my local machine, one time on
the current ToT, one time with this CL plus http://crrev.com/2524093002.
Before: 143.72 +- 1.21 seconds
Now: 144.18 +- 0.67 seconds
In order to check that the new comparisons are working, I refactored
some DCHECKs in wasm to use the new magic, and added unit test cases.
R=ishell@chromium.org, titzer@chromium.orgCC=ahaas@chromium.org, bmeurer@chromium.org
Committed: https://crrev.com/5925074a9dab5a8577766545b91b62f2c531d3dc
Review-Url: https://codereview.chromium.org/2526783002
Cr-Original-Commit-Position: refs/heads/master@{#41275}
Cr-Commit-Position: refs/heads/master@{#41411}
These byte pointers (module_start and module_end) were only valid
during decoding. During instantiation or execution, they can get
invalidated by garbage collection.
This CL removes them from the WasmModule struct, and introduces a new
ModuleStorage struct as interface to the wasm wire bytes.
Since the storage is often needed together with the ModuleEnv, a new
ModuleStorageEnv struct holds both a ModuleEnv and a ModuleStorage.
The pointers in the ModuleStorage should never escape the live range of
this struct, as they might point into a SeqOneByteString or ArrayBuffer.
Therefore, the WasmInterpreter needs to create its own copy of the
whole module.
Runtime functions that previously used the raw pointers in WasmModule
(leading to memory errors) now have to use the SeqOneByteString in the
WasmCompiledModule.
R=titzer@chromium.org
BUG=chromium:669518
Review-Url: https://codereview.chromium.org/2540133002
Cr-Commit-Position: refs/heads/master@{#41388}
Reason for revert:
Need to revert previous CL because of Android compile error, and this one depends in it.
Original issue's description:
> [base] Define CHECK comparison for signed vs. unsigned
>
> The current CHECK/DCHECK implementation fails statically if a signed
> value is compared against an unsigned value. The common solution is to
> cast on each caller, which is tedious and error-prone (might hide bugs).
> This CL implements signed vs. unsigned comparisons by executing up to
> two comparisons. For example, if i is int32_t and u is uint_32_t, a
> DCHECK_LE(i, u) would create the check
> i <= 0 || static_cast<uint32_t>(i) <= u.
> For checks against constants, at least one of the checks can be removed
> by compiler optimizations.
>
> The tradeoff we have to make is to sometimes silently execute an
> additional comparison. And we increase code complexity of course, even
> though the usage is just as easy (or even easier) as before.
>
> The compile time impact seems to be minimal:
> I ran 3 full compilations for Optdebug on my local machine, one time on
> the current ToT, one time with this CL plus http://crrev.com/2524093002.
> Before: 143.72 +- 1.21 seconds
> Now: 144.18 +- 0.67 seconds
>
> In order to check that the new comparisons are working, I refactored
> some DCHECKs in wasm to use the new magic.
>
> R=bmeurer@chromium.org, titzer@chromium.org
>
> Committed: https://crrev.com/5925074a9dab5a8577766545b91b62f2c531d3dc
> Cr-Commit-Position: refs/heads/master@{#41275}
TBR=ishell@chromium.org,titzer@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/2531533003
Cr-Commit-Position: refs/heads/master@{#41277}
The current CHECK/DCHECK implementation fails statically if a signed
value is compared against an unsigned value. The common solution is to
cast on each caller, which is tedious and error-prone (might hide bugs).
This CL implements signed vs. unsigned comparisons by executing up to
two comparisons. For example, if i is int32_t and u is uint_32_t, a
DCHECK_LE(i, u) would create the check
i <= 0 || static_cast<uint32_t>(i) <= u.
For checks against constants, at least one of the checks can be removed
by compiler optimizations.
The tradeoff we have to make is to sometimes silently execute an
additional comparison. And we increase code complexity of course, even
though the usage is just as easy (or even easier) as before.
The compile time impact seems to be minimal:
I ran 3 full compilations for Optdebug on my local machine, one time on
the current ToT, one time with this CL plus http://crrev.com/2524093002.
Before: 143.72 +- 1.21 seconds
Now: 144.18 +- 0.67 seconds
In order to check that the new comparisons are working, I refactored
some DCHECKs in wasm to use the new magic.
R=bmeurer@chromium.org, titzer@chromium.org
Review-Url: https://codereview.chromium.org/2526783002
Cr-Commit-Position: refs/heads/master@{#41275}
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}
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 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}
[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}
According to the WebAssembly specification the alignment of load and
store instructions has to be less or equal to natural alignment.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2285643002
Cr-Commit-Position: refs/heads/master@{#39131}
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}
In the current implementation of wasm an unrepresentable input of the
float32-to-int32 conversion is detected by first truncating the input, then
converting the truncated input to int32 and back to float32, and then checking
whether the result is the same as the truncated input.
This input check does not work on arm and arm64 for an input of (INT32_MAX + 1)
because on these platforms the float32-to-int32 conversion results in INT32_MAX
if the input is greater than INT32_MAX. When INT32_MAX is converted back to
float32, then the result is (INT32_MAX + 1) again because INT32_MAX cannot be
represented precisely as float32, and rounding-to-nearest results in (INT32_MAX
+ 1). Since (INT32_MAX + 1) equals the truncated input value, the input appears
to be representable.
With the changes in this CL, the result of the float32-to-int32 conversion is
incremented by 1 if the original result was INT32_MAX. Thereby the detection of
unrepresenable inputs in wasm works. Note that since INT32_MAX cannot be
represented precisely in float32, it can also never be a valid result of the
float32-to-int32 conversion.
@v8-mips-ports, can you do a similar implementation for mips?
R=titzer@chromium.org, Rodolph.Perfetta@arm.com
Review-Url: https://codereview.chromium.org/2105313002
Cr-Commit-Position: refs/heads/master@{#37448}
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}
Cleaning up the code to replace all instances of "i++" in for loops with the more efficient "++i".
The latter foregoes an extra intermediate variable.
BUG=v8:5044
Review-Url: https://codereview.chromium.org/2094573002
Cr-Commit-Position: refs/heads/master@{#37230}
Port 481502dad9
Float32SubMinusZero and Float64SubMinusZero tests are failing because MIPS does not preserve NaN payload according to Wasm spec. Implemented macro-assembler methods that check for NaN operands, and return the qNaN value with preserved payload and sign bits.
TEST=cctest/test-run-wasm/Run_WasmFloat32SubMinusZero, cctest/test-run-wasm/Run_WasmFloat64SubMinusZero
BUG=
patch from issue 2019693002 at patchset 140001 (http://crrev.com/2019693002#ps140001)
R=ahaas@chromium.org
Review-Url: https://codereview.chromium.org/2066483008
Cr-Commit-Position: refs/heads/master@{#37105}
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}
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/2034093002
Cr-Commit-Position: refs/heads/master@{#37065}
This interpreter directly decodes and executes WASM binary code for
the purpose of supporting low-level debugging. It is not currently
integrated into the main WASM implementation.
R=ahaas@chromium.org,clemensh@chromium.org,rossberg@chromium.org,binji@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/1972153002
Cr-Commit-Position: refs/heads/master@{#36497}
