In the degenerate case where we wanted to emit {x = x - x} (where {x}
is any register), ia32 and x64 generated wrong code (producing {-x + -x}
instead). Fix this by special casing this case.
R=ahaas@chromium.org
Bug: chromium:919308
Change-Id: I9cd9818d2a678450ac6530107e7a5cbb625ddb8d
Reviewed-on: https://chromium-review.googlesource.com/c/1405029
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58731}
In {Assembler::and_} we might need to use the scratch register. Thus use
a free LiftoffRegister instead to emit i32 popcnt.
R=ahaas@chromium.orgCC=george.wort@arm.com
Bug: chromium:918284
Change-Id: Ia814899bf6e33dd4989fd09329542b4bc09b48df
Reviewed-on: https://chromium-review.googlesource.com/c/1405036
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58723}
Use the right register type for the temporary register.
R=titzer@chromium.org
Bug: v8:6600, chromium:917588
Change-Id: Ia2617f6b406924ca7f496608fd495faf04dff25b
Reviewed-on: https://chromium-review.googlesource.com/c/1403127
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58711}
Since register can be used multiple times on the stack, they can also
be spilled into multiple stack slots. At merge points, we then might
have to reload the spilled slots. A DCHECK currently checks that each
register is only loaded once. Instead of failing, just load the first
stack slot, the others are statically known to contain the same value
anyways.
R=ahaas@chromium.org
Bug: v8:6600, chromium:919533
Change-Id: Ic0c806238b2997f006829b4b509a50468a55befa
Reviewed-on: https://chromium-review.googlesource.com/c/1403124
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58676}
If we have both f32 and f64 locals, we use the same register to hold
their zero value. On stack transfers, we might thus encounter the same
fp register with both the f32 and f64 type. Explicitly allow that case
to happen.
R=ahaas@chromium.org
Bug: chromium:918917, v8:6600
Change-Id: I6937008d38853fe2bdccd9715e1a2499cf6bf7c6
Reviewed-on: https://chromium-review.googlesource.com/c/1398225
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58623}
The {movsx_b} instruction can only take byte registers (or operands) as
source. Ensure that for i8 sign extensions to i64, the src register is
moved to a temporary byte register first, similar to the same operation
on i32 a few lines above.
R=ahaas@chromium.org
Bug: chromium:918149, v8:6600
Change-Id: I17bc942127baee57279a7fc0caac9d82bd7c6bfb
Reviewed-on: https://chromium-review.googlesource.com/c/1394555
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58542}
We currently de-duplicate used registers also in regions which do not
need merging. In those regions though it can never happen that we need
to pass different values from any merge input. Apart from introducing
unnecessary register moves, this also causes a DCHECK to fail, because
we might later want to merge back different registers into one.
Assume this initial stack state (where each letter is a register):
[A B B C]
If in any child block the two Bs get de-duplicated so something like
[A B D C]
then we run into trouble when merging back this state into the parent
state, because both B and D would need to be put into B.
In this case we can statically infer that B and D must hold the same
value anyway, but having this situation does not make much sense in the
first place, so the DCHECK fires correctly.
R=titzer@chromium.org
Bug: v8:8423, chromium:917412
Change-Id: I24c36b062e04a134cf7051725afab98126753f31
Reviewed-on: https://chromium-review.googlesource.com/c/1392190
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58522}
On x64 the {kScratchRegister} cannot be held in a {LiftoffRegister},
since it is not a valid cache register. Also, the code unnecessarily
checked whether there is an unused cache register, but then didn't use
it. Simplify the logic to always use the scratch register, just
distinguish between 4-byte and 8-byte moves.
On ia32 we did not move 64-bit values correctly if we didn't have
unused registers and needed to move via the stack.
R=titzer@chromium.org
Bug: v8:6600, chromium:917588, chromium:917450
Change-Id: I0bbe946c6ac8fca62f85711ae47afdac9c02ae6b
Reviewed-on: https://chromium-review.googlesource.com/c/1391755
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58521}
Identify validation fails to read the index of prefixed opcodes, and not
continue to decode the next bytes.
Change-Id: I2c737af55615ba69ba0c5f5adf18a06c6cdb951a
Bug: chromium:905815
Reviewed-on: https://chromium-review.googlesource.com/c/1390927
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58485}
Ensure that GetUnusedRegister is always called before
acquiring the scratch register in case it is needed
for spilling the value of the used register.
Bug: v8:6600, chromium:910824
Change-Id: I93ae684ad504584807dfa6227b6af14609c6bcf5
Reviewed-on: https://chromium-review.googlesource.com/c/1387498
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58442}
The source register of {movsx_b} must be a byte register.
Drive-by: Add missing sign extension opcodes to wasm-constants.js.
R=herhut@chromium.org
Bug: chromium:916869
Change-Id: I571c1ea2a0e197afefc810f306eed238250cd5e0
Reviewed-on: https://chromium-review.googlesource.com/c/1386110
Reviewed-by: Stephan Herhut <herhut@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58394}
We hit a DCHECK in the wasm graph builder because the current SSA
environment is unreachable. We were using the wrong block (the target
block) to do the reachability check.
R=titzer@chromium.org
Bug: chromium:913804
Change-Id: I4cfd3a0c696fb63903a47e4448362626a524340d
Reviewed-on: https://chromium-review.googlesource.com/c/1371566
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58150}
Fix and re-enable tests for WebAssembly's memory/constructor and
table/constructor js-api.
It introduces the '[EnforceRange] unsigned long' algorithm used
to validate initial and maximum properties.
The initial property is now required, by the switch to the Web IDL
specification. Most of the input validations errors are now considered
TypeError instead of RangeError.
The WasmTableObject and WasmMemoryObject APIs use more consistently uint32_t
to ensure integer range and remove the need for bounds checks.
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Bug: v8:8319
Change-Id: Iedd3ee6484ef688a5e96f93006eb6ca66d805a48
Reviewed-on: https://chromium-review.googlesource.com/c/1354043
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58138}
The existing implementation embedded an isolate-specific pointer to the
thread-in-wasm flag in the wrapper code. However, when the module code
is shared among multiple workers, this can mean that the workers
share the same thread-in-wasm flag.
With this change we load the pointer to the flag at runtime from the
current isolate. Thereby the correct flag is used even when the same
code is executed on different workers.
Note that we could access the right flag address by going through the
root register. However, changing the code generation to use the root
register requires some inconvenient steps:
* Pass the isolate to the pipeline again, which we don't want.
* Change the WasmCallDescriptor to allow the use of the root register
for wrappers but not for other code.
To avoid these issues, and allow the CL to be easy to merge back, we
got for the changes proposed here.
R=mstarzinger@chromium.org, ishell@chromium.org
Bug: v8:8533
Change-Id: If15565a7ad7cba835cfc1628e7a4d3fdef90a5c0
Reviewed-on: https://chromium-review.googlesource.com/c/1358518
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58044}
This CL adds new Wasm import call kinds that correspond to various
math functions that can be imported from JavaScript, such as trigonometry.
Instead of calling a special import wrapper that converts arguments
to tagged values by boxing, we can now generate calls to little WASM
stubs that contain a single WASM bytecode each.
R=mstarzinger@chromium.org
BUG=v8:8423
Change-Id: I59b1be2dd36d190a8b6c98b88c86cecc0ca7f4a2
Reviewed-on: https://chromium-review.googlesource.com/c/1349279
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57835}
With just five cache registers, Liftoff can run out of memory on a
64bit shift. This CL solves this by using a parallel register move and
pinning less registers.
R=ahaas@chromium.org
Bug: chromium:894307
Change-Id: I91ed0fee00ceb452841e5d1bb10905be6702dcce
Reviewed-on: https://chromium-review.googlesource.com/c/1337580
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57552}
The flag is on by default, so we don't need to specify it. More
importantly, the tests are expected to work for any value of that flag.
So don't force the flag but use whatever the test variant chooses.
Note that in streaming-compile.js, the flag was accidentally specified
as '-async-compilation'. I also removed that one.
R=ahaas@chromium.org
Change-Id: Ifad31160d266dda38cdd9dd1d73dad69bd2c2f2c
Reviewed-on: https://chromium-review.googlesource.com/c/1325961
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57406}
For memory limit checks, we should use the minimum of the
--wasm-max-mem-pages flag and kV8MaxWasmMemoryPages. The former is a
limit set by the user, the latter is the maximum we can handle
internally.
R=titzer@chromium.org
Bug: chromium:898677
Change-Id: I3c549f4e90dd016b5d07475d9353f30134f76dcc
Reviewed-on: https://chromium-review.googlesource.com/c/1305274
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57127}
The "grow_memory" opcode was renamed to "memory.grow", and the spec
repo was updated to use kExprMemoryGrow internally instead of
kExprGrowMemory (https://github.com/WebAssembly/spec/pull/720).
This CL does the same change for v8.
Drive-by: Rename "current_size" to "memory.size", and a minor cleanup
in wasm-graph-builder.js to bring it in line with the version in the
js-api tests in the spec repo.
R=titzer@chromium.org
Change-Id: If525dba898b2c248890a616d3392c22b45f698ef
Reviewed-on: https://chromium-review.googlesource.com/c/1302057
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57089}
On ia32, we were pinning too many registers, resulting in no unpinned
byte registers left (we only have three byte registers since {ebx}
is reserved for the root register).
It turns out that on most paths, we don't actually need to pin any
registers, since {Store} is often the last call for an operation (like
any store or set_global). If registers need to be pinned, only pass
those that must be kept alive across the {Store}. This allows to
compute a more narrow set of pinned registers on demand inside {Store}.
Plus minor drive-by changes.
R=titzer@chromium.org
Bug: chromium:894374, chromium:894307, v8:6600
Change-Id: Ic4d7131784c193dc7a2abf0e504d9973f6d5c5f1
Reviewed-on: https://chromium-review.googlesource.com/c/1275819
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56587}
Use naming similar to the spec: "table" instead of "function table",
"element segment" instead of "function table init".
Change-Id: Ib1b6cdfa566f8bd00017ccedf9440084204f10ff
Reviewed-on: https://chromium-review.googlesource.com/c/1273612
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56545}
Previously we only supported strings and not filenames. This
changes the default to filename and adds a new `type: string` which can
be passed `options` to allow for strings to be passed in test code.
See: https://developer.mozilla.org/en-US/docs/Web/API/Worker/Worker
Bug: v8:8020
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ie8818885c5c5c071b6614852322cb45aeb01a647
Reviewed-on: https://chromium-review.googlesource.com/1185980
Commit-Queue: Sam Clegg <sbc@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56056}
This verifies that asm.js over the internal parameter count limit
does not crash. The internal limit is 1000 parameters, and the test
was using >3000 parameters. Reduce this down to 1005, and also
introduce a test which does not dynamically construct the string
and eval it, because the construction of this string takes time.
Mark the old test as slow in debug mode.
R=machenbach@chromium.org
BUG=v8:8165
Change-Id: Ib6ef5e1e58d3f37a71720fb59afa19464e7f2ff7
Reviewed-on: https://chromium-review.googlesource.com/1224057
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55860}
This fixes exception creation (by the WebAssembly throw operation) so
that it is not observable by JavaScript. Internal properties are now
stored with symbol names instead of string names, which also prevents
them from being accessed or monkey-patched directly by JavaScript.
R=clemensh@chromium.org
TEST=mjsunit/regress/wasm/regress-8094
BUG=v8:8094
Change-Id: I33cb27f4373114cd4db28d9aef23560093e55242
Reviewed-on: https://chromium-review.googlesource.com/1203951
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55602}
This fixes a crash with a predicate used during stack unwinding of
WebAssembly frames during exception handling. The predicate caused an
observable side-effect in JavaScript during unwinding, code that is
inherently unhandlified and is not allowed to be observable.
The fix actually just removes the entire predicate. This is because the
updated proposal causes all JavaScript exceptions to participate in
WebAssembly exception handling, allowing modelling of "finally" language
constructs to perform cleanup independent of the embedders exception
details.
R=ahaas@chromium.org
TEST=mjsunit/regress/wasm/regress-8095
BUG=v8:8095
Change-Id: Ic03bc45e7b7f4562a431ccf910ee9ddcf558aa48
Reviewed-on: https://chromium-review.googlesource.com/1193445
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55457}
This makes sure the aforementioned predicate is independent of the
current context (aka. Realm) and only uses the instance type of the
given object to determine whether it is a WebAssembly module object.
R=titzer@chromium.org
TEST=mjsunit/regress/wasm/regress-8059
BUG=v8:8059
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Icc8e400f8412483f2a3883ca65c58b7ef938ef23
Reviewed-on: https://chromium-review.googlesource.com/1180886
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55205}
Enforce both engine limitations and spec (http://asmjs.org/spec/latest/)
limitations on the size of asm.js heaps.
R=clemensh@chromium.org
CC=mstarzinger@chromium.org
Bug: chromium:873600
Change-Id: I104c23bbd0a9a7c494f97f8f9e83ac5a37496dfd
Reviewed-on: https://chromium-review.googlesource.com/1174411
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55163}
i32 stack parameters can be loaded by Turbofan as 64-bit value, hence
they would not be zero extended. If this loaded value is then passed to
Liftoff (which assumes zero-extended i32 values), we could use it for
memory accesses, which would be out of bounds.
R=mstarzinger@chromium.org
Bug: chromium:864509, v8:6600
Change-Id: I0f45a269b1fb1c2befc2e6bc660c559a88323767
Reviewed-on: https://chromium-review.googlesource.com/1140168
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54500}
This removes an occurrence where the "%Foo" native syntax appears as part
of a string. Such strings are picked up by the fuzzer and recombined in
unsupported ways, producing false-positive crash reports. Simply avoid
having those strings in the fuzzing corpus.
R=clemensh@chromium.org
TEST=mjsunit/regress/wasm/regress-808848
BUG=chromium:844842
Change-Id: I017c1552578f0d26033e58b11353e87e27a69ebf
Reviewed-on: https://chromium-review.googlesource.com/1136300
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54432}
We need to push the sign-extended constant instead of just the lower 32
bits. Otherwise, the callee might read stale data from the stack.
Bug: chromium:854011, v8:6600
R=ahaas@chromium.orgCC=rodolph.perfetta@arm.com
Change-Id: Iafcfd6ba9532771615b41215fb4d1a2b85ce5623
Reviewed-on: https://chromium-review.googlesource.com/1124683
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54185}
This is a reland of ada648006b, fixed
for 32 bit architectures (register pairs).
Original change's description:
> [Liftoff] Fix register use count
>
> In {SetLocalFromStackSlot}, we decrement the use count of the register
> in the target slot without updating this slot, and then call
> {GetUnusedRegister}. At that point, the register use counts do not
> match the cache state, which leads to errors later on.
> This CL fixes this by marking the target slot as a stack slot after
> reducing the register use count.
>
> It also adds a Validation which helped to find that error and will
> catch similar errors earlier.
>
> R=titzer@chromium.org
>
> Bug: chromium:854050, v8:6600
> Change-Id: I74d3a5aa947ec4247d7b4557567f642bf4082316
> Reviewed-on: https://chromium-review.googlesource.com/1111958
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53976}
TBR=titzer@chromium.org
Bug: chromium:854050, v8:6600
Change-Id: Ibc8801737e9604a8490382c569b0378585625376
Reviewed-on: https://chromium-review.googlesource.com/1112238
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53981}
This reverts commit ada648006b.
Reason for revert: Failure with slow dchecks: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20debug/20982
Original change's description:
> [Liftoff] Fix register use count
>
> In {SetLocalFromStackSlot}, we decrement the use count of the register
> in the target slot without updating this slot, and then call
> {GetUnusedRegister}. At that point, the register use counts do not
> match the cache state, which leads to errors later on.
> This CL fixes this by marking the target slot as a stack slot after
> reducing the register use count.
>
> It also adds a Validation which helped to find that error and will
> catch similar errors earlier.
>
> R=titzer@chromium.org
>
> Bug: chromium:854050, v8:6600
> Change-Id: I74d3a5aa947ec4247d7b4557567f642bf4082316
> Reviewed-on: https://chromium-review.googlesource.com/1111958
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53976}
TBR=titzer@chromium.org,clemensh@chromium.org
Change-Id: I5b8d8d405dcd7f82ee431cba290419425b9859a1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:854050, v8:6600
Reviewed-on: https://chromium-review.googlesource.com/1112277
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53979}
In {SetLocalFromStackSlot}, we decrement the use count of the register
in the target slot without updating this slot, and then call
{GetUnusedRegister}. At that point, the register use counts do not
match the cache state, which leads to errors later on.
This CL fixes this by marking the target slot as a stack slot after
reducing the register use count.
It also adds a Validation which helped to find that error and will
catch similar errors earlier.
R=titzer@chromium.org
Bug: chromium:854050, v8:6600
Change-Id: I74d3a5aa947ec4247d7b4557567f642bf4082316
Reviewed-on: https://chromium-review.googlesource.com/1111958
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53976}
Cleanup decoding of flags so that invalid flags for sections other than
memory are caught correctly.
Bug: chromium:853453
Change-Id: Ia347d5f7672eee93ca3f6a743f06fba629f55cb5
Reviewed-on: https://chromium-review.googlesource.com/1104976
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53972}
This loads references to {null} values from the instance object instead
of embedding them into the generated code. It is one step towards making
the {WasmCode} objects independent of the Isolate.
Note that this also fixes an issue with the serializer/deserializer that
failed to properly serialize {null} values and accidentally collapsed
them to {undefined} values instead.
R=ahaas@chromium.org
TEST=mjsunit/regress/wasm/regress-7785
BUG=v8:7424,v8:7785
Change-Id: Ie436c2d96890e7c8c89ffe2bd4189a759254775b
Reviewed-on: https://chromium-review.googlesource.com/1070981
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53352}
At the moment, WebAssembly.instantiate(bytes) is implemented by
desugaring it to WebAssembly.compile(bytes).then(WebAssembly.instantiate).
The problem is that the {then} in this snippet is observable. With this
CL I introduce a CompilationResultResolver which allows to do the
desugaring internally and thereby make the {then} unobservable.
Unfortunately the result of WebAssembly.instantiate(bytes) is different
than the result of WebAssembly.instantiate(module). Therefore I also
introduced an InstantiationResultResolver for symmetry with
WebAssembly.compile.
R=mstarzinger@chromium.org
Bug: chromium:837417
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I2d98e03d65f2ada19041d5a9e2df5da91b24ccca
Reviewed-on: https://chromium-review.googlesource.com/1059783
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53347}
The js-to-wasm wrappers are shared across instances, so we cannot
directly call the instance-specific wasm-to-js wrappers. Instead, we
need to call via the import table.
R=titzer@chromium.org
Bug: chromium:843563
Change-Id: Ia882604f6769472fe2eb69176cbed728215ced29
Reviewed-on: https://chromium-review.googlesource.com/1064610
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53254}
The clusterfuzz issue crashes because VisitBinops expected only but 4
input operands but in the generated graph 5 input operands get created
The issue is fixed by increasing the size of the input operand buffer.
R=jarin@chromium.org
Bug: chromium:842501
Change-Id: I4bbb09a968e165e6f5a0a02d06eee97333f7aa38
Reviewed-on: https://chromium-review.googlesource.com/1056989
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53147}
This is a reland of e084eea628.
Undefined behavious was fixed in https://crrev.com/c/1051235.
Original change's description:
> Fix SourcePositionInfo for wasm
>
> In wasm we often don't have a SharedFunctionInfo associated with a
> compilation job, so we can't get a Script. Just print "unknown" in
> these cases (instead of crashing).
>
> R=titzer@chromium.org
> CC=herhut@chromium.org
>
> Bug: chromium:840757, v8:7738
> Change-Id: I850c6adfd9e07c9a0f6dd018f1a9314feb89d887
> Reviewed-on: https://chromium-review.googlesource.com/1049632
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53080}
TBR=titzer@chromium.org
Bug: chromium:840757, v8:7738
Change-Id: If04040a33766955cfed78e7c27226dd04c3f9b9f
Reviewed-on: https://chromium-review.googlesource.com/1051266
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53111}
This reverts commit e084eea628.
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20UBSanVptr/builds/3163
Original change's description:
> Fix SourcePositionInfo for wasm
>
> In wasm we often don't have a SharedFunctionInfo associated with a
> compilation job, so we can't get a Script. Just print "unknown" in
> these cases (instead of crashing).
>
> R=titzer@chromium.org
> CC=herhut@chromium.org
>
> Bug: chromium:840757, v8:7738
> Change-Id: I850c6adfd9e07c9a0f6dd018f1a9314feb89d887
> Reviewed-on: https://chromium-review.googlesource.com/1049632
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53080}
TBR=titzer@chromium.org,clemensh@chromium.org
Change-Id: Ib2020ea3f2b778df9fe50ccbe803938f2f4fd709
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:840757, v8:7738
Reviewed-on: https://chromium-review.googlesource.com/1051265
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53082}
In wasm we often don't have a SharedFunctionInfo associated with a
compilation job, so we can't get a Script. Just print "unknown" in
these cases (instead of crashing).
R=titzer@chromium.org
CC=herhut@chromium.org
Bug: chromium:840757, v8:7738
Change-Id: I850c6adfd9e07c9a0f6dd018f1a9314feb89d887
Reviewed-on: https://chromium-review.googlesource.com/1049632
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53080}
A stack overflow can be thrown by JSEntryStub, which means the
thread-in-wasm flag will not have the expected value. To accommodate
this, we now clear the flag during exceptional returns if it is set.
Bug: chromium:834624
Change-Id: I8359af79886ab98dfecc2fb39ca19118b7fa38eb
Reviewed-on: https://chromium-review.googlesource.com/1019570
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52891}
When WebAssembly.instantiate or WebAssembly.instantiateStreaming is
called in JavaScript, internally we transfrom it into
WebAssembly.compile(buffer).then(WebAssembly.instantiate). However,
modifying the prototype of WebAssembly.Module can change the result of
WebAssembly.compile(buffer). With this CL we make sure that even if the
result of WebAssembly.compile is modified, there is still no type
confusion. In the long term we have to do a refactoring and remove
this internal transformation.
R=mstarzinger@chromium.org
Bug: chromium:837417
Change-Id: I376068b8b8b01b991ec450162da6a62ae7030c62
Reviewed-on: https://chromium-review.googlesource.com/1032392
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52859}
