Not even when copying 0 bytes. Same for memmove and memcmp.
Bug: v8:3770
Change-Id: I3ed45a4572467ec7a9fc697ac28c004aa9b8b274
Reviewed-on: https://chromium-review.googlesource.com/c/1436217
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59101}
This switches the experimental exception handling implementation to the
new proposal where 'catch' blocks behave in a catch-all fashion and a
new 'br_on_exn' operation is used to check for a certain exception type
and extract the exception values on a match.
R=clemensh@chromium.org
TEST=unittests/FunctionBodyDecoderTest,mjsunit/wasm/exceptions
BUG=v8:8091
Change-Id: Ib12ba28b3aa2a7d831312a83abcb00bf56d0adc3
Reviewed-on: https://chromium-review.googlesource.com/c/1409431
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58832}
We often use ResultBase or VoidResult to store or pass wasm errors
(errors with locations). This CL extracts a WasmError class which can
store an error (can also be empty), and Result<T> which stores an error
or a T (exactly one of them).
R=titzer@chromium.org
Bug: v8:8689
Change-Id: I3f5203559984a0ae8757e0130a9184957fa28df5
Reviewed-on: https://chromium-review.googlesource.com/c/1409365
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58827}
This matches the terminology that is used throughout the spec.
R=clemensh@chromium.org
Change-Id: I62445e750415e6048b805110c7306f3bdbf9da60
Reviewed-on: https://chromium-review.googlesource.com/c/1408988
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58774}
The memory.init and memory.drop instructions have a data segment index
that can only be validated by knowing the number of data segments. This
information is provided by the new DataCount section.
Bug: v8:7747
Change-Id: Ie04d57584fe028637f6e931ab53d00abc5b998a4
Reviewed-on: https://chromium-review.googlesource.com/c/1355624
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58031}
This is a reland of c2aaf0a6fa
Original change's description:
> [wasm][liftoff] Optimize one-armed ifs
>
> Do not implement one-armed ifs by emulating an empty else branch. In
> Liftoff, we can generate better code and save compile time by handling
> this specially. If the merge point at the end of the if is not reached
> by the if-branch, we do not need to generate any merge code.
>
> R=titzer@chromium.org
>
> Bug: v8:6600, v8:8423
> Change-Id: Ie8ea69dd7491f225605a8e1b986d275d869aa90b
> Reviewed-on: https://chromium-review.googlesource.com/c/1356508
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57968}
Bug: v8:6600, v8:8423
Change-Id: I6d5eea9f860486768779a33bf6bd7b87cbfc2af0
Reviewed-on: https://chromium-review.googlesource.com/c/1361040
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58024}
This reverts commit c2aaf0a6fa.
Reason for revert: Benchmarks fail, and ClusterFuzz is not happy (issue 911406, issue 911271)
Original change's description:
> [wasm][liftoff] Optimize one-armed ifs
>
> Do not implement one-armed ifs by emulating an empty else branch. In
> Liftoff, we can generate better code and save compile time by handling
> this specially. If the merge point at the end of the if is not reached
> by the if-branch, we do not need to generate any merge code.
>
> R=titzer@chromium.org
>
> Bug: v8:6600, v8:8423
> Change-Id: Ie8ea69dd7491f225605a8e1b986d275d869aa90b
> Reviewed-on: https://chromium-review.googlesource.com/c/1356508
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57968}
TBR=titzer@chromium.org,clemensh@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6600, v8:8423
Change-Id: I5cb3b069f40e34f34da4013e666f6ff293752567
Reviewed-on: https://chromium-review.googlesource.com/c/1360633
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58012}
Do not implement one-armed ifs by emulating an empty else branch. In
Liftoff, we can generate better code and save compile time by handling
this specially. If the merge point at the end of the if is not reached
by the if-branch, we do not need to generate any merge code.
R=titzer@chromium.org
Bug: v8:6600, v8:8423
Change-Id: Ie8ea69dd7491f225605a8e1b986d275d869aa90b
Reviewed-on: https://chromium-review.googlesource.com/c/1356508
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57968}
The MemoryInitImmediate and TableInitImmediate read a Memory/Table
index, followed by a segment index. If reading the first index fails, we
need to stop reading, or the decoder will read past the end.
Bug: chromium:907324
Change-Id: I3eb46c08d03e3b2e44ed4081d307b32c799abcec
Reviewed-on: https://chromium-review.googlesource.com/c/1351502
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57889}
These instructions aren't implemented yet in TF or in Liftoff, but they
are properly decoded.
The table instructions (i.e. `table.{init,drop,copy}`) are validated,
since the table and element sections occur before the code section. The
memory instructions (i.e. `memory.{init,drop,copy,fill}`) are not
validated because the data section occurs after the code section, so it
can't be verified in one pass (without throwing a validation error
later).
There is currently a discussion about whether to add a new section
(similar to `func`) that predefines the number of expected data
segments. If we add this, then we can validate in one pass. For now,
we'll leave it unimplemented.
Bug: v8:7747
Change-Id: I839edf51721105a47a1fa8dd5e5e1bd855e72447
Reviewed-on: https://chromium-review.googlesource.com/c/1339241
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57622}
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}
This adds support for multiple catch blocks being attached to a single
try block. The implemented semantics are that type checks are performed
in order from top to bottom.
Note that multiple catch blocks of the same type are not prohibited and
will be accepted, making the second such block essentially unreachable.
The current proposal neither explicitly allows nor prohibits it.
R=clemensh@chromium.org
TEST=mjsunit/wasm/exceptions
BUG=v8:8091
Change-Id: I31e7a07a7cffdd909a58342e00f05e52ed1a3182
Reviewed-on: https://chromium-review.googlesource.com/c/1270591
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56478}
This adds basic support for decoding catch-all expressions as part of a
try block. Note that control flow and code generation support is still
missing.
R=clemensh@chromium.org
TEST=unittests/FunctionBodyDecoderTest.TryCatchAll
BUG=v8:8091
Change-Id: I10a1aa3e3e0418e0a04965e8318c94f449a00bb4
Reviewed-on: https://chromium-review.googlesource.com/c/1268059
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56444}
This adds experimental support for an 'except_ref' value type for caught
exceptions as per the exception handling proposal. In the current for it
is only allowed to have such types in the stack or in a local, support
for having it as part of any signature was left out.
The default value for a local of type 'except_ref' is the 'ref_null'
value for now. Since this value cannot escape a wasm function, the
concrete value is not actually observable.
R=ahaas@chromium.org
TEST=unittests/LocalDeclDecoderTest.ExceptRef,mjsunit/wasm/exceptions
BUG=v8:8091
Change-Id: I7bd65274327a833262f8749cbe0e24e737f6e0c1
Reviewed-on: https://chromium-review.googlesource.com/1196510
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55526}
This CL introduces a set of configuration options implemented as
a struct of booleans that together comprise the set of enabled
or detected features. The configuration options replace command-line
flags that were checked deep in the implementation. As such, it is
necessary to plumb them through multiple levels of abstraction.
R=ahaas@chromium.orgCC=mstarzinger@chromium.org
BUG=chromium:868844
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I1b82f5826e4fd263f68e8cafcd923bac5818a637
Reviewed-on: https://chromium-review.googlesource.com/1163670
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55018}
The instruction got removed from the proposal.
R=titzer@chromium.org
Bug: v8:7581
Change-Id: I3e27bad923544896ebf6ab8969e5c365a397f6c9
Reviewed-on: https://chromium-review.googlesource.com/1128754
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54402}
Allow the decoding of multiple tables, and allow these tables to have
any reference type. In addition, rename function-tables (in different
occurrences) to tables.
R=titzer@chromium.org
Bug: v8:7581
Change-Id: I191ea8e303b76563f9d91ae7447b373c4760d8b8
Reviewed-on: https://chromium-review.googlesource.com/1019581
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54355}
The WasmInstanceObject stores two new arrays:
- imported_mutable_globals_buffers_: a FixedArray of all the imported
globals' array buffers.
- imported_mutable_globals: a calloc'd array of Addresses pointing to
the mutable global in its array buffer.
When accessing the global, the generated code looks up the address in
imported_mutable_globals to find where to load/store.
Bug: v8:7625
Change-Id: I60844c21a788fce28f346455f10f2283d1c152e9
Reviewed-on: https://chromium-review.googlesource.com/1020602
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52794}
This CL splits the definition of ValueType and its helper functions
into its own header file.
R=clemensh@chromium.org
Bug: v8:7570
Change-Id: I3aa776edb45839d7d38836e131df45732c685310
Reviewed-on: https://chromium-review.googlesource.com/1021810
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52758}
The "Address" type is V8's general-purpose type for manipulating memory
addresses. Per the C++ spec, pointer arithmetic and pointer comparisons
are undefined behavior except within the same array; since we generally
don't operate within a C++ array, our general-purpose type shouldn't be
a pointer type.
Bug: v8:3770
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779
Reviewed-on: https://chromium-review.googlesource.com/988657
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52601}
Function names are optional in wasm and might not be present for most
functions. Instead of storing an empty name with each function, this
change loads names, if present, on first access of the name.
This also fixes an inconsistency with streaming compilation. Under
streaming compilation, functions are compiled before parsing the name
section. Hence, they always received an empty name. With this change,
assignment of names is typically deferred until the whole module was
parsed.
Bug: chromium:820291
Change-Id: I86d76aa40b7c45897d152725547795c8b6b9b9ba
Reviewed-on: https://chromium-review.googlesource.com/955647
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51909}
The problem was that parts of Simd8x16ShuffleOperand were uninitialized.
Original message:
[wasm] Stop decoding operands after error.
When we decode operands of WebAssembly instructions, we do not use the
current pc but a pc of the instruction plus some offset. However, the
pc of the instruction + offset can become invalid in case of a decoder
error. Therefore we have to stop decoding operands explicitly in case
of an error.
R=clemensh@chromium.org
Bug: chromium:795131
Change-Id: I732bc23547dbe531019d81a4397d22165a26d46b
Reviewed-on: https://chromium-review.googlesource.com/833934
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50211}
This reverts commit 6633ad56d8.
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/18850
Original change's description:
> [wasm] Stop decoding operands after error.
>
> When we decode operands of WebAssembly instructions, we do not use the
> current pc but a pc of the instruction plus some offset. However, the
> pc of the instruction + offset can become invalid in case of a decoder
> error. Therefore we have to stop decoding operands explicitly in case
> of an error.
>
> R=clemensh@chromium.org
>
> Bug: chromium:795131
> Change-Id: I3b7b45782c71a70364adf930bee3e94a1be88fea
> Reviewed-on: https://chromium-review.googlesource.com/832867
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50196}
TBR=ahaas@chromium.org,clemensh@chromium.org
Change-Id: I5a67f77285fdedc7f4645f8efaaf0087b4046011
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:795131
Reviewed-on: https://chromium-review.googlesource.com/832650
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50199}
When we decode operands of WebAssembly instructions, we do not use the
current pc but a pc of the instruction plus some offset. However, the
pc of the instruction + offset can become invalid in case of a decoder
error. Therefore we have to stop decoding operands explicitly in case
of an error.
R=clemensh@chromium.org
Bug: chromium:795131
Change-Id: I3b7b45782c71a70364adf930bee3e94a1be88fea
Reviewed-on: https://chromium-review.googlesource.com/832867
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50196}
This patch normalizes the casing of hexadecimal digits in escape
sequences of the form `\xNN` and integer literals of the form
`0xNNNN`.
Previously, the V8 code base used an inconsistent mixture of uppercase
and lowercase.
Google’s C++ style guide uses uppercase in its examples:
https://google.github.io/styleguide/cppguide.html#Non-ASCII_Characters
Moreover, uppercase letters more clearly stand out from the lowercase
`x` (or `u`) characters at the start, as well as lowercase letters
elsewhere in strings.
BUG=v8:7109
TBR=marja@chromium.org,titzer@chromium.org,mtrofin@chromium.org,mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org,mlippautz@chromium.org
NOPRESUBMIT=true
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I790e21c25d96ad5d95c8229724eb45d2aa9e22d6
Reviewed-on: https://chromium-review.googlesource.com/804294
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49810}
This CL fixes all occurences that don't require special OWNER reviews,
or can be reviewed by Michi.
After this one, we should be able to reenable the readability/check
cpplint check.
R=mstarzinger@chromium.org
Bug: v8:6837, v8:6921
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ic81d68d5534eaa795b7197fed5c41ed158361d62
Reviewed-on: https://chromium-review.googlesource.com/721120
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48670}
Calls like read_leb<int32_t, true, true, true>(...) can be hard to read
and understand. This CL replaces the three boolean template parameters
with enums so that the call is read_leb<int32_t, kChecked, kAdvancePC, kTrace>(...)
now.
R=clemensh@chromium.org
Bug: v8:6921
Change-Id: Id876a727d5e17df721444e7e5a117ad5395071aa
Reviewed-on: https://chromium-review.googlesource.com/718204
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48607}
Only change over original: Init sig_index to 0 at
function-body-decoder-impl.h:168, to make MSAN happy on error path.
R=titzer@chromium.org
Change-Id: I9ac17215360523b656b10d2466201001b65992c0
Reviewed-on: https://chromium-review.googlesource.com/712655
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Rossberg <rossberg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48463}
This is a second attempt at landing CL 644866 which was reverted by
CL 667019.
Extends the current implementation of WASM exceptions to be able to
throw exceptions with values (not just tags).
A JS typed (uint_16) array is used to hold the thrown values. This
allows all WASM types to be stored (i32, i64, f32, and f64) as well as
be inspected in JS.
The previous CL was reverted because the WASM compiler made calls to
run time functions with tagged objects, which must not be done. To fix
this, all run time calls use the thread-level isolate to hold the
exception being processed.
Bug: v8:6577
Change-Id: I4b1ef7e2847b71a2fab8e9934a0531057db9de63
Reviewed-on: https://chromium-review.googlesource.com/677056
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48148}
And add some tests for (seemingly) previously uncovered cases.
The additional check for unreachable code is not needed any more, since
polymorphic stack values get assigned a specific type on their first
use or validation anyway. Hence the first entry in the br_table will
assign specific types to all polymorphic stack values, and type checking
will fail if later entries do not match.
R=rossberg@chromium.orgCC=titzer@chromium.org
Change-Id: I1d0f91f927a2aa5186f874112e91ebffa1f1b3a7
Reviewed-on: https://chromium-review.googlesource.com/675405
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48109}
This reverts commit 7b5a40222e.
Reason for revert: GC stress-test failures exposed by 7742e534a8https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15110/steps/Mjsunit/logs/exceptions
Original change's description:
> Add capability of throwing values in WASM
>
> Extends the current implementation of WASM exceptions to be able to
> throw exceptions with values (not just tags).
>
> An JS typed array (uint_16) is used to hold thrown values, so that the
> thrown values can be inspected in JS.
>
> Bug: v8:6577
> Change-Id: I1007e79ceaffd64386b62562919cfbb920fc10c5
> Reviewed-on: https://chromium-review.googlesource.com/633866
> Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48001}
TBR=bbudge@chromium.org,mtrofin@chromium.org,eholk@chromium.org,clemensh@chromium.org,kschimpf@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6577
Change-Id: I8f545183c2d2abb1bf4a0b3ee23379f3754ffd55
Reviewed-on: https://chromium-review.googlesource.com/667019
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48050}
Extends the current implementation of WASM exceptions to be able to
throw exceptions with values (not just tags).
An JS typed array (uint_16) is used to hold thrown values, so that the
thrown values can be inspected in JS.
Bug: v8:6577
Change-Id: I1007e79ceaffd64386b62562919cfbb920fc10c5
Reviewed-on: https://chromium-review.googlesource.com/633866
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48001}
This required splitting wasm-run-utils.h in header and implementation,
since the anonymous namespace in wasm-run-utils.h is now gone.
This is a reasonable refactoring in itself.
R=titzer@chromium.orgCC=mstarzinger@chromium.org, mostynb@opera.com
Bug: chromium:746958
Change-Id: I0f3b30fef1865cd88eca37b69d0c3a9eb19e77ea
Reviewed-on: https://chromium-review.googlesource.com/647587
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47773}
This is a reland of 6b4dc039a6
Original change's description:
> [wasm] Refactor function body decoder
>
> This refactoring separates graph building from wasm decoding. The
> WasmGraphBuilder is just a consumer of the decoded information.
> Decoding without any consumer (i.e. just validation) gets 16% faster by
> this refactoring, because no TFNode* have to be stored in the value
> stack, and all dynamic tests to determine whether the graph should be
> build are gone (measured on AngryBots; before: 110.2 +- 3.3ms, after:
> 92.2 +- 3.1 ms).
>
> This new design will allow us to also attach other consumers, e.g. a
> new baseline compiler.
>
> R=titzer@chromium.org
>
> Bug: v8:6600
> Change-Id: I4b60f2409d871a16c3c52a37e515bcfb9dbb8f54
> Reviewed-on: https://chromium-review.googlesource.com/571010
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47671}
TBR=titzer@chromium.org
Bug: v8:6600
Change-Id: Idd867c5a1917437de5b6e3de5917cc1c9f194489
Reviewed-on: https://chromium-review.googlesource.com/640591
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47678}
This reverts commit 6b4dc039a6.
Reason for revert: Mips build failure: https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/11749
Original change's description:
> [wasm] Refactor function body decoder
>
> This refactoring separates graph building from wasm decoding. The
> WasmGraphBuilder is just a consumer of the decoded information.
> Decoding without any consumer (i.e. just validation) gets 16% faster by
> this refactoring, because no TFNode* have to be stored in the value
> stack, and all dynamic tests to determine whether the graph should be
> build are gone (measured on AngryBots; before: 110.2 +- 3.3ms, after:
> 92.2 +- 3.1 ms).
>
> This new design will allow us to also attach other consumers, e.g. a
> new baseline compiler.
>
> R=titzer@chromium.org
>
> Bug: v8:6600
> Change-Id: I4b60f2409d871a16c3c52a37e515bcfb9dbb8f54
> Reviewed-on: https://chromium-review.googlesource.com/571010
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47671}
TBR=titzer@chromium.org,clemensh@chromium.org
Change-Id: I76a50e355f0390cc53a2da4ceedd8830ca20a9c6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6600
Reviewed-on: https://chromium-review.googlesource.com/640870
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47672}
This refactoring separates graph building from wasm decoding. The
WasmGraphBuilder is just a consumer of the decoded information.
Decoding without any consumer (i.e. just validation) gets 16% faster by
this refactoring, because no TFNode* have to be stored in the value
stack, and all dynamic tests to determine whether the graph should be
build are gone (measured on AngryBots; before: 110.2 +- 3.3ms, after:
92.2 +- 3.1 ms).
This new design will allow us to also attach other consumers, e.g. a
new baseline compiler.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: I4b60f2409d871a16c3c52a37e515bcfb9dbb8f54
Reviewed-on: https://chromium-review.googlesource.com/571010
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47671}
