Currently the shared value barrier manually fast paths instance types
for objects that are always in the shared heap. This CL makes a common
superclass, AlwaysSharedSpaceJSObject, and uses that for the fast path.
Bug: chromium:1402920, v8:12547
Fixed: chromium:1402920
Change-Id: I84421802791a4dc72925341eeb0cfc5949b8938a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4134475
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85192}
A MinorMC in a client isolate while incremental marking is active in the
main isolate may observe an object in the shared heap as residing on an
evacuation candidate. It would then treat it as OLD_TO_OLD rather than
OLD_TO_SHARED.
This logic is obsolete and no longer needed since MinorMC is not
interleaved with full GCs and only need to record OLD_TO_NEW and
OLD_TO_SHARED slots.
Fix by removing OLD_TO_OLD and OLD_TO_CODE recording.
Bug: chromium:1402660
Change-Id: I5482d3fe7d7a4eeb00be13445d66f178a3ffe2fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4152485
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85191}
Drive-by fixes:
1. On x64, avoid reloading from memory a value already in a register.
2. On arm64, pop has the wrong order of the padding/value.
Bug: v8:7700
Change-Id: I3baedcc280f5c544cc9d44b37aaf80e4eb8bd636
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4152472
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85190}
Allow the user to specify the range of instructions
that are shown on the live ranges grid so as to
ease performance issues.
Bug: v8:7327
Change-Id: I431e4464155427f59adf3a2229806c6f11c471be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110973
Commit-Queue: George Wort <george.wort@arm.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85186}
Most Wasm signatures still do not contain any tagged parameters. Thus
skip the second pass over the signature if we did not see any tagged
parameter before.
R=ahaas@chromium.org
Bug: v8:13565
Change-Id: Icf0df86bc96125b38adb65f074166b6b3c47b722
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4147615
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85184}
InstanceType is a 16bit word.
Bug: v8:7700
Change-Id: Id73d2bf42fd682d3fa5136e17a9f85e353edbe4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4151199
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85182}
We add simplified Turbofan operators for the following wasm-gc
operations: struct.get/set, array.get/set, array.length, and array
length initialization. We then lower them to object load/store
operators in WasmGCOperatorReducer.
Bug: v8:7748
Change-Id: I3b40df1419e5ad98562e6bec6c4a3d1a4de63c71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4146428
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85181}
This is a reland of commit fe54336953
The reland fixes an arm64 compilation error.
Original change's description:
> [maglev] Force (U)Int32 values to always be zero extended
>
> Ensure that (U)Int32 values are always zero extended (in particular,
> after Float64 truncation and constant materialisation), and add debug
> code which asserts that (U)Int32 register inputs to nodes are zero
> extended at input read time.
>
> Bug: v8:7700
> Change-Id: Idbebabdd48bc7a6d2d73f1dfce7da629b5814ca5
> Fixed: chromium:1404066
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4147621
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Auto-Submit: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#85169}
Bug: v8:7700
Fixed: chromium:1404066
Change-Id: I4f61acfd3a1cdbc8c1976bb1731441cb1e8fe784
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4151569
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85180}
This is a reland of commit 3cc300558e
Original change's description:
> [maglev] Remove kScratchRegister in maglev-ir
>
> The use of kScratchRegister in arm64 code is unsafe. Since a scratch
> scope could re-use the same register. Ideally, we should remove it
> altogether, but we still currently require it for the ParallelMover.
>
> Bug: v8:7700
> Change-Id: I46c93874632a3d505ef71a7bf790c31fb5fd46d6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4147617
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
> Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
> Auto-Submit: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#85156}
Bug: v8:7700
Change-Id: I7de621b19da48c234ccb18ca702aa041673a1c2e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4151489
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85178}
The condition is a simple page flag check so shouldn't be too
expensive. This will help investigate the linked issue which is
currently not reproducible.
Bug: v8:13267, chromium:1405324
Change-Id: I3e93dd120884e81814b3bb59626ea45721d1a86d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4151196
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85176}
Also remove unnecessary maglev runs on x64 FYI bots, since maglev runs
on the main waterfall's x64 bots already.
Bug: v8:7700
Change-Id: I5bb23c3ba7696b48f2fe1af4036a3de8c5b1801a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4128092
Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85174}
This is a reland of commit ebd933037e
Original change's description:
> [flags,testrunner] Consider readonly flags for conflict detection
>
> Flag conflict detection 1) bails out on incompatible flag values (e.g.
> --jitless and --turbofan) and 2) handles such bailouts transparently in
> the test runner by marking affected tests as OUTCOMES_FAIL.
>
> This CL adds full support for readonly flags to this system, together
> with required additional annotations in variants.py.
>
> Drive-by: assert proper use of v8_enable_slow_dchecks, and add
> support when dcheck_always_on is set.
> Drive-by: introduce has_maglev build variable detection based on
> v8_enable_maglev and use that for .status file annotations.
> Drive-by: protect against unintended overwrites of build variables
> in statusfile.py.
>
> Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel
> Bug: v8:13629,v8:10577
> Change-Id: I04de399139a0490806df8bfee7e75e2ec767b4b5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4135879
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#85130}
Bug: v8:13629,v8:10577
Change-Id: I49ce322c3fda00a1e1e280d99d2d818772533927
Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4151087
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85172}
- 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}
Ensure that (U)Int32 values are always zero extended (in particular,
after Float64 truncation and constant materialisation), and add debug
code which asserts that (U)Int32 register inputs to nodes are zero
extended at input read time.
Bug: v8:7700
Change-Id: Idbebabdd48bc7a6d2d73f1dfce7da629b5814ca5
Fixed: chromium:1404066
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4147621
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85169}
This check was probably relevant in the past (when GC was different),
but it is unknown today why it exists. It can cause races in a
concurrent set-up though, as tracking the post-processing state is not
atomic.
Due to possible races and no reason to check whether we are in GC
post-processing phase, this check is removed from
String::SupportsExternalization().
SupportsExternalization() was the only user of the logic.
Drive-by: Remove tracking of GC post-processing state, as
Change-Id: Id0a6dd25a8dc6044504b40f1c754612dedcacf75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4147612
Auto-Submit: Patrick Thier <pthier@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85167}
Only byte displacement was handled for opcode F6F7,
this CL adds 32-bit displacement support.
Change-Id: I40b3140df582cd0dce008dbbb957e615751c2131
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4144627
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Jie Pan <jie.pan@intel.com>
Cr-Commit-Position: refs/heads/main@{#85166}
The bytecode generator currently uses the wrong catch prediction in
the desugaring for for-of loops. This leads to unexpected pauses in
DevTools when 'pause on uncaught exceptions' is enabled, e.g. for throwing generators.
Specifically the call to .next of the iterator is unconditionally
marked as 'uncaught' instead of using the surrounding catch
prediction. Similarly, in the desugared "finally" block we call
.return which can also throw.
Note that if both the loop body and the ".return" throws, the
exception from ".return" is caught and only the loop body exception
is re-thrown. We still pause on both throw sites since we can't
detect this case statically.
R=leszeks@chromium.org
Bug: chromium:1270780
Change-Id: I2e642ef3fbfcfc6ad19e92cf611188801ebf2450
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4146420
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85164}
The class static blocks proposal has shipped since M91.
Bug: v8:11375
Change-Id: Icec89ea7e4bbef325f2b12b5f7f829840d3f4575
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4144630
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85162}
This is a reland of commit a614ccb8f7
This CL will cause a performance regression when running with MinorMC on
the bots. However this regression is expected (due to delaying pretenuring
decisions) and we anyway result from relanding crrev.com/c/4092734.
Original change's description:
> [heap] Adjust pretenuring heuristic for MinorMC
>
> MinorMC needed to process pretenuring feedback both after sweeping and
> at the end of the atomic pause, despite having no new feedback at the
> end of the atomic pause, because the heuristics didn't hold after
> sweeping. This CL adjusts the heuristics for MinorMC so that processing
> twice is no longer needed.
>
> Bug: v8:12612
> Change-Id: I4d3ebaeaa6e7868bcdcae6fbdb3bcecb0ebcb8bf
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4085983
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84730}
Bug: v8:12612
Change-Id: I3101f8c8b4c1d34ff95802fbc8c8d1fff81e8ddd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4147607
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85161}
There is no path to handle inline element access requiring a shared
barrier check.
Change-Id: Ia16d4792a136adebb753cc1eee9d2f45baeb0e46
Bug: v8:12547, chromium:1402921
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4144619
Commit-Queue: Luis Fernando Pardo Sixtos <lpardosixtos@microsoft.com>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85160}
This reverts commit 3cc300558e.
Reason for revert: Reverting because of TSAN failures https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8792427956695159937/+/u/Check/regress-1394663
Original change's description:
> [maglev] Remove kScratchRegister in maglev-ir
>
> The use of kScratchRegister in arm64 code is unsafe. Since a scratch
> scope could re-use the same register. Ideally, we should remove it
> altogether, but we still currently require it for the ParallelMover.
>
> Bug: v8:7700
> Change-Id: I46c93874632a3d505ef71a7bf790c31fb5fd46d6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4147617
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
> Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
> Auto-Submit: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#85156}
Bug: v8:7700
Change-Id: Ib5a47c20932c28163fc2627c5b433ca64ab55730
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4148267
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85159}
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}
The use of kScratchRegister in arm64 code is unsafe. Since a scratch
scope could re-use the same register. Ideally, we should remove it
altogether, but we still currently require it for the ParallelMover.
Bug: v8:7700
Change-Id: I46c93874632a3d505ef71a7bf790c31fb5fd46d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4147617
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85156}
When computing a call descriptor from a {wasm::FunctionSig} (which is
{Signature<ValueType>}), we were first computing a temporary
{Signature<MachineRepresentation>}.
This CL avoids this allocation by templatizing {BuildLocations} and
accepting either a {Signature<MachineRepresentation>} or a
{Signature<ValueType>}.
As {GetWasmCallDescriptor} shows up prominently in Liftoff performance
profiles (~2% of execution time), this optimization should give a slight
improvement in Liftoff compile time.
R=ahaas@chromium.org
Bug: v8:13565
Change-Id: Ibd2b72c29b965580e91e39bef560b82cc85d1b7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4147614
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85155}
The zone always returns 8-byte aligned pointers. This is sufficient for
all current uses, but future uses might require bigger alignment (for
SIMD or for types with custom alignment via `alignas`).
This CL adds static asserts that such types are not used with the
`Zone::New` or `Zone::NewArray` methods.
R=jkummerow@chromium.org
Change-Id: I9aefbc655b25a5a0b26d2a640b691a52abb5f3c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4146427
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85153}
{Zone::NewExpand} currently allocates a new segment of the right size
and also allocates first memory from it. Rewriting this to only allocate
the new chunk not only allows us to mark the {Zone::Expand} method as
"preserve_all" in a follow-up, but also make the code simpler.
R=leszeks@chromium.org
Change-Id: Ibbe3486b07c09c2c1b8b528c240d89879de2ef4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4147611
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85151}
This reverts commit 8fe57bf641.
Reason for revert: Looks like preserve_most is too experimental after all: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20shared/24208/overview
Original change's description:
> [x64] Make {Assembler::GrowBuffer} preserve most registers
>
> This makes many callers of {GrowBuffer} a lot slimmer, by avoiding the
> need to push and pop all values in otherwise caller-saved registers.
> E.g. {emit_mov(Register, Operand)} was measured to be ~2x faster (from
> 2.3% of Liftoff compilation time to 1.2%).
>
> R=bikineev@chromium.org
> CC=dlehmann@chromium.org
>
> Bug: v8:13565
> Change-Id: I681747a491548adf1374187cd9f37520c153ef1a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4127230
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#85147}
Bug: v8:13565
Change-Id: I80207ab3cc84958c3c453e63cc4062a408e05a27
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4147787
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#85149}
This makes many callers of {GrowBuffer} a lot slimmer, by avoiding the
need to push and pop all values in otherwise caller-saved registers.
E.g. {emit_mov(Register, Operand)} was measured to be ~2x faster (from
2.3% of Liftoff compilation time to 1.2%).
R=bikineev@chromium.orgCC=dlehmann@chromium.org
Bug: v8:13565
Change-Id: I681747a491548adf1374187cd9f37520c153ef1a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4127230
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85147}
The caller was rewritten but the ignore scope was left behind.
Bug: v8:12819
Change-Id: I76c297f43587bb5bd74c62cf39e0e979271a3b7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110939
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85146}
Instead of allocating the signature and the buffer separately, allocate
them in one chunk in the Zone.
R=ahaas@chromium.org
Bug: v8:13565
Change-Id: Ie6317bc695473cad667e47ad7869a07376c96631
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4138268
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85145}
This CL handles 2 issues with disposing of external string resources in
the string forwarding table:
1) Resources of unmarked strings during GCs with stack are correctly
disposed (these were previously leaking).
2) Resources of unmarked strings during GCs without stack are disposed
at most once. Previously resources could be disposed multiple times if
the same resource had multiple entries in the string forwarding table.
Bug: v8:12957, chromium:1403564
Change-Id: I809ec1ada1ee813d7277e85ade9aa1e3e95a80f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4136725
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85144}
This CL introduces typed optimizations for Turboshaft, which replaces all operations that produce a constant output (and don't have side effects) by the corresponding constant.
In addition, a new pass for eliminating dead code is introduced that cannot only remove dead operations, but also rewrite branches that are not required into GotoOps.
Drive-by: Introduce -0 as a "special value" for Float32Type and Float64Type to fix a few issues where 0 and -0 have been treated as identical.
Bug: v8:12783
Change-Id: Ia1450ad7a9abb5d58c7d753596ed08a33a73184f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4110993
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85143}
