Add a map check for the RHS of instanceof checks (i.e. the class) when
loading its hasInstance method. We were previously confirming the value
of the RHS, to make sure that it's a constant, but not considering the
case that the map of that class could change (e.g. because of a
prototype change or field definition).
Bug: v8:7700
Change-Id: Ia2923b99dd0524670bebcc57e4c0c209f8835d04
Fixed: chromium:1407959
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4173568
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85336}
The RegisterInput (NewTarget) was not correctly visited by the GC.
This:
- Creates a sentinel safepoint to indicate that the stack is not
fully created (we are in the stack guard call).
- Generalises RegisterInputs (we assumed only NewTarget before) and
save them in the graph.
- Pass the register input count via tagged_register_indexes in
this case.
Fixed: chromium:1407606
Bug: v8:7700
Change-Id: I8f599f8c1a992ee6fd886eec1e289454649dfec8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4171626
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85331}
If the register allocator assigns kJavaScriptCallArgCountRegister
to {object}, we were clobbering the object, before pushing it to
the stack.
Additionally, we use PushReverse instead of Push to indicate
that kDataViewPrototypeGetByteLength has a JS call convention
(arguments are reversed). This is a no-op for x64, but it guarantees
the correct order of the padding in arm64.
Fixed: chromium:1406456
Bug: v8:7700, v8:13645
Change-Id: Ia9126ff5315ab4ab08ae733f138a1e0cb2d021a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4156053
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85227}
- For TypedArrays, we bail out trying to reduce the access.
- For DataView, we check dynamically the DataView object bitfield
and call a builtin on a slow path.
Drive by: fix presubmit lint to allow assertOptimized when
passing --maglev flag.
Bug: v8:7700, v8:13645
Change-Id: I3ce4773466f045ff10c86c41734e00fbb94eb331
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4146435
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85171}
Drive-by: fix wrong bound check for TypedArrays / DataView on arm64,
which sometimes resulted in unecessary deopts.
Bug: v8:7700, chromium:1405651
Change-Id: I9afb2008edb22c0cd63044a6700a9f276960c191
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4146437
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85157}
TurboAssembler::Switch considers its "condition" input is 64-bit.
However, Maglev's inner integers are rather Smis/32-bit integers.
Because we didn't not sign-extend the condition before calling
TurboAssembler::Switch, negative values were treated as positive
rather than negative.
Fixed: chromium:1403749
Bug: v8:7700
Change-Id: I78e934045330012186dc83dea0dc620ec977380a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128080
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85049}
.. which should result in 0 if x is non-negative, and -0.0 otherwise.
- Fix two invalid modulus-related folds.
- Handle aliased inputs in Int32ModulusWithOverflow.
- Drive-by: rename left/right to lhs/rhs to match the algorithm
description.
Note there is no deopt loop here since a result of -0.0 will update
feedback to kSignedSmallInputs.
Bug: v8:7700
Change-Id: I84fca0e43ded152d3520cbe73cc43299ff1c4230
Fixed: chromium:1403575
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128081
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85039}
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}
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}
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}
All IFS values of resumable loops are loop phis, so values from before
the loop can safely be dropped. In fact, if we don't drop them we might
not be able to restore them and crash in a safety check. Eagerly
dropping the values allows us to keep the safety check.
Bug: v8:7700
Change-Id: I99ef80e35db5aba965dc1c5c9d78f1d085e589fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110940
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
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@{#84943}
This (test-only) runtime function only supported unoptimized frames as
callers. Add support for Maglev frames as well by extracting the
relevant BytecodeArray and bytecode offset.
This reverts commit 955de73ee5.
Bug: chromium:1400549,v8:7700
Change-Id: I80f80f8736ff0400d6d47e355add2a07cdc4559e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4111851
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84931}
This is a reland of commit 5d95bd39ca
Original change's description:
> [maglev] Prevent lazy deopts during maglev's JumpLoop (=OSR)
>
> The problem was that synchronous Maglev OSR potentially caused
> code deoptimization during compilation dependency finalization; this
> led to a lazy deopt when returning from the call to
> Runtime_CompileOptimizedOSRFromMaglev. However, a lazy deopt is
> disallowed at this point, since a) Maglev doesn't support marking an opcode as both lazy- and eager deopt, and b) the JumpLoop opcode
> is already marked as eager deopt since that's how OSR is implemented
> under the hood. See also the comment in runtime-compiler.cc.
>
> We fix this by changing synchronous Maglev-to-Turbofan OSR
> behavior s.t. actual OSR compilation is triggered from Ignition
> (and not from Maglev). In other words, when synchronous OSR is
> requested:
>
> 1. trigger an eager deopt from Maglev to Ignition by returning a
> non-null code object from Runtime_CompileOptimizedOSRFromMaglev.
> 2. Ignition handles the pending OSR compile request (through
> osr_urgency).
>
> This CL also reverts previous partial fixes:
>
> This reverts commit 21969e8e24.
> This reverts commit 6bcbcfed5c.
>
> Bug: chromium:1394279,v8:13585,v8:7700
> Change-Id: I3d64aa39575ad806ba2623102092176ca160ef0b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110740
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84922}
Bug: chromium:1394279,v8:13585,v8:7700
Change-Id: Id9d1a1ab2dc36e481287a1a25863b45bf281920c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110746
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84928}
This reverts commit 5d95bd39ca.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20gc%20stress/2101/overview
Original change's description:
> [maglev] Prevent lazy deopts during maglev's JumpLoop (=OSR)
>
> The problem was that synchronous Maglev OSR potentially caused
> code deoptimization during compilation dependency finalization; this
> led to a lazy deopt when returning from the call to
> Runtime_CompileOptimizedOSRFromMaglev. However, a lazy deopt is
> disallowed at this point, since a) Maglev doesn't support marking an opcode as both lazy- and eager deopt, and b) the JumpLoop opcode
> is already marked as eager deopt since that's how OSR is implemented
> under the hood. See also the comment in runtime-compiler.cc.
>
> We fix this by changing synchronous Maglev-to-Turbofan OSR
> behavior s.t. actual OSR compilation is triggered from Ignition
> (and not from Maglev). In other words, when synchronous OSR is
> requested:
>
> 1. trigger an eager deopt from Maglev to Ignition by returning a
> non-null code object from Runtime_CompileOptimizedOSRFromMaglev.
> 2. Ignition handles the pending OSR compile request (through
> osr_urgency).
>
> This CL also reverts previous partial fixes:
>
> This reverts commit 21969e8e24.
> This reverts commit 6bcbcfed5c.
>
> Bug: chromium:1394279,v8:13585,v8:7700
> Change-Id: I3d64aa39575ad806ba2623102092176ca160ef0b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110740
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84922}
Bug: chromium:1394279,v8:13585,v8:7700
Change-Id: Ib82d06ab8281f0e59a2af2b631bf93b25064df1f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110745
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84925}
The problem was that synchronous Maglev OSR potentially caused
code deoptimization during compilation dependency finalization; this
led to a lazy deopt when returning from the call to
Runtime_CompileOptimizedOSRFromMaglev. However, a lazy deopt is
disallowed at this point, since a) Maglev doesn't support marking an opcode as both lazy- and eager deopt, and b) the JumpLoop opcode
is already marked as eager deopt since that's how OSR is implemented
under the hood. See also the comment in runtime-compiler.cc.
We fix this by changing synchronous Maglev-to-Turbofan OSR
behavior s.t. actual OSR compilation is triggered from Ignition
(and not from Maglev). In other words, when synchronous OSR is
requested:
1. trigger an eager deopt from Maglev to Ignition by returning a
non-null code object from Runtime_CompileOptimizedOSRFromMaglev.
2. Ignition handles the pending OSR compile request (through
osr_urgency).
This CL also reverts previous partial fixes:
This reverts commit 21969e8e24.
This reverts commit 6bcbcfed5c.
Bug: chromium:1394279,v8:13585,v8:7700
Change-Id: I3d64aa39575ad806ba2623102092176ca160ef0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110740
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84922}
If we'd do it before merging register values, we might drop a value from
a register that's needed by a phi.
Bug: v8:7700, chromium:1394036
Change-Id: I39be09d5ccf19ff70aaefc8865565f0d2169552c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4063692
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84576}
If a value is used after a try-block finishes, we need to make sure that
the catch-block can restore its value. Otherwise we'd accidentally drop
the value on register merge thinking we're in a liveness hole on the
merge after the catch (since the catch cleared all the registers). This
then breaks JumpLoops that need to restore the value in a specific
register.
Bug: v8:7700, chromium:1392061
Change-Id: I7255ccf9b36bf36583ad612882137b251c48caed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4055111
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84483}
This reverts commit a63f9912b7.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64/50370/overview
Original change's description:
> [maglev] Spill nodes that we'd otherwise fail to merge
>
> This makes sure that catch-blocks don't accidentally drop values that
> are only in registers, which can happen if we throw in deferred throwing
> code (e.g., in ThrowReferenceErrorIfHole). At the latest we'll discover
> such values when trying to merge after the catch block, noticing we
> can't find the value through the catch-block. Unfortunately it's not
> trivial to figure out where that merge happens, so we just
> unconditionally spill the value.
>
> For liveness holes (as the comment previously mentioned) the value
> should already be dead and dropped on the merge. Running --maglev-stress
> etc shows that no code currently hits this path, except for the added
> test that shows the issue with catch blocks.
>
> Bug: chromium:1392061
> Change-Id: Ied0b1d4b430c9af2e7ae3dfc004ecb45037c5735
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4051605
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Auto-Submit: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84448}
Bug: chromium:1392061
Change-Id: Iddbd7b19bc73e352dbd6867db990238f80adbdda
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4055504
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84455}
Function#call needs a function to call, so don't try to lower it to a
builtin call when there's no function.
Bug: v8:7700
Change-Id: I6705e2900731b2be2830231f8ab0dbfcdca5f594
Fixed: chromium:1392936
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4055680
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84451}
This makes sure that catch-blocks don't accidentally drop values that
are only in registers, which can happen if we throw in deferred throwing
code (e.g., in ThrowReferenceErrorIfHole). At the latest we'll discover
such values when trying to merge after the catch block, noticing we
can't find the value through the catch-block. Unfortunately it's not
trivial to figure out where that merge happens, so we just
unconditionally spill the value.
For liveness holes (as the comment previously mentioned) the value
should already be dead and dropped on the merge. Running --maglev-stress
etc shows that no code currently hits this path, except for the added
test that shows the issue with catch blocks.
Bug: chromium:1392061
Change-Id: Ied0b1d4b430c9af2e7ae3dfc004ecb45037c5735
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4051605
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84448}
The condition clearing the "known HeapObject" bit was wrong -- it was
checking whether the _map_ was a HeapObject (spoiler alert, it is), not
whether it was the map _of_ a HeapObject, i.e. not a HeapNumberMap which
returns true for Smis.
Bug: v8:7700
Change-Id: I5af4c1a662bb16bacdfcf178819d912332ecefd6
Fixed: chromium:1383712
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4023077
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84243}
For SignedSmall binary ops, we know that the output has to fit in a Smi.
So, emit a Smi check eagerly after these operations, so that future Smi
untagging knows that it doesn't need to do a check.
Bug: v8:7700
Change-Id: I117c55caa5e2ebe870fd964908564d74df726546
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4020434
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84223}
The builtin inlining for FunctionPrototypeCall has to consider the case
where there is no new receiver to the call. It now does this by
considering the new call args to be kNullOrUndefined instead of kAny.
Drive-by cleanup of CallArguments to always consider the register count
and not the argument count, unifying the with/without receiver
correction for the list-of-regs and RegList cases.
Bug: v8:7700
Change-Id: I7e8cb7e9d654fdfcbb8add80e7a0a01a39d36504
Fixed: chromium:1381663, chromium:1381665
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4008638
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84092}
Copy the instanceof fast path from TurboFan, which emits an
'OrdinaryHasInstance' when there is no @@hasInstance symbol (which can
eventually become a constant true/false if we can look through the
prototype chain), and a direct call of @@hasInstance otherwise.
In particular, the call to @@hasInstance requires a continuation builtin
(to call ToBoolean), so add support for these too.
Bug: v8:7700
Change-Id: I14aee4346e98cd650f190b811cc7a733e33addae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3990844
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84012}
An Int32Constant might need to be tagged in Phi boundaries.
This exposes the Graph's smi constants to frames state
merger logic.
Bug: v8:7700, chromium:1378814, chromium:1379571
Change-Id: Ib373b44a76324eeb23cf9fef4483f70160cd54b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3993220
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83993}
Unstable maps can transition to stable ones after a side effect,
therefore we cannot trust the set of stable maps. The CL nukes
from the set from stable_maps, equivalent of setting it to
the universal set.
Bug: v8:7700
Change-Id: I457f76efd48ec7eec747233ec063ebe265d3085a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3978169
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83923}
Currently it falls back to runtime for externalized strings.
Bug: v8:7700
Change-Id: I9bc09969915e437af5fcf563ba74a6edd9280779
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3956975
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83745}
Our previous assumption that the receiver is immutable is incorrect in
constructors. Change the current logic (which never generates an
exception phi for receivers, but instead re-uses the parameter slot)
into forcing the receiver exception phi to be allocated (and spilled) in
the receiver parameter slot.
Bug: v8:7700
Change-Id: I1ba92b2e711dc0fcd7c818526b9c199cadcdd3bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3948586
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83684}
Wait for TF optimisation to be requested (or to have happened) before
cranking up TF OSR urgency; this prevents us from getting into a
situation where we repeatedly call Maglev code which then OSRs into
TurboFan lots of times before finally tiering up to TurboFan properly.
Since we are waiting for TF optimisation to be requested, we also need a
mechanism to allow TF optimisation to be requested even when Maglev code
has been requested hasn't yet run (for direct Baseline->Turbofan tierup,
since Maglev can't OSR). Do so by re-trying the optimisation check if it
spits out Maglev but Maglev is already requested.
As a drive-by, clean up some naming around OSR code.
Bug: v8:7700
Change-Id: I483a412dd92fe13ee21f8aa46d86572bcf3f8a61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3942385
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83630}
Due to stack slot reuse, any of the moves that are part of the handler
trampoline may conflict and thus need parallel move resolution.
Materialisations (= calls to the NewHeapNumber builtin) add an addtl
complication since a) materialising moves can also be part of any
move conflict, b) the builtin call may clobber arbitrary registers,
and c) materialisation need a spot to store the NewHeapNumber result.
We resolve this by materialising into new temporary stack slots
before the main move sequence, and popping into the final target
locations after the main move sequence.
Bug: v8:7700
Change-Id: I1734faf189d02e38af07a817a9b647e2dce54f22
Fixed: chromium:1368046
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3921515
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83511}
Lazy deopts are always after calls, so force them to spill their inputs.
This would normally be the case anyway, except for deferred calls, which
don't tell the register allocator to spill like normal calls do.
This makes lazy deopt regalloc always spill its inputs and use their
spill slot, but unlike calls, this doesn't additionally clear the
register, so subsequent nodes can continue using the register cached
value without having to reload it.
As drive-bys, fix the Throw* opcodes to have the Throw property, and use
detail::DeepForEachInput in a couple of extra locations (including for
lazy deopts).
Bug: v8:7700
Change-Id: I89b04f17ca781d4f69ff0ed07566fa583aa677e6
Fixed: chromium:1364074
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899009
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83293}
The kContextRegister can alias allocated registers - when setting it,
take care not to unintentionally clobber.
Bug: v8:7700
Change-Id: I0635d334fb14fa15540582a4873d4186fffa2199
Fixed: chromium:1363450
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3897634
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83212}
Temporaries and the allocated result register may alias, thus order is
important when setting the result value.
Fixed: TestUndetectable, LogicalNot, SetPendingMessage.
Drive-by: Pass Label::kNear in a few spots I passed by.
Bug: v8:7700
Change-Id: Ice3de1d1014ad05d8fa9fb18d967887386bfed0d
Fixed: chromium:1359723
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3898530
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83207}
Check whether the exception phi for the accumulator (i.e. the exception
message object) is dead, and don't assign rax to it if yes. Note that
maglev node liveness can differ from bytecode liveness, since the
bytecode accumulator could have been considered "live" just because of a
move to a (dead) register.
Bug: v8:7700
Change-Id: If1384284f6f55a565e2ae94e5e7a32455fdedb93
Fixed: chromium:1359382
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3892353
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83197}
Ignition remembers the correct context to restore when entering an
exception handler by moving the context to an interpreter register
when entering a try block, and restoring it from there when unwinding
the frame and entering the catch block.
Maglev code has to do the same by taking the context from the
appropriate register for the handler's frame state.
Bug: v8:7700
Change-Id: I294fcccc845c660b2289b6d7b40f49f1aa46283d
Fixed: chromium:1359928
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3892352
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83181}
This is a reland of commit 24e60017d4
The reland changes %ClearFunctionFeedback to clear *all* feedback
slot kinds including binary/compare/for-in slots. In the tests we
thus no longer have to resort to tricks to restore the function to
it's initial state, instead simply call %ClearFunctionFeedback.
Original change's description:
> [maglev] Deopt on overflow in >>>
>
> Re-enable the int32 fast path for ShiftRightLogical, but account for
> Maglev's missing signed/unsigned representation tracking by a)
> removing rhs==0 as the identity value (a shift by 0 is still a
> signed-unsigned conversion) and b) deoptimizing if the result cannot
> be converted to a non-negative smi.
>
> Note this is not a deopt loop, since a non-smi result will change the
> feedback to kSignedSmallInputs (from kSignedSmall).
>
> To fix this properly, we should track signed/unsigned representations
> and convert the result to a heap number if it doesn't fit within smi
> range.
>
> Bug: v8:7700
> Change-Id: Ifd538d227a6f1290eb7f008d9bfad586ff91ea0f
> Fixed: v8:13251
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3876366
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83025}
Bug: v8:7700
Change-Id: I2f607a0fb863b80e8589c9c1e86ee31fbac48c25
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3879491
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83057}
This reverts commit 24e60017d4.
Reason for revert: Change breaks maglev GC stress tests.
Original change's description:
> [maglev] Deopt on overflow in >>>
>
> Re-enable the int32 fast path for ShiftRightLogical, but account for
> Maglev's missing signed/unsigned representation tracking by a)
> removing rhs==0 as the identity value (a shift by 0 is still a
> signed-unsigned conversion) and b) deoptimizing if the result cannot
> be converted to a non-negative smi.
>
> Note this is not a deopt loop, since a non-smi result will change the
> feedback to kSignedSmallInputs (from kSignedSmall).
>
> To fix this properly, we should track signed/unsigned representations
> and convert the result to a heap number if it doesn't fit within smi
> range.
>
> Bug: v8:7700
> Change-Id: Ifd538d227a6f1290eb7f008d9bfad586ff91ea0f
> Fixed: v8:13251
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3876366
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83025}
Bug: v8:7700
Change-Id: Ibd4c29cc57b999e1cfcd040cee3228ea27a74029
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3876374
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83029}
Re-enable the int32 fast path for ShiftRightLogical, but account for
Maglev's missing signed/unsigned representation tracking by a)
removing rhs==0 as the identity value (a shift by 0 is still a
signed-unsigned conversion) and b) deoptimizing if the result cannot
be converted to a non-negative smi.
Note this is not a deopt loop, since a non-smi result will change the
feedback to kSignedSmallInputs (from kSignedSmall).
To fix this properly, we should track signed/unsigned representations
and convert the result to a heap number if it doesn't fit within smi
range.
Bug: v8:7700
Change-Id: Ifd538d227a6f1290eb7f008d9bfad586ff91ea0f
Fixed: v8:13251
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3876366
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83025}
Inline DependOnStablePrototypeChain to iterate only those maps which
share a validity cell with the receiver map. This resolves an issue
where maps after the holder object violate the stability invariants, but
doesn't require looking up what the actual holder is.
Bug: v8:7700
Change-Id: Id06f0d13660f547e14dd25085799c0e6223c34b9
Fixed: chromium:1359215
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3871298
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82964}
At the start of the graph builder, we add merge states to exception
handlers basic block with ExceptionPhis (normal phis with no input,
but with an interpreter register "owner").
Every Node that can throw, can also lazy deopt, so we use the
lazy deopt IFS to recover the exception phi values in a trampoline
before jumping to the exception catch block.
Bug: v8:7700
Change-Id: I62fe7f19ce5e89c3df645224ea62f9fc2798207c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3865865
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82935}
We've previously reset profiler ticks on ML finalization to avoid
unexpected early tierups to TF. This CL additionally avoid early TF
tierup through the `small function` reason by disabling small-function
optimization.
Bug: v8:7700
Change-Id: I57ba294af0d1d189f76c2cb1ffc31af0837b1e42
Fixed: v8:13242
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3865550
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82886}
