Inline a catch handler after each potentially throwing call. The handler
just merges values into the actual catch environment and then jumps to
the catch body.
This automatically adds support for unwind, which also uses the
"CatchAll" interface method.
Many tests can be written either with "catch" or with "catch_all".
Duplicate them to get coverage for both.
R=clemensb@chromium.org
Bug: v8:11453
Change-Id: I789ad44b8d1e496f026157d5c37a12004a8b37e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2726497
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73129}
These were prototyped and not merged into the SIMD proposal.
Bug: v8:10983
Change-Id: I5c30a0e9955ee5602e05d473f0f85be59d124205
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718761
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73080}
In https://crrev.com/c/2707170, Liftoff was changed to only store the
ValueKind instead of the ValueType, because we only need to know kind
for code emission. For debugging though, the whole type is useful.
This CL changes the debug sidetable back to store the full type, and
retrieves this information from the decoder.
R=jkummerow@chromium.org
Bug: v8:11477
Change-Id: I08a512d24cdf0955c95f3b9261d68a02a39b9b4e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720302
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73068}
This instruction is not in the final SIMD proposal.
Bug: v8:6020
Change-Id: Ifef1b3d58bf660f2d30784f587aed85f327825ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2716073
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73058}
Design doc: https://docs.google.com/document/d/1AsUCqslMUB6fLdnGq0ZoPk2kn50jIJAWAL77lKXXP5g/
Currently, wasm loop unrolling is disabled by default. We intend to
further investigate its compilation time cost and running time benefits
before enabling it.
Additional changes:
- Introduce LoopFinder::FindUnnestedLoopFromHeader() as a lightweight
loop analysis.
- Move EliminateLoopExit into LoopPeeling and expose it.
- Introduce loop_info_ field into WasmGraphBuildingInterface, fill it
up in Loop().
- Break after encountering the first loop in BuildNestedLoopExits.
- Introduce struct WasmLoopInfo. A WasmLoopInfo vector is instantiated
in ExecuteTurbofanWasmCompilation, passed to BuildGraphForWasmFunction
to be filled up by WasmGraphBuildingInterface, and then passed to
GenerateCodeForWasmFunction to be used in WasmLoopUnrollingPhase.
- Introduce WasmLoopUnrollingPhase and insert it into the wasm
compilation pipeline.
- Fix an issue where exception values were not wrapped in
WasmGraphBuilderInterface.
- Update --wasm-loop-unrolling flag description.
Bug: v8:11298
Change-Id: I4b57cf2ea8520931f60769f843ffd57b3ca6399b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697349
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73009}
The precise type is only used for validation. For code generation,
knowing the kind is more than enough. Hence, only store and pass the
ValueKind in Liftoff, and not the full ValueType.
R=manoskouk@chromium.org
Bug: v8:11477
Change-Id: Ia42c0fa419f75b508bd2f210c767b631e93d3398
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707170
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72997}
This is essentially a revert of 3 commits:
- a1d39bbaed
- 5a0938e593
- 74362ae3e2
with merge conflicts fixed.
These instructions were not merged into the SIMD proposal.
Bug: v8:11297
Change-Id: Ifffe7c61cae10fadc345d0faa1b0ba45ce74e946
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704950
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72933}
Backends do not care about the concrete type, they only need to know the
"kind" (e.g. "ref" or "i32").
In order to prepare Liftoff to use the value kind instead of the
value type for all stored data, this CL moves the kind out of the
ValueType and makes it a top-level enum.
R=manoskouk@chromium.org
Bug: v8:11477
Change-Id: I489d6c5207e6ff1b66e2afbe78a156d66df27eb3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707169
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72896}
When there are multiple nested catch blocks, the rethrow immediate
disambiguates which catch block to take the exception from. We
add a FixedArray to keep track of exceptions that are currently
in scope, and compute the mappings between rethrow/catch instructions
and the index to fetch/store the exception from/to in the FixedArray
during pre-processing.
R=clemensb@chromium.org
Bug: v8:8091
Change-Id: If55242c551f42262c790b5bf3f1543a003280623
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695388
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72768}
Same code sequence as x64.
Bug: v8:11416
Change-Id: Ibbd4cbf75e10b0ce876d42809d909868fdb86b87
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2686309
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72724}
This is a reland of a16add806d.
The fixes are adding disassembly for pcmpgtq and vpcmpgtq.
While fixing also noticed a mistake in assembler for pcmpgtq,
which flipped dst and src.
Also realized that we don't detect SSE4.2, so adding that in.
PS2 contains these changes.
Original change's description:
> [wasm-simd][ia32] Implement i64x2 signed compares
>
> The code sequence is exactly the same as x64.
>
> Bug: v8:11415
> Change-Id: I53ed2723eda29c0a250cff514372a3d45b203476
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683495
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72637}
Bug: v8:11415
Change-Id: If6a18af2d7de20ac8ad38f94b6d0220769397194
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688119
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72721}
If the exception tag does not match any of the catch blocks and there is
no catch_all block, it should be rethrown.
R=clemensb@chromium.org
Bug: v8:8091
Change-Id: I8df80f51340fc6265f5ef4308ee3b0f892ee3a90
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690599
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72713}
Following up on https://crrev.com/c/2689185, this CL significantly
simplifies the whole implementation of the stack trace capturing.
Before this CL, capturing any stack trace (for the purpose of the API or
Error.stack) would roughly work like this:
1. The CaptureStackTrace() function uses the StackFrameIterator to
walk the system stack. For each native frame it uses the
FrameSummary abstraction to get all (including potentially inlined)
frames. For each of those it appends a record consisting of six
elements to a FrameArray (this holds pointers to the actual
closures and receivers).
2. Afterwards the FrameArray is shrinked to the required size, and a
new FixedArray is allocated, and initialized with new
StackTraceFrame objects where each holds a reference to the
FrameArray, the index of the frame, and an initially uninitialized
StackFrameInfo reference. This new FixedArray is then returned from
CaptureStackTrace() and either stored on a message object or
provided to the API as v8::StackTrace.
The new approach removes a lot of the machinery in between and directly
creates a FixedArray of StackFrameInfo objects in CaptureStackTrace().
These StackFrameInfo objects are directly exposed as v8::StackFrame on
the public API, and they hold the six fields that were previously stored
flat in the FrameArray. This not only avoids a lot of copying around of
data and creation of temporary objects and handles, but most importantly
unifies and simplifies the stack frame function inside StackFrameInfo,
so you no longer need to wonder which function / object might be
responsible for a certain API.
There's still a lot of room for improvement. In particular we currently
don't cache the source position for a given StackFrameInfo (or
globally), but rather recompute it every time. This is still very fast,
significantly faster than the previous approach.
There are some notable (potentially user visible) changes:
- The CallSite#GetPosition() method now consistently returns the
Wasm module relative bytecode offset for all Wasm frames (previously
it'd return the function relative bytecode offset for non-asm.js
Wasm frames).
- The column and line numbers returned from StackFrameInfo methods are
consistently 1-based now, instead of sometimes being 0-based (Wasm)
and sometimes being 1-based (JS and asm.js Wasm). The only
potentially noticable difference is that for
CallSite#GetLineNumber() no longer returns 0 for Wasm frames, but
that was wrong and useless anyways.
- CallSite#GetThis() would sometimes return the_hole, another bug
flushed out by this CL.
The CL also contains some other not noteworthy drive-by-cleanups.
Fixed: chromium:1057211
Bug: chromium:1077657, chromium:1069425, v8:8742
Bug: chromium:1127391, chromium:1098530, chromium:981541
Change-Id: Iff12f6838a4d99080db8dd96bccc14440affc5a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689183
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72694}
In the latest spec, catch can take an exception index immediate, and
control-flow jumps to the appropriate catch handler depending on the
thrown exception.
Do this by allowing multiple jump targets for the same pc in labels and
in the control transfer map. At runtime, the unwinder will choose the
appropriate control transfer entry based on the exception tag, unpack
the exception and jump to the handler.
Enable the exception cctests that were currently disabled for the
interpreter, fix some issues and add tests for the new behaviors.
R=clemensb@chromium.org
Bug: v8:8091
Change-Id: I30cb8f9459647a7c6f7bfd9785b238a9c9e9fc10
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690587
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72661}
Also move it from post-mvp to mvp, since it is now in the proposal.
Bug: v8:11002
Change-Id: I711ee7a92e6937948c93e6028ef018188ea4c976
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676937
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72643}
This reverts commit a16add806d.
Reason for revert: Broke Win32 debug https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win32%20-%20debug/29653/overview
Original change's description:
> [wasm-simd][ia32] Implement i64x2 signed compares
>
> The code sequence is exactly the same as x64.
>
> Bug: v8:11415
> Change-Id: I53ed2723eda29c0a250cff514372a3d45b203476
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683495
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72637}
TBR=bbudge@chromium.org,zhin@chromium.org
Change-Id: Idbfc8cd0fbbff607cff76953c53d0c149b87b573
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:11415
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688074
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72640}
The code sequence is exactly the same as x64.
Bug: v8:11415
Change-Id: I53ed2723eda29c0a250cff514372a3d45b203476
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683495
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72637}
By disengaging it from 'let' which is not implemented in liftoff yet.
Bug: v8:7748
Change-Id: I191695767bf8c6153f70d509dd13ff734fe75e01
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676631
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72620}
This is a partial revert of https://crrev.com/c/2457669/.
This change is slightly longer (in code-generator-x64.cc) because we
also implement support when SSE4_2 is not supported (the reverted change
seems to assume SSE4_2, which is not always the case). This code
sequence is from https://github.com/WebAssembly/simd/pull/412.
Bug: v8:11415
Change-Id: I3eef415667b4142887cf1c449d27d19ba5bbd208
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683219
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72611}
This very large changeset adds support for RISC-V.
Bug: v8:10991
Change-Id: Ic997c94cc12bba6881bc208e66526f423dd0679c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571344
Commit-Queue: Brice Dobry <brice.dobry@futurewei.com>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72598}
Prototype these 6 instructions on arm:
- f64x2.convert_low_i32x4_s
- f64x2.convert_low_i32x4_u
- i32x4.trunc_sat_f64x2_s_zero
- i32x4.trunc_sat_f64x2_u_zero
- f32x4.demote_f64x2_zero
- f64x2.promote_low_f32x4
For all these instructions we rely on having Q registers that map to S
registers, which means we can only use q0 to q7. We fix the src/dst
to q0 arbitrarily.
Bug: v8:11265
Change-Id: Ied95f2dde9859a60fc216ed67615f80e9d795bb7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679842
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72567}
For functions with a very large stack, the debug side table repeats a
lot of information: Most values will be spilled to the stack, still
every single entry in the debug side table repeats information about
them (type, stack offset). This leads to the size of the debug side
table to be quadratic in the size of the function.
In the linked bug, the generation of the debug side table took ~400ms,
whereas Liftoff compilation alone just took 16ms.
This CL optimized the debug side table by delta-encoding the entries,
i.e. only storing stack slots that changed. This reduces the size of the
table significantly, at the cost of making lookup slower, since that now
has to search the table backwards for the last entry that had
information about a specific slot. For now, this seems like a good
compromise. If it turns out to be a problem, we could speed up the
lookup by either forcing a full dump of the stack state after N entries,
or by dynamically inserting new entries during lookup, whenever we find
that we had to search backwards more than N entries. That would speed up
subsequent lookups then.
On the reproducer in the linked bug, this change reduces the time to
generate the debug side table from ~400ms to ~120ms.
Before this CL, the debug side table has 13,314 entries with a total of
38,599,606 stack value entries. After this CL, it shrinks to 20,037
stack value entries in the 13,314 entries (average of ~1.5 instead of
~2,899).
R=thibaudm@chromium.org
Bug: chromium:1172299
Change-Id: Ie726bb82d4c6648cc9ebd130115ee7ab3d1d551b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676636
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72558}
This prototypes i32x4.widen_i8x16_s and i32x4.widen_i8x16_u for arm64.
Bug: v8:11297
Change-Id: Ib9be5086c8ea98340c9bb1980c319626d7072c1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2664994
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72537}
Implement these 6 instructions:
- f64x2.convert_low_i32x4_s
- f64x2.convert_low_i32x4_u
- i32x4.trunc_sat_f64x2_s_zero
- i32x4.trunc_sat_f64x2_u_zero
- f32x4.demote_f64x2_zero
- f64x2.promote_low_f32x4
The code sequences are exactly the same as on x64.
Needed to add some more instructions, and we don't have macro lists for
these instructions yet, so individually define them for now. We can
factor them into lists in a future change.
Bug: v8:11265
Change-Id: I606e1226201e3c5ecdc7e3f611315437e917d77c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2668913
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72535}
Instead of passing a bunch of objects and pointers to
{GenerateLiftoffDebugSideTable}, just pass the WasmCode pointer for
which the debug sidetable should be created.
This requires changing the corresponding cctests to actually compile
code, such that we can get a WasmCode pointer.
R=thibaudm@chromium.org
Bug: chromium:1172299
Change-Id: If42f06a545feb590f9c2377ce95e6214bbc6f566
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2674006
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72526}
Code sequence from https://github.com/WebAssembly/simd/pull/379, and
exactly the same as x64, with minor tweaks for
ExternalReferenceAsOperand.
Bug: v8:11002
Change-Id: Icbfdac62b21c2734ad4886b3d48f34e29f7a8222
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2664860
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72495}
We were hitting an implementation defined behavior in this instruction:
- v is clamped to uint8_t::min and uint8_t::max
- then we static_cast<int8_t>(v)
- any values that don't fit in int8_t (> 127) hits and implementation
defined behavior
We reuse base::saturated_cast here instead to avoid this undefined
behavior.
Drive-by cleanup of test cases to make the signed/unsigned cases more
explicity.
Bug: v8:11372
Change-Id: I4e92cdfb685d74bd5436ba25f1c00db49a231221
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2659501
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72491}
This is a partial revert of https://crrev.com/c/2457669 to add back
i64x2.ne and i64x2.all_true, which were accepted into the proposal
(https://github.com/WebAssembly/simd/issues/419).
This only implements it for x64 and arm64 on TurboFan, other archs and
Liftoff will come later.
Bug: v8:11347,v8:11348
Change-Id: I86934478760e3d501ecdb3ce6c9b702764cc0838
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2665005
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72489}
We are often stepping multiple times without inspecting the state
in-between. Hence, the generated debug side table is often not being
used. Instead of always generating it, we can generate it lazily on
demand, which can avoid the need to generate it at all.
R=thibaudm@chromium.org
TEST=inspector/debugger/wasm-stepping
Bug: chromium:1172299
Change-Id: I9b9ff4485d65d720d23585856b3d672925460667
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2664446
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72484}
Changes:
- Rename ObjectReferenceKnowledgs::object_must_be_data_ref to
reference_kind, introduce an enum to describe it.
- In both compilers, remove the dynamic check whether the object is an
array/struct. This is known statically. Instead, if we are checking
for a function, just check for rtt equality and exit.
- Remove is_data_ref_type(), replace it in the compilers with calls to
has_signature().
- Restructure AllocateSubRtt() to handle function rtts properly.
- Add a couple execution tests.
Bug: v8:7748
Change-Id: I46fbbfe2f2a7d29b583de0d536d71c534b98322f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661460
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72477}
This is a reland of commit 9c09c227b0.
The fix for gc stress failure is merged: https://crrev.com/c/2656857.
Original change's description:
> Bug: v8:11331
> Change-Id: Ie394ec841a1a1c4030c4f589eac2cee8a6a2a1f9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639033
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72304}
Bug: v8:11331
Change-Id: I82f57b3fe5f0c456472aa7ce404703f34b73d17e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2659511
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72465}
Changes:
- Remove an obsolete TODO from wasm-module-builder.
- Replace CHECK with gTest's EXPECT in unittests.
- Remove setting of --experimental-wasm-liftoff-extern-ref in wasm-gc.
- Test test-gc/JSAccess with Liftoff.
- Remove useless #undef's from module-decoder-unittest.
Change-Id: I11b4a3dde9683cc9c7d1eb89b1a63e1859505aad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2659063
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72455}
br_on_* instructions need a precisely typed branch target, as opposed
to being treated like regular br instructions.
Bug: v8:7748
Change-Id: Iedace79faf59d61cf2ce5ac88e633e07b5a2a43f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2655507
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72450}
