.. print them as '-0.0' instead of '0.0'.
Change-Id: I425d78e245868e7ff878c07282a0f9d8ca67a8d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128558
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85036}
The arm64 version of GeneratorStore was using the write barrier
incorrectly, triggering it when it shouldn't be triggered (and
vise-versa), and a "PointersFromHere" was mistakenly used instead of a
"PointersToHere".
The reason for the incorrect ne/eq used in CheckFlags is that this
function works a bit differently on x64 and arm64, cf their
implementations:
- x64: https://source.chromium.org/chromium/chromium/src/+/main:v8/src/codegen/x64/macro-assembler-x64.cc;l=3425;drc=605e46479aca3449a6ba1350a1de7927c76b86ad
- arm64: https://source.chromium.org/chromium/chromium/src/+/main:v8/src/codegen/arm64/macro-assembler-arm64.cc;l=3248;drc=dc950c32bd5262d66d845d2bfeb1ff4a17a857bc
For an example of both of those functions used for similar purposes,
see `MacroAssembler::RecordWrite` in macro-assembler-x64.h and
macro-assembler-arm64.h: the former uses `zero` in `CheckFlags`, while
the latter uses `ne`.
When --stress-maglev and --verify-heap were enabled, this mistake was
causing a crash in the heap verifier in the
`mjsunit/es6/typedarray-from.js` and `mjsunit/wasm/gc-js-interop.js`
benchmarks. I was able to reproduce those crashes on x64 by replacing
the "not_equal" in CheckFlags by "equal".
Bug: v8:7700
Change-Id: I42316931fba858433317238fc42f7c33985f46ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128556
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85035}
Addresses two potential performance regressions introduced in
https://crrev.com/c/4116776. First, the left-over CHECK is changed to a
DCHECK. Second, calling `EarlyGetReadOnlyRoots` should at least be as
efficient as `GetReadOnlyRoots` before the earlier change.
Bug: v8:13466
Change-Id: I93e9c06ce651cae90e9c969e54ec73e4eab80fd6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4127159
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85032}
This makes js-fuzzer use %OptimizeMaglevOnNextCall in 30% of the
times when optimization patterns are chosen. Other probabilities
of the function-call mutator are tuned a bit to keep using
%OptimizeFunctionOnNextCall proportionally similarly to before.
(~ some round number preferences... exact choices might not matter
much, since the original probability choices are rater arbitrary
anyways)
Bug: v8:7700
Change-Id: I7727ea27fd956efab6fbee2b4a090213d1d7ff05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4124118
Reviewed-by: Almothana Athamneh <almuthanna@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85031}
Rename the flag in order to avoid confusion with `V8_STATIC_ROOTS_BOOL`.
The flag is used by `./mksnapshot` to generate a new static-roots.h
file.
Bug: v8:13466
Change-Id: Ieb5af89b9839673fd2b8aeef197c104aa3c580aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111933
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Olivier Flückiger <olivf@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85030}
The Sub macro sometimes needs a scratch register when the 2nd operand
is too large to be encoded in the instruction. The prologue was
already reserving 2 scratch registers, which made Sub crash on a
DCHECK when trying to reserve one more scratch register.
Bug: v8:7700
Change-Id: I995689b8b16e3ef216641f0b6cadbf58f7f3740b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128554
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85029}
When the interrupt_budget is exhausted, Maglev code calls into runtime
for tiering logic in TieringManager. As always, the runtime call
itself has a certain (noticeable) overhead.
This CL is an optimization based on the observation that the
TieringManager only performs simple bookkeeping if the
tiering_state (or osr_tiering_state) is kInProgress. We can avoid
the runtime call overhead in this case. Changes are:
1. Extract the interrupt check (= stack check) into generated code s.t.
it's separate from tiering logic. Note, combining the interrupt
check and tiering logic was a previous optimization to reduce
generated code size, introduced in crrev.com/c/3049076.
2. Skip the runtime call to Runtime::kBytecodeBudgetInterrupt if
`tiering_state == kInProgress || osr_tiering_state == kInProgress`.
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel
Bug: v8:7700
Change-Id: Ibcd416aaea7abdd087741551fa213fa033fe12e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4127157
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85028}
A recent CL refactored some Deopts
(https://chromium-review.googlesource.com/c/v8/v8/+/4120575), and
mistakenly wrote EmitDeoptIf (which isn't an existing function)
instead of EmitEagerDeoptIf, which broke the Arm64 build (which
isn't covered by the bots yet).
Bug: v8:7700
Change-Id: I1301a26584bd76d1a2608c37c07c58fe990446d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128095
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85026}
.. and several other minor changes (branch hints, moving code around
for better grouping, const).
Bug: v8:7700
Change-Id: Ia07aa478a5ae5d1852e4ad2dce39f42743376e65
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128096
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85025}
.. that should now be a jump to `no_code_for_osr` since
AttemptOnStackReplacement is now emitted in deferred code and may thus
no longer fall through.
Fixed: chromium:1403135
Bug: v8:7700
Change-Id: I3dcd7696dc5a19a0cd955b2eef1538c07b2d6e00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4124200
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85022}
Mark rhs as clobbered since we may negate it. Negate the lhs in rax.
Bug: v8:7700, chromium:1403470
Change-Id: I9a26de78fcd8d1db90c1d26617001c0c699c350e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110814
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85021}
As a drive-by this also fixes property load from smi. We still need to check that we actually have a smi...
Bug: v8:7700, chromium:1403280, chromium:1403323
Change-Id: I3c4f050b94550b8d7e4e65f733f9c1dad47941d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4120575
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85015}
Even if we have a constant load, if the map is not stable, we cannot
guarantee that the load is preserved across side-effecting calls.
Fixed: chromium:1403324
Bug: v8:7700
Change-Id: Ib900cf7574711115439e6521ed8cfaa866525e78
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4123532
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85014}
It's possible that various branches merged already with a value that's
in a liveness hole, but we only figure out later. If so, drop the merge
as well.
Bug: v8:7700, chromium:1403399
Change-Id: Ifd97e0c1959ffe51017e400fb028041047885a9c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111932
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85013}
Many locations use the generic GetReadOnlyRoots() function to get access
to read only roots. Prominently this happens in Object::IsUndefined and
friends. The function is quite inefficient on shared read only root
build configurations as it always has to check if the shared read only
heap is already initialized or not. However, the heap is only
uninitialized during bootstrapping.
This CL replaces the branch by a CHECK and deals with the fallout
twofold. First, the SoleReadOnlyHeap is initialized earlier, right
after all heap objects have been created. Second, any location that
calls GetReadOnlyRoots() during initialization is fixed to access
the isolate-local read only roots table instead of the shared one.
Bug: v8:13466
Change-Id: I03e3e68eeefc8651818700629f69ff6163ceb6ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4116776
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Olivier Flückiger <olivf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85012}
Drop --future from 25% to 5% for a few days until all currently open
correctness cases associated with --future are fixed.
No-Try: true
Bug: v8:7700
Change-Id: I161a0adbc767c5cec46409443fe58c634531487c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4114292
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85010}
Some TF builtins (*_WithFeedback variants) consume some of the stack
arguments and pass the rest through to ASM builtins.
We need to seperately align the stack arguments consumed by the TF
builtin and the arguments passed to the ASM builtins via TailCall.
Bug: v8:7700
Change-Id: I26de558fd961cb35b5c642430f9e2c8523ecf096
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4118741
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85009}
Source register has to be 32-bit.
Bug: v8:7700
Change-Id: Ica2a51de100d81bc36447988f6508800f87379ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4118740
Auto-Submit: Patrick Thier <pthier@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85008}
The issue causing this test to fail on the usban bot was fixed with
https://crrev.com/fcda478d890caea6bf04a50e6106682b64cf8d5a
Bug: v8:13611, v8:13612
Change-Id: I1d0a713160cdddf8623e767d43277a988509bce0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110955
Auto-Submit: Patrick Thier <pthier@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85007}
Check strings length before calling to Builtin::StringEqual. If length
is not equal, the strings must also be not equal.
Change-Id: I4f8c2e72720d0919b3fd57013d06dcc8d83f2ab4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4090410
Commit-Queue: Hao A Xu <hao.a.xu@intel.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85005}
Wasm graph builder duplicates a vector of local variables for each block or branch, but it never frees them. So, if a single function has a lot of local variables allocated, the graph builder bloats the memory.
This CL actively frees the locals vector and reuses them within the zone. It's easy to reuse them since the locals vector always have the same size. This saves 95% of memory for the reported wasm binary.
Bug: v8:13543
Change-Id: Ibf5e846b405adc24101ed79dd34d08160ceda2fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4112638
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Choongwoo Han <choongwoo.han@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#85004}
This CL plugs the hole in the outside<-ShadowRealm direction (i.e.
getting a reference to an object inside of the ShadowRealm from outside
the ShadowRealm).
This is a follow-on CL to
https://chromium-review.googlesource.com/c/v8/v8/+/4108810, which
plugged the getFunction hole in the ShadowRealm<-outside direction (i.e.
getting a reference to an object outside of the ShadowRealm from inside
the ShadowRealm).
Bug: v8:1198
Change-Id: Ic06533ba8b1cc6477ef9d55a23cb8b0b6584d4a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4115657
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85003}
Port e17eee4894
Original Commit Message:
After https://crrev.com/c/3859787 those frames would be printed like
standard Wasm frames, but in the place of the WasmInstanceObject, they
have a WasmApiFunctionRef object instead.
So special-case the {WasmToJsFrame::instance()} to load the instance
properly. Also special-case the {position()} accessor for imported
functions.
R=clemensb@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: I370bc4f4f84e1262c4542879b9058f6cf1d9f84e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4122830
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84999}
With smi feedback, we use int32 operations for arithmetics.
When negating 0, we have to fallback to float as we can't represent -0
in int32. We can simply deopt in that case without causing a deopt loop, as a non-smi result will change the feedback to kSignedSmallInputs (from kSignedSmall).
Bug: chromium:1403102
Change-Id: Ic27c267349a1de6904639e91b1cade2c4f7d1fe2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4122829
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Auto-Submit: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84998}
We should compare only 32 bits for smi when pointer compression
is enabled.
Bug: v8:7700
Change-Id: I6cbc22e57e873cb8ab3c26a4b655a393e258e697
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4122831
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84997}
This CL introduced four more operators in TurboFan: BigIntLessThan,
BigIntLessThanOrEqual, and the corresponding speculative operators so
that all the BigInt comparisons are supported.
This CL also implemented fast paths for small BigInt inputs.
Bug: v8:9407
Change-Id: Iaa2d4dbebf68656d775a7feb65b97fb5c598ec23
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111951
Commit-Queue: Qifan Pan <panq@google.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84995}
After https://crrev.com/c/3859787 those frames would be printed like
standard Wasm frames, but in the place of the WasmInstanceObject, they
have a WasmApiFunctionRef object instead.
So special-case the {WasmToJsFrame::instance()} to load the instance
properly. Also special-case the {position()} accessor for imported
functions.
R=victorgomes@chromium.org
Bug: chromium:1402270
Change-Id: I39805805a50e7a73d7d8075c63c46bdf5a373a33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4116778
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84993}
Pass the {WasmModule} in the {CompilationEnv} argument in
{CompileWasmImportCallWrapper} to {BuildWasmToJSWrapper}, which in
turn passes it to {FromJS}.
Bug: chromium:1401934
Change-Id: I8d689d881e4d8013cd4dcb6cfb54d663d1c4ec38
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4120443
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84992}
In the future we want to be able to return statically known pointers of
read only roots. To be able to do so we must ensure that heap
initialization code does not rely on the fact that the root is not
initialized yet and the accessor returns null. Instead we must
explicitly test if the root is initialized.
Bug: v8:13466
Change-Id: Id2b93388f499a58ff26ca5fb566b4538e00916e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4106452
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84990}
