With --wasm-trace-memory, both compiled code and the interpreter will
output each memory load or store. This helps to debug miscompilations in
emscripten or in V8, like the referenced bug.
R=titzer@chromium.org
Bug: chromium:718858
Change-Id: I90704d164975b11c65677f86947ab102242d5153
Reviewed-on: https://chromium-review.googlesource.com/684316
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48255}
The TypedArray.prototype[Symbol.toStringTag] getter is currently the best (and
as far as I can tell only definitely side-effect free) way to check whether an
arbitrary object is a TypedArray - either generally TypedArray or a specific
one like Uint8Array. Using the getter is thus emerging as the general pattern
to detect TypedArrays, even Node.js now adapted it starting with
https://github.com/nodejs/node/pull/15663
for the isTypedArray and isUint8Array type checks in lib/internal/util/types.js
now.
The getter returns either the string with the TypedArray subclass name
(i.e. "Uint8Array") or undefined if the receiver is not a TypedArray.
This can be implemented with a simple elements kind dispatch, instead of
checking the instance type and then loading the class name from the
constructor, which requires a loop walking up the transition tree. This
CL ports the builtin to CSA and TurboFan, and changes the logic to a
simple elements kind check. On the micro-benchmark mentioned in the
referenced bug, the time goes from
testIsArrayBufferView: 565 ms.
testIsTypedArray: 2403 ms.
testIsUint8Array: 3847 ms.
to
testIsArrayBufferView: 566 ms.
testIsTypedArray: 965 ms.
testIsUint8Array: 965 ms.
which presents an up to 4x improvement.
Bug: v8:6874
Change-Id: I9c330b4529d9631df2f052acf023c6a4fae69611
Reviewed-on: https://chromium-review.googlesource.com/695021
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48254}
- Moves leak sanitizer code to callers of OS:: Memory functions.
- Changes signature of OS::ReleasePartialRegion to be more generic,
removing the parameters that only make sense as part of VirtualMemory.
Bug: chromium:756050
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I2f1401c9b0856b2eaf36b80b5f141e935ef63e1c
Reviewed-on: https://chromium-review.googlesource.com/685741
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48250}
This improves performance of ArrayBuffer.isView by roughly 2.5x itself,
and enables optimizations across ArrayBuffer.isView calls, i.e. map
checks can be eliminated across. This was discovered in a related Node
pull request (https://github.com/nodejs/node/pull/15663).
Bug: v8:6868
Change-Id: I1d56ec385f8daa0e1d44d3bc4d6c9a5558ba4522
Reviewed-on: https://chromium-review.googlesource.com/691660
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48247}
This reverts commit 3c4bc27f13.
Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=770257
Original change's description:
> Reland "[turbofan] eagerly prune None types and deadness from the graph"
>
> This is a reland of e1cdda2512
> Original change's description:
> > [turbofan] eagerly prune None types and deadness from the graph
> >
> > In addition to using the {Dead} node to prune dead control nodes and nodes that
> > depend on them, we introduce a {DeadValue} node representing an impossible value
> > that can occur at any position in the graph. The extended {DeadCodeElimination}
> > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into
> > the effect chain when possible. The remaining uses of {DeadValue} are handled
> > in {EffectControlLinearizer}, where we always have access to the effect chain.
> > In addition to explicitly introduced {DeadValue} nodes, we consider any value use
> > of a node with type {None} as dead.
> >
> > Bug: chromium:741225
> > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655
> > Reviewed-on: https://chromium-review.googlesource.com/641250
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48208}
>
> Bug: chromium:741225
> Change-Id: I21316913dae02864f7a6d7c9269405a79f054138
> Reviewed-on: https://chromium-review.googlesource.com/692034
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48232}
TBR=jarin@chromium.org,tebbi@chromium.org
Change-Id: Ied8da411a9c8cbe4ed2e1d3e98a76162c2834c97
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:741225 chromium:770257
Reviewed-on: https://chromium-review.googlesource.com/693235
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48246}
In JS to Wasm wrappers, arguments have to be converted from JavaScript's
representation to Wasm's representation. Because of property accessors, this can
result in JavaScript or even asm.js/Wasm code being run. We were previously
setting this flag before doing the parameter conversions, and if these
conversions triggered a Wasm property getter then we would try to set the flag
twice.
With this change, we wait until after all argument conversions are done to set
the flag.
Bug: chromium:769846
R=bradnelson@chromium.org
Change-Id: Ia4b56df45619dcad69f3750bb33cacfedcaeb5b2
Reviewed-on: https://chromium-review.googlesource.com/693414
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48244}
Changing "DoubleDigitGreaterThan", which was consuming the result of a
multiplication, to "ProductGreaterThan", which performs both steps.
Bug: v8:6791
Change-Id: I7dbad350ff9b8228e11682d9691a1574ea5b0b58
Reviewed-on: https://chromium-review.googlesource.com/683614
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48243}
This reverts commit 1f99c66b56.
Reason for revert: Test timeouts on Win64 Debug: https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/19226
Original change's description:
> [wasm] always allocate memory when guard regions are needed
>
> When using trap handlers, memory references do not get any checks inserted. This
> means there is no check for a null memory as happens when the memory size is
> 0. Normally this would be correctly caught as an out of bounds access, since the
> low memory addresses are not normally mapped. However, if they were mapped for
> some reason, we would not catch the out of bounds access.
>
> The fix is to ensure WebAssembly instances always have a guard region even if
> the memory is size 0.
>
> Bug: chromium:769637
> Change-Id: I2d0f8c107563236c3780eb7746c2f820e319c65f
> Reviewed-on: https://chromium-review.googlesource.com/693137
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48240}
TBR=gdeepti@chromium.org,mtrofin@chromium.org,eholk@chromium.org
Change-Id: I4065b367c6cfffe8dd601b67cd53ad54759ae96a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:769637
Reviewed-on: https://chromium-review.googlesource.com/692918
Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48242}
based on the existing Number.parseInt.
Bug: v8:6791
Change-Id: I9169a4695807a3e435e343d239431ae7f6ccf2a1
Reviewed-on: https://chromium-review.googlesource.com/685990
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48241}
When using trap handlers, memory references do not get any checks inserted. This
means there is no check for a null memory as happens when the memory size is
0. Normally this would be correctly caught as an out of bounds access, since the
low memory addresses are not normally mapped. However, if they were mapped for
some reason, we would not catch the out of bounds access.
The fix is to ensure WebAssembly instances always have a guard region even if
the memory is size 0.
Bug: chromium:769637
Change-Id: I2d0f8c107563236c3780eb7746c2f820e319c65f
Reviewed-on: https://chromium-review.googlesource.com/693137
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48240}
It was working fine for bases 2, 4, and 16; but not for 8 and 32.
We have to take carryover from one digit to the next into account
when bits_per_character is not a divisor of kDigitBits.
Bug: v8:6791
Change-Id: Ia2cd13bdddb04b8abf1e4381e66ba4c88826fbf9
Reviewed-on: https://chromium-review.googlesource.com/685813
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48239}
Change the default to false. Block coverage will need to be
enabled explicitly via inspector protocol, which is already
being done.
R=franzih@chromium.org
Bug: v8:6738
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I08684ce7b501981bc376a6bc6181fabac9628a63
Reviewed-on: https://chromium-review.googlesource.com/689234
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48235}
And some refactoring to the existing code for LiveEdit.
R=jarin@chromium.org
Change-Id: Ic1d626db9722b39cbcd83bf6878fc24d6094e612
Reviewed-on: https://chromium-review.googlesource.com/687014
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48233}
This is a reland of e1cdda2512
Original change's description:
> [turbofan] eagerly prune None types and deadness from the graph
>
> In addition to using the {Dead} node to prune dead control nodes and nodes that
> depend on them, we introduce a {DeadValue} node representing an impossible value
> that can occur at any position in the graph. The extended {DeadCodeElimination}
> prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into
> the effect chain when possible. The remaining uses of {DeadValue} are handled
> in {EffectControlLinearizer}, where we always have access to the effect chain.
> In addition to explicitly introduced {DeadValue} nodes, we consider any value use
> of a node with type {None} as dead.
>
> Bug: chromium:741225
> Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655
> Reviewed-on: https://chromium-review.googlesource.com/641250
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48208}
Bug: chromium:741225
Change-Id: I21316913dae02864f7a6d7c9269405a79f054138
Reviewed-on: https://chromium-review.googlesource.com/692034
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48232}
We were unnecessarily storing everything as uint32_t, even though many items in
the preparsed scope data can be stored as uint8_t. This CL also adds an
(internal) API which abstracts away the actual data storing, so the backing
store can be made even more efficient (e.g., use only 1-3 bytes for some
uint32_t values, if they fit) without affecting other parts of the code.
BUG=v8:5516,chromium:762492
Change-Id: I7cd4d91dc11f87f8aec9c7584044a6f2a59b73ba
Reviewed-on: https://chromium-review.googlesource.com/684182
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48231}
Verify that both UTF-8 decoders (incremental and non-incremental one) match the
expectations.
Also cleanup / harden the UTF-8 handling code, as suggested in
https://chromium-review.googlesource.com/c/v8/v8/+/671020/ .
BUG=chromium:765608
Change-Id: I6344d62ca15b75ac8e333421c94c4aa35ab8190d
Reviewed-on: https://chromium-review.googlesource.com/681217
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48229}
We had dangling pointers by storing a raw pointer and then discarding
the unique_ptr holding it alive, and we had lots of redundant
information there.
This CL refactors the interface to take a format string and a variable
number of argument.
R=titzer@chromium.org
Change-Id: I8eb6ccd19d307e2477c97a3e5e7f537b5671a891
Reviewed-on: https://chromium-review.googlesource.com/690196
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48223}
Removes script() from CompilationInfo since it might not be created when
compiling from a background thread.
BUG=v8:5203
Change-Id: Ic36fd04cf4792336707b2d3715d47c59b6a97faf
Reviewed-on: https://chromium-review.googlesource.com/690299
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48220}
When loading a known value from a JSArray with a copy-on-write backing
store, we don't need to actually do a map check on the JSArray, but just
check that the backing store didn't change in the meantime.
R=jarin@chromium.org
Bug: v8:6816, v8:6815
Change-Id: I6764f3b8af7d4c17b9f6d2396555b584eae08176
Reviewed-on: https://chromium-review.googlesource.com/691721
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48218}
Formerly known as Opera TV.
Change-Id: If141d86e744f3ea9dc9605f6d2b35fc78d291a69
Reviewed-on: https://chromium-review.googlesource.com/683175
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@vewd.com>
Cr-Commit-Position: refs/heads/master@{#48212}
Merge better captures the upcoming usecase in the wasm native heap,
where allocating/freeing is moving the accounting of memory from
a free list to an allocated list and vice-versa - making 'Release'
an odd API when allocating.
Bug:
Change-Id: I9010959c91a1e8585eb06303ab06078132a03f60
Reviewed-on: https://chromium-review.googlesource.com/688004
Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48211}
This reverts commit e1cdda2512.
Reason for revert: Fails 'constructor-inlining' on GC-Stress bot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15270
Original change's description:
> [turbofan] eagerly prune None types and deadness from the graph
>
> In addition to using the {Dead} node to prune dead control nodes and nodes that
> depend on them, we introduce a {DeadValue} node representing an impossible value
> that can occur at any position in the graph. The extended {DeadCodeElimination}
> prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into
> the effect chain when possible. The remaining uses of {DeadValue} are handled
> in {EffectControlLinearizer}, where we always have access to the effect chain.
> In addition to explicitly introduced {DeadValue} nodes, we consider any value use
> of a node with type {None} as dead.
>
> Bug: chromium:741225
> Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655
> Reviewed-on: https://chromium-review.googlesource.com/641250
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48208}
TBR=jarin@chromium.org,tebbi@chromium.org
Change-Id: I9c175d47e2ee4b11a36ed90421202f2354610398
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:741225
Reviewed-on: https://chromium-review.googlesource.com/690080
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48210}
The WasmContext struct introduced in this CL is used to store the
mem_size and mem_start address of the wasm memory. These variables can
be accessed at C++ level at graph build time (e.g., initialized during
instance building). When the GrowMemory runtime is invoked, the context
variables can be changed in the WasmContext at C++ level so that the
generated code will load the correct values.
This requires to insert a relocatable pointer only in the
JSToWasmWrapper (and in the other wasm entry points), the value is then
passed from function to function as an automatically added additional
parameter. The WasmContext is then dropped when creating an Interpreter
Entry or when invoking a JavaScript function. This removes the need of
patching the generated code at runtime (i.e., when the memory grows)
with respect to WASM_MEMORY_REFERENCE and WASM_MEMORY_SIZE_REFERENCE.
However, we still need to patch the code at instance build time to patch
the JSToWasmWrappers; in fact the address of the WasmContext is not
known during compilation, but only when the instance is built.
The WasmContext address is passed as the first parameter. This has the
advantage of not having to move the WasmContext around if the function
does not use many registers. This CL also changes the wasm calling
convention so that the first parameter register is different from the
return value register. The WasmContext is attached to every
WasmMemoryObject, to share the same context with multiple instances
sharing the same memory. Moreover, the nodes representing the
WasmContext variables are cached in the SSA environment, similarly to
other local variables that might change during execution. The nodes are
created when initializing the SSA environment and refreshed every time a
grow_memory or a function call happens, so that we are sure that they
always represent the correct mem_size and mem_start variables.
This CL also removes the WasmMemorySize runtime (since it's now possible
to directly retrieve mem_size from the context) and simplifies the
GrowMemory runtime (since every instance now has a memory_object).
R=ahaas@chromium.org,clemensh@chromium.org
CC=gdeepti@chromium.org
Change-Id: I3f058e641284f5a1bbbfc35a64c88da6ff08e240
Reviewed-on: https://chromium-review.googlesource.com/671008
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48209}
In addition to using the {Dead} node to prune dead control nodes and nodes that
depend on them, we introduce a {DeadValue} node representing an impossible value
that can occur at any position in the graph. The extended {DeadCodeElimination}
prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into
the effect chain when possible. The remaining uses of {DeadValue} are handled
in {EffectControlLinearizer}, where we always have access to the effect chain.
In addition to explicitly introduced {DeadValue} nodes, we consider any value use
of a node with type {None} as dead.
Bug: chromium:741225
Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655
Reviewed-on: https://chromium-review.googlesource.com/641250
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48208}
