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}
- 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}
Convert wasm-value into internal::WasmValue, then to debug::WasmValue.
This is then copied into a CDP protocol object via a new class,
WasmValueMirror.
Bug: v8:10347
Change-Id: I5778d2cc5701caf82e4a97ac329303e510695b74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151130
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67908}
This change updates some Torque-defined classes to include more precise
field types where possible. It also updates those classes to use
@generateCppClass. One field was removed because it's unused
(PrototypeInfo::validity_cell), and two fields in StackFrameInfo
actually became less precise because they're based on Script::name,
which is an embedder-provided untyped Local<Value>. (Automatically
generated accessors pointed out this bug easily.)
This change also includes a couple of minor fixes in Torque.
Change-Id: Ib2bc6c7165bb3612b6d344c0686a94165a568277
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199640
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67907}
Port 18ac08d03c
Original Commit Message:
This is a reland of 3cc981cb7a with a
fix for data race detected by TSan.
Original change's description:
> [wasm][debug] Fix tier down during streaming compilation
>
> If the debugger is enabled while streaming compilation is happening, we
> won't correctly tier down to Liftoff. This is because during streaming
> compilation, we always compile for no debugging. Fixing that is a bit
> tricky, since when the debugger is enabled, functions can either already
> have finished compiling, or they are currently being compiled, or their
> wire bytes are not received yet.
> Instead of handling this correctly while streaming compilation is
> running, we just recompile the whole module with Liftoff after streaming
> compilation finished.
>
> For testing this, we use the existing tests for async compilation, and
> enable --wasm-test-streaming, which compiles via the streaming decoder
> even in the async compilation case.
>
> R=thibaudm@chromium.org
>
> Bug: v8:10531
> Change-Id: I0177248a9ad2e90f83faee965d6746de05423f1f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207133
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67882}
R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I778a10eaba0016a9e897c8f71ac822c6b421350f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208901
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67906}
Registers cannot be used as a merge destination if they have more than
one use, otherwise the merge will unexpectedly affect other uses of that
register.
R=ahaas@chromium.org,clemensb@chromium.org
Bug: chromium:1084151
Change-Id: I0d6ad97c585920357a37d95361e0320d32c71f4b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208851
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67904}
Lookups and updates to the executable_memory_ unordered_map need to be
protected with mutex.
Bug: v8:10315, v8:10546
Change-Id: Ic17e19d1e4fda18b99103a96052940e68e970586
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208867
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67902}
The typed function references proposal allows an optional second
parameter to Table.grow containing the initialization value for the
newly added entries for tables that do not support null defaults.
This CL adds this functionality but hides it behind a newly added
experimental flag --experimental-wasm-typed-funcref.
R=ahaas@chromium.orgCC=jkummerow@chromium.orgCC=manoskouk@chromium.org
Bug: v8:9495
Change-Id: Ia156aeacf95bc36a9fc182990f315c42075cbb7b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207184
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67900}
Do not lock mutex for the full duration of the slow path of allocation
on background threads. For example sweeping and allocation of a new page
is now performed outside of the lock.
Bug: v8:10315
Change-Id: Ifee9bc1569d1ec53fdced965bd222dd1eab11b24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207131
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67898}
This is a reland of 3cc981cb7a with a
fix for data race detected by TSan.
Original change's description:
> [wasm][debug] Fix tier down during streaming compilation
>
> If the debugger is enabled while streaming compilation is happening, we
> won't correctly tier down to Liftoff. This is because during streaming
> compilation, we always compile for no debugging. Fixing that is a bit
> tricky, since when the debugger is enabled, functions can either already
> have finished compiling, or they are currently being compiled, or their
> wire bytes are not received yet.
> Instead of handling this correctly while streaming compilation is
> running, we just recompile the whole module with Liftoff after streaming
> compilation finished.
>
> For testing this, we use the existing tests for async compilation, and
> enable --wasm-test-streaming, which compiles via the streaming decoder
> even in the async compilation case.
>
> R=thibaudm@chromium.org
>
> Bug: v8:10531
> Change-Id: I0177248a9ad2e90f83faee965d6746de05423f1f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207133
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67882}
Bug: v8:10531, v8:10544
Change-Id: I884922b6ac55543e6ff9b1046438f6b3abab6f64
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207187
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67896}
Fix underflow when the break type list is empty, and do not try to
reuse the first value to generate the wanted type.
Bug: chromium:1084452
Change-Id: Ia9855a267730bb9f427518c27157f449475fb6ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208858
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67895}
For single-threaded, we can not tier up in the background. Hence we can
either tier up in foreground (which is pointless), or not tier up.
This CL disables Liftoff, so will compile TurboFan code right away.
R=ahaas@chromium.org
Bug: v8:10530
Change-Id: Icfdc26643ab219d617f844c2ea8e149870168dbc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208853
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67894}
TSan handles SIGPROF incorrectly, hence we don't get the samples we
expect on that test, and it quite frequently times out on TSan bots.
Skip it for now, until the TSan issue is fixed.
R=petermarshall@chromium.org
Bug: v8:9869
Change-Id: I27c65cdd10c53b441faad216e00d6c60b42229e6
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208857
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67892}
Allocation observers are not thread-safe, so the allocation steps should
be invoked only on the main thread.
Bug: v8:10536
Change-Id: I90e809fa230d18cce135f4bea67b62ef616ca593
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207189
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67891}
Call_WithFeedback
CallWithArrayLike_WithFeedback
CallWithSpread_WithFeedback
ConstructWithArrayLike_WithFeedback
ConstructWithSpread_WithFeedback
These are used in generic lowering if --turbo-nci is passed.
Bug: v8:8888
Change-Id: I78b56a1f358fa7c213e375eeb2feaa65432adfdb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199352
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67888}
Return type still needs TNodification. It can be Object or Float64T.
Bug: v8:10506, v8:6949
Change-Id: I71e7ae28f3039b2e1c5c2a5c2e383c335cdec38a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2204281
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67887}
Used to be named FastFixedArrayForEachBody. Rename to remove the 'fixed'
part since it can also be a PropertyArray (i.e not a FixedArray).
Rename BuildFastFixedArrayForEach to also remove the 'fixed'.
Bug: v8:10506, v8:6949
Change-Id: I840edf802d334b9ca930f3022553c476e2dca34a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2202910
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67886}
This reverts commit 3cc981cb7a.
Reason for revert: TSan failures: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/31572
Original change's description:
> [wasm][debug] Fix tier down during streaming compilation
>
> If the debugger is enabled while streaming compilation is happening, we
> won't correctly tier down to Liftoff. This is because during streaming
> compilation, we always compile for no debugging. Fixing that is a bit
> tricky, since when the debugger is enabled, functions can either already
> have finished compiling, or they are currently being compiled, or their
> wire bytes are not received yet.
> Instead of handling this correctly while streaming compilation is
> running, we just recompile the whole module with Liftoff after streaming
> compilation finished.
>
> For testing this, we use the existing tests for async compilation, and
> enable --wasm-test-streaming, which compiles via the streaming decoder
> even in the async compilation case.
>
> R=thibaudm@chromium.org
>
> Bug: v8:10531
> Change-Id: I0177248a9ad2e90f83faee965d6746de05423f1f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207133
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67882}
TBR=clemensb@chromium.org,thibaudm@chromium.org
Change-Id: I26e750c6c6d0783b5e4a0f19a5462a5fbe99a742
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10531
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207186
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67885}
We implement the conversions via C functions (external references)
because 64-bit conversions are difficult to implement on ia32 and
would not be significantly faster.
Bug: v8:10520
Change-Id: I3573d30bf6b3d558f708c7e0273f027c30a1a771
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2202988
Commit-Queue: Richard Stotz <rstz@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67883}
If the debugger is enabled while streaming compilation is happening, we
won't correctly tier down to Liftoff. This is because during streaming
compilation, we always compile for no debugging. Fixing that is a bit
tricky, since when the debugger is enabled, functions can either already
have finished compiling, or they are currently being compiled, or their
wire bytes are not received yet.
Instead of handling this correctly while streaming compilation is
running, we just recompile the whole module with Liftoff after streaming
compilation finished.
For testing this, we use the existing tests for async compilation, and
enable --wasm-test-streaming, which compiles via the streaming decoder
even in the async compilation case.
R=thibaudm@chromium.org
Bug: v8:10531
Change-Id: I0177248a9ad2e90f83faee965d6746de05423f1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207133
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67882}
So far this is mainly a readability improvement to specify
expectations on the packed argument. In the future we should also
check signedness during bytecode generation.
Drive-by: Update DCHECK to allow signed args to
CHECK_CURRENT_POSITION.
Bug: chromium:1083450
Change-Id: I9376ec691b51eb251c972309ad65dd6c04eec3ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207137
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67880}
Verify that `current` always points inside, or just past the end of the
subject string.
Bug: chromium:1083450
Change-Id: I27ba49cbfd0aa93cd2e305efafc23b155c98a49b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207136
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67879}
The lowering for anytrue was assuming that the input nodes are all
integers. The regression test added in https://crrev.com/c/2194471 calls
anytrue with float operands, this was causing the lowering to generate
cmpl instructions with a float register and an immediate, which is
wrong.
The fix is to use GetReplacementsWithType on the input nodes, but
only if the input were floats, since we use Word32Equal.
Drive-by clean up of comments in the aforementioned regression test.
Bug: v8:10535
Change-Id: I4de89516c178e9003a4c745808d831be87918381
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2203400
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67878}
