This adds the wasm instance to the module scope. The instance
contains the exported entities that can now be inspected.
Bug: chromium:1043034
Change-Id: I9236ac9c126f3bc4b1e056990fe34956bbe8ed6b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2213433
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67961}
After all struct/array definitions are parsed, we need to check if all
reference type indices are legal. We need to do it at the end because
types can be mutually recursive.
Bug: v8:7748
Change-Id: I5e6b5185e7d0c5e8d905b6833a2b9026ab630c01
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2214821
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67960}
The interpreter is not used for debugging any more. Hence any breakpoint
support and related functionality is dead code.
This CL removes
- the {SetBreakpoint} and {GetBreakpoint} methods,
- the {break_pc_} field which holds the current pause position,
- the {break_flags_} field which is used to break at function entry and
after calls,
- functions to modify {break_flags_},
- the dead {kInternalBreakpoint} and {kInvalidPc} constants (plus
respective macros and enums),
- the {orig_start} and {orig_end} fields (code is not being modified any
more, so we just use {start} and {end} now),
- the {PrepareStepIn} method,
- the unimplemented {SetTracing} method, and
- two tests that test breakpoints in the interpreter.
R=thibaudm@chromium.org
Bug: v8:10389
Change-Id: I52103c37516446e40d3dfa365d6b480a7c623577
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215163
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67958}
If multiple isolates share the same module, and the debugger gets
enabled, then we trigger tier down in each isolate separately. To avoid
generating too much code, we only recompile functions that are not
already in the right tier.
This CL is only the first step towards an actual fix. Since we only
check already installed code (and ignore compilations that are already
scheduled), we might still compile the same functions multiple times. A
second CL will make sure that only one recompilation is running at the
same time.
R=thibaudm@chromium.org
Bug: chromium:1084369, v8:10359
Change-Id: Ic4f9afac1add0fe8ad9e5d68f22d3d41ba2e52be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2213438
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67957}
This CL adds the new _WithFeedback variant of unary, binary, and
compare operation builtins. Existing logic to do these operations is
refactored s.t. it can be used by both ignition bytecode handlers and
the new builtins.
Note that the new builtins are not yet used. Follow-up CLs will hook
them into generic lowering.
Bug: v8:8888
Change-Id: Id77dbe74bdf3b3806b2aefdf1abe52c3d165a3a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208862
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67956}
This CL introduces the SyncStreamingDecoder to support
streaming compilation when --single-threaded is set. The
SyncStreamingDecoder buffers all bytes it receives over
{OnBytesReceived}, and compiles them synchronously upon {Finish}.
In addition to introducing SyncStreamingDecoder, this CL does
the following changes:
* Redirect streaming compilation to the new streaming decoder if
--no-wasm-async-compilation is set. This flag is set if
--single-threaded is set.
* Extend the test-streaming-compilation.cc tests to test also the new
streaming decoder.
R=thibaudm@chromium.org
Bug: v8:10548
Change-Id: I807e291a6060067c9835de4adf82bcb00321d995
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209053
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67955}
We can't consistently rewire the successor blocks of an unreachable node to
disconnect them from the graph when we are trying to maintain the schedule.
Instead simply leave the code there. As a future optimization we could add a
proper scheduled dead code elimination phase which can deal with this.
As a side-effect, one of the tests sees a int64 DeadValue, so add support for that
in the instruction selector.
BUG=chromium:1083272,chromium:1083763,chromium:1084953,v8:9684
Change-Id: I69a6feaeef4eae62110392e27ea848b28bccf787
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209061
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67953}
Failing to do so results in an error when generating the respective
ValueType, since the index has to be encoded in 24 bits.
Bug: v8:7748, chromium:1080444
Change-Id: Ifd1ce9744388b65f91dbd9eaeb497726c6cd207e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2214823
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67952}
This patch added an IsValid method to StartupData which returns a
boolean upon verifying a given snapshot matches the v8 version.
Embedders can use this API now to check snapshots' versions.
This was originally done by Snapshot::CheckVersion, which now simply
runs Startup::IsValid.
Bug: v8:8104
Change-Id: If555bcc55de4a05adf61798cd58d9ea8c8a71302
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2178091
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Junha Park <jpark3@scu.edu>
Cr-Commit-Position: refs/heads/master@{#67951}
This CL also fixes a small bug in the update-wasm-spec-tests.sh script,
as it was not able to handle proposals without additional core spec
tests. It also disables a lot of tests.
R=jkummerow@chromium.org
bug:v8:10556
Change-Id: Ibd885350478de935dc67edb664715cfa64f1d8e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2210248
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67949}
Sometimes CSA code carefully constructs a mask to check several
bitfields at once. Thus far, such a check has been very awkward to write
in Torque. This change adds a way to do so, using the
non-short-circuiting binary `&` operator. So now you can write an
expression that depends on several bitfields from a bitfield struct,
like `x.a == 5 & x.b & !x.c & x.d == 2` (assuming b is a one-bit value),
and it will be reduced to a single mask and equality check. To
demonstrate a usage of this new reduction, this change ports the trivial
macro IsSimpleObjectMap to Torque. I manually verified that the
generated code for the builtin SetDataProperties, which uses that macro,
is unchanged.
Bug: v8:7793
Change-Id: I4a23e0005d738a6699ea0f2a63f9fd67b01e7026
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2183276
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67948}
From 10 to 8 instructions (each). We do this by using mi (instead of lt)
and ls (instead of le), which check for strictly less than and greater
than or unordered. That way we don't have to have an extra mov for NaN.
Change-Id: I18ff876ac12b7097d73d6cbbb64de6c2a1148e43
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208934
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67947}
The proposal uses the lane shape, e.g. i64x2.anytrue, and we were using
s1x2.anytrue in our opcodes. This was a legacy naming, because we were
trying to bitpack the booleans. Now that we aren't doing that, rename
these to be more consistent with the proposal.
This was done with a straightforward sed script, changing both cpp code
and also some comments in mjsunit test files.
Bug: v8:10506
Change-Id: If077ed805de23520d8580d6b3b1906c80f67b94f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207915
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67945}
Currently, if d8 is run with the --turbo-profiling flag, it prints info
about every TurboFan-compiled function. This info includes the number of
times that each basic block in the function was run. It also includes
text representations of the function's schedule and code, so that the
person reading the output can associate counters with blocks of code.
The data about each function is currently stored in a
BasicBlockProfiler::Data instance, which is attached to a list owned by
the singleton BasicBlockProfiler. Each Data contains an
std::vector<uint32_t> which represents how many times each block in the
function has executed. The generated code for each block uses a raw
pointer into the storage of that vector to implement incrementing the
counter.
With this change, if you compile with v8_enable_builtins_profiling and
then run with --turbo-profiling, d8 will print that same info about
builtins too.
In order to generate code that can survive being serialized to a
snapshot and reloaded, this change uses counters in the JS heap instead
of a std::vector outside the JS heap. The steps for instrumentation are
as follows:
1. Between scheduling and instruction selection, add code to increment
the counter for each block. The counters array doesn't yet exist at
this point, and allocation is disallowed, so at this point the code
refers to a special marker value.
2. During finalization of the code, allocate a BasicBlockProfilingData
object on the JS heap containing data equivalent to what is stored in
BasicBlockProfiler::Data. This includes a ByteArray that is big
enough to store the counters for each block.
3. Patch the reference in the BuiltinsConstantsTableBuilder so that
instead of referring to the marker object, it now refers to this
ByteArray. Also add the BasicBlockProfilingData object to a list that
is attached to the heap roots so it can be easily accessed for
printing.
Because these steps include modifying the BuiltinsConstantsTableBuilder,
this procedure is only applicable to builtins. Runtime-generated code
still uses raw pointers into std::vector instances. In order to keep
divergence between these code paths to a minimum, most work is done
referring to instances of BasicBlockProfiler::Data (the C++ class), and
functions are provided to copy back and forth between that type and
BasicBlockProfilingData (the JS heap object).
This change is intended only to make --turbo-profiling work consistently
on more kinds of functions, but with some further work, this data could
form the basis for:
- code coverage info for fuzzers, and/or
- hot-path info for profile-guided optimization.
Bug: v8:10470, v8:9119
Change-Id: Ib556a5bc3abe67cdaa2e3ee62702a2a08b11cb61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159738
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67944}
Some non-templated uses remain until further TNodification.
Bug: v8:9708, v8:6949
Change-Id: Ica841f95a6ddfbdea78589f9db47c5b4126497f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2212263
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67943}
Rolling v8/build: 1a96233..99ffd3c
Rolling v8/buildtools: c8f5482..7a0ebcc
Rolling v8/third_party/aemu-linux-x64: wCYE7BPak_YwqYwMPrwRw1mwSyAzsuX3tth_UvhHUEUC..4xEEbuyLmLA-dGdzewQlaM2km7fPUiGEEdIQJhIK8v4C
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/503f81b..ae2ed9f
Rolling v8/third_party/depot_tools: d8c6146..8f6bfe3
Rolling v8/tools/clang: a0ee3ce..e34638cTBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com
Change-Id: I0d238afaaeec823e1be91bfe7f75e741f622e27e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208123
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#67940}
Changes:
- Implement the 'let' opcode, as per
https://github.com/WebAssembly/function-references/blob/master/proposals/function-references/Overview.md#local-bindings
- Use a WasmDecoder in place of a plain decoder in OpcodeLength and
AnalyzeLoopAssignment.
- Change ControlBase to accept an additional 'locals_count' parameter.
- Implement required test infrastructure and write some simple tests.
Bug: v8:7748
Change-Id: I39d60d1f0c26016c8f89c009dc5f4119b0c73c87
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2204107
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67937}
We would like DecodeLocals to allow inserting new locals
in any position. This is useful for the upcoming 'let' instruction.
Bug: v8:7748
Change-Id: Ic7f2a7fba0f69ee76b0ace46bb0cecee9d047306
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208859
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67936}
load_extend is now implanted on BE machines by loading
bytes and using replace_lane to add it to the desired lane.
Interpret is also fixed to write lanes in reverse.
Change-Id: I984ae6b4bd41544fbf65c702a4b5b50ba03cb261
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2210147
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67935}
Port 6b228044a9
Original Commit Message:
This is a reland of dd19a40083
Original change's description:
> [wasm-simd][liftoff][x64][ia32] Implement load extend
>
> The operations are implemented:
>
> - i16x8.load8x8_s
> - i16x8.load8x8_u
> - i32x4.load16x4_s
> - i32x4.load16x4_u
> - i64x2.load32x2_s
> - i64x2.load32x2_u
>
> on x64 and i32. The rest of the arch currently bail out, and will be
> implemented in subsequent patches.
>
> The liftoff-compiler.cc code looks very similar to the one for LoadMem,
> the only difference is special handling of kSplat v.s. kExtend. kExtend
> always loads 8 bytes, so the bounds check and tracing is different.
> Compared to LoadMem there is less need for pinning, since the result is
> always going to be in a SIMD/FP register, which is different from the
> index/addr register.
>
> The enum LoadTransformationKind was moved from
> function-body-decoder-impl.h to function-body-decoder.h so that no
> unncessary header file inclusions were needed to liftoff, and also it's
> a better place for it to live.
>
> Bug: v8:9909
> Change-Id: I926bcc01c0c3c860223e8c08f91bc4ab3b75c399
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2203730
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67914}
R=zhin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I2745871868afc1e6120197ad3ad138c89d47521e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2210764
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#67933}
The implementation of the StreamingDecoder depends on async compilation.
However, when the --single-threaded flag is set, async compilation is
not available. Therefore V8 does not support streaming compilation at
the moment if the --single-threaded flag is set.
This CL is the first step to support streaming compilation in
--single-threaded mode. This CL makes the StreamingDecoder an abstract
class, and the current implementation a sub-class called
AsyncStreamingDecoder. A follow-up CL will provided a second sub-class
implementation for streaming compilation in --single-threaded mode.
Bug: v8:10548
Change-Id: Ice5c01340d3df18f836a4a05d30571207ca8ccf6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208869
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67931}
This is a reland of dd19a40083
Original change's description:
> [wasm-simd][liftoff][x64][ia32] Implement load extend
>
> The operations are implemented:
>
> - i16x8.load8x8_s
> - i16x8.load8x8_u
> - i32x4.load16x4_s
> - i32x4.load16x4_u
> - i64x2.load32x2_s
> - i64x2.load32x2_u
>
> on x64 and i32. The rest of the arch currently bail out, and will be
> implemented in subsequent patches.
>
> The liftoff-compiler.cc code looks very similar to the one for LoadMem,
> the only difference is special handling of kSplat v.s. kExtend. kExtend
> always loads 8 bytes, so the bounds check and tracing is different.
> Compared to LoadMem there is less need for pinning, since the result is
> always going to be in a SIMD/FP register, which is different from the
> index/addr register.
>
> The enum LoadTransformationKind was moved from
> function-body-decoder-impl.h to function-body-decoder.h so that no
> unncessary header file inclusions were needed to liftoff, and also it's
> a better place for it to live.
>
> Bug: v8:9909
> Change-Id: I926bcc01c0c3c860223e8c08f91bc4ab3b75c399
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2203730
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67914}
Bug: v8:9909
Change-Id: Ic1d8dcc00d9c5af0d51100a947161eaa315b7659
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209268
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67930}
This reverts commit 611e412768.
Reason for revert: https://crbug.com/1080367
Original change's description:
> [Intl] Use new getDefaultHourCycle to replace old hack
>
> Use the ICU 67.1 new API DateTimePatternGenerator::getDefaultHourCycle
> to replace a hack which get the pattern of "jjmm" to find out the
> default hour cycle of a locale
> Bump the required API version from 65 to 67
>
> Bug: v8:10225
> Change-Id: I3378edacb6dfb8400357ac0bf3d5d50b9fe008bd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2173875
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67549}
TBR=jkummerow@chromium.org,ftang@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:10225
Change-Id: I8bdfbdfc6c906814e5a7525cbde79c9cac854bd1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208811
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67929}
Instead of skipping LAB in PagedSpaceObjectIterator, make the space
iterable by inserting a filler object into the LAB.
Bug: v8:10315
Change-Id: I6d79c309b7b8180b2a173ebd5ebdf8a893e88c4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2210234
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67928}
Math.random, while technically not having any effects which modify the
surrounding JS state, does observably change between a no-side-effects
evaluation and an actual evaluation, and can cause confusion.
Change-Id: I4a41ac6fd3153a14245d5940fe52ada43ca05e0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207805
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Gus Caplan <me@gus.host>
Cr-Commit-Position: refs/heads/master@{#67927}
This is a reland of 4482f98806
It's identical to the original CL so ..
TBR=jgruber@chromium.org,tebbi@chromium.org
Original change's description:
> [torque] Port builtins-number-gen to Torque
>
> - Ports everything except Add.
>
> Builtins generated from this CL are slightly larger, e.g. Subtract
> is 424 bytes on x64, as opposed to 400 bytes for the CSA version.
> See https://crbug.com/v8/10521
>
> Bug: v8:9891
>
> Change-Id: Id85779eb26d8e51643d8a04f0a75090bc50ef5b2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2191644
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67910}
Bug: v8:9891
Change-Id: I910c95db7bc044b2457364f4bfbbca46f0745bb9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209265
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67926}
This was introduced by https://crrev.com/c/2207137.
Load offsets can be negative.
Drive-by: Add a helper function to wrap the verbose static casts in
bounds checks.
Bug: chromium:1084872,chromium:1083450
Change-Id: I48934d04a8ab15a8fc347465064b190e32c00716
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209066
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67924}
- Undefined behavior resulted from constant 2147483648.0. Fixed by
checking for an out of range integer before casting.
Change-Id: I1c5093e546dde79babedb70fa4067756b853d206
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209266
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67923}
When we add waitAsync, void* backing_store_ is no longer sufficient,
since we cannot guarantee that the BackingStore stays alive while
we're (asynchronously) waiting.
Bug: v8:10239
Change-Id: I0e4f6049eb0c01faf216a8c6865a41c6e42be3ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208854
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67922}
There's no need for it to be a JSArray. In the spec it's a List
which roughly corresponds to FixedArray (but not JSArray).
Gotchas:
- There's no good point in time where we know the array length, since
resolving might be interleaved with iteration.
- Using ExtractFixedArray in places where we don't need to extract,
since it takes care of things like allocating the resulting array
in the right space etc.
Drive-by fix: Previously we pre-allocated an array 1 elements too big,
but never noticed it since the last element was the hole.
Bug: v8:10506
Change-Id: I6a72fbf1fc0cc031f2c8bad9314c4ed21d544a0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2202905
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67919}
Rolling v8/base/trace_event/common: dab187b..ef35868
Rolling v8/build: 1b904cc..1a96233
Rolling v8/buildtools: 204a35a..c8f5482
Rolling v8/buildtools/linux64: git_revision:5ed3c9cc67b090d5e311e4bd2aba072173e82db9..git_revision:d0a6f072070988e7b038496c4e7d6c562b649732
Rolling v8/third_party/aemu-linux-x64: 5LzaFiFYMxwWXcgus5JjF74yr90M5oz9IMo29pTdoLgC..wCYE7BPak_YwqYwMPrwRw1mwSyAzsuX3tth_UvhHUEUC
Rolling v8/third_party/android_platform: 716366f..c1f84dc
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/e9a8d37..503f81b
Rolling v8/third_party/depot_tools: 454f4ba..620c56e
Rolling v8/third_party/fuchsia-sdk: 277fe91..8ce2286
Rolling v8/third_party/zlib: 90fc47e..94df8b7
Rolling v8/tools/clang: de3e206..a0ee3ce
Rolling v8/tools/swarming_client: 160b445..7e86362TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com
Change-Id: I35d1312f952fcfea355eac2c42cf816e43fb6756
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208933
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#67916}
This reverts commit dd19a40083.
Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20debug/30448?
Original change's description:
> [wasm-simd][liftoff][x64][ia32] Implement load extend
>
> The operations are implemented:
>
> - i16x8.load8x8_s
> - i16x8.load8x8_u
> - i32x4.load16x4_s
> - i32x4.load16x4_u
> - i64x2.load32x2_s
> - i64x2.load32x2_u
>
> on x64 and i32. The rest of the arch currently bail out, and will be
> implemented in subsequent patches.
>
> The liftoff-compiler.cc code looks very similar to the one for LoadMem,
> the only difference is special handling of kSplat v.s. kExtend. kExtend
> always loads 8 bytes, so the bounds check and tracing is different.
> Compared to LoadMem there is less need for pinning, since the result is
> always going to be in a SIMD/FP register, which is different from the
> index/addr register.
>
> The enum LoadTransformationKind was moved from
> function-body-decoder-impl.h to function-body-decoder.h so that no
> unncessary header file inclusions were needed to liftoff, and also it's
> a better place for it to live.
>
> Bug: v8:9909
> Change-Id: I926bcc01c0c3c860223e8c08f91bc4ab3b75c399
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2203730
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67914}
TBR=clemensb@chromium.org,zhin@chromium.org
Change-Id: I2af6dfe6cd163d0dbc9f3a5ad4bfc5e622e76b63
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9909
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207665
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67915}
The operations are implemented:
- i16x8.load8x8_s
- i16x8.load8x8_u
- i32x4.load16x4_s
- i32x4.load16x4_u
- i64x2.load32x2_s
- i64x2.load32x2_u
on x64 and i32. The rest of the arch currently bail out, and will be
implemented in subsequent patches.
The liftoff-compiler.cc code looks very similar to the one for LoadMem,
the only difference is special handling of kSplat v.s. kExtend. kExtend
always loads 8 bytes, so the bounds check and tracing is different.
Compared to LoadMem there is less need for pinning, since the result is
always going to be in a SIMD/FP register, which is different from the
index/addr register.
The enum LoadTransformationKind was moved from
function-body-decoder-impl.h to function-body-decoder.h so that no
unncessary header file inclusions were needed to liftoff, and also it's
a better place for it to live.
Bug: v8:9909
Change-Id: I926bcc01c0c3c860223e8c08f91bc4ab3b75c399
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2203730
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67914}
For load extends, we can use Ldr, which does not require us to manually
calculate address - ld1r uses post-index, so we have to add the index
ourselves.
By checking the operation in the instruction-selector, we can set the
addressing mode for load extends to be MRR, then use Ldr in the codegen.
Bug: v8:9886
Change-Id: Ibcd22fa719cd6dafd2fd06e68066960db249b57a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207656
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67912}
