The stored value might be an allocation that can be removed once the
Store node is removed. We need to revisit this node manually because
inputs in a node removed with ReplaceWithValue are not revisited
automatically.

Bug: v8:11510
Change-Id: I57cb8955a3e2f7143474ad7ced9d946e6d1cc18e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277880Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77899}

Posting compile tasks from the parser has several issues:

  1. We don't know how many functions there will be total, so we can't
     yet allocate shared_function_infos array on the Script
  2. Without this array, inner function compiles can't look up their own
     inner functions during bytecode finalization, so we can't run that
     finalization before script parse completes
  3. Scope analysis can't have run yet, so we can only post top-level
     function tasks and if we allocate SharedFunctionInfos early they
     are forced into a bit of a limbo state without an outer ScopeInfo.

Instead, we can post compile tasks during bytecode generation. Then, the
script parse is guaranteed to have completed, so we'll have a
shared_function_infos array and we will have allocated ScopeInfos
already. This also opens the door for posting tasks for compiling more
inner functions than just top-level, as well as generating better code
for functions/methods that reference same-script top-level
let/const/class.

Bug: chromium:1267680
Change-Id: Ie1a3a3c6f1b264c4ef28cd4763bfc6dc08f45d4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277884
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77894}

Bug: v8:12382
Change-Id: I31a9e919db56cf7642b2f5e22352ce3ebe0f6e23
Cq-Include-Trybots: luci.v8.try:v8_linux64_single_generation_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3278675
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77893}

Complete implementation of Heap::MakeHeapIterable() by also making the
LABs of paged spaces iterable. This method is the one to use when
the heap and/or a particular space shall be iterable.

Bug: v8:12338
Change-Id: Id859cf1a05df21a54939c504c59d7b1ccd659c9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277888Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77891}

In each wasm CallDescriptor, we store the signature of the call based on
the real parameters passed to the call. This signature is more precise
than the formal function signature. We use this signature in inlining
to enable more optimizations.

Changes:
- Add wasm_sig_ field to CallDescriptor.
- Construct the real signature in {DoCall} and {DoReturnCall} in
  graph-builder-interface, and pass it to all call-related functions in
  WasmGraphBuilder.
- Update {ReplaceTypeInCallDescriptorWith} to use ValueType over
  MachineType. Construct the updated function signature.
- In wasm-inlining, kill the Call node after inlining.
- Add two tests.

Bug: v8:11510
Change-Id: Ica711b6b4d83945ecb7201be26577eab7db3c060
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270539Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77889}

FLAG_wasm_dynamic_tiering is still off by default. When enabled,
it now uses the technique previously behind --new-wasm-dynamic-tiering.

Bug: v8:12281
Change-Id: I365c2c066e62418cd6abc7830f95d1fe0f950e33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275570
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77883}

Under certain conditions GC could flush bytecode array from
SharedFunctionInfos. This CL ensures that the bytecode array is always
available for reconstructing source positions.

Bug: chromium:1265570
Change-Id: I2ce7eb04201f69121687ab0aaa2af42adb2caae0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275569Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77877}

UnprotectAndRegisterMemoryChunk should only be called if we have
CodePageCollectionMemoryModificationScope or
CodeSpaceMemoryModificationScope open.

This also fixes cctests that create code objects without a
code modification scope.

Bug: v8:12054
Change-Id: Id931f1f8120050b2bb76ef3d5701b9a32e52ff37
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277882
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77873}

Unify parse post-processing between main-thread and background-thread
parsing, now that we have LocalIsolate and can Internalize on background
threads.

As part of this, simplify the LocalIsolate parking pattern to explicitly
park during ParseOnBackground, rather than being implicitly parked when
ParseOnBackground is called. This reduces the amound of scoping needed
in the BackgroundCompileTask::Run method.

Change-Id: Ifdb128b763129bda78bd1bae89dac1c62f872350
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277876
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77872}

Due to streaming, the SFI enqueueing can happen concurrently with with
main-thread finalising, so we need to add locks around accesses to the
SFI->Job map.

Bug: v8:12370
Change-Id: I60281a954ef10f7fcde559b9529077a6b9a82c31
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277874
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77869}

Diary  https://docs.google.com/document/d/1NqMw7DAVFCZRx67auC7sgOvrikHvCYuaB87JUf21yG8/edit#
https://chromium.googlesource.com/chromium/deps/icu.git/+log/eedbaf76..3e05d9da

chromium roll in https://chromium-review.googlesource.com/c/chromium/src/+/3224333

Bug: chromium:1260116
Change-Id: Ie1922a129310106985f3bf1bffd9101fce6bb73a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3237532Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77868}

- Add Wasm SIMD packing instruction:
  `LiftoffAssembler::emit_i8x16_{s,u}convert_i16x8`

- Add Wasm SIMD unpacking instructions:
  `LiftoffAssembler::emit_i64x2_{s,u}convert_i32x4_{low,high}`
  `LiftoffAssembler::emit_i32x4_{s,u}convert_i16x8_{low,high}`
  `LiftoffAssembler::emit_i64x2_{s,u}convert_i32x4_{low,high}`

- Add RVV instrucions: `vzext_vf{2,4,8}` and `vsext_vf{2,4,8}`

- Fixed simulator for `vslidedown_vi`

Bug: v8:11976
Change-Id: Idd383bc566589ce183f4fcef2201d2ccfe03519f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3273812Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Reviewed-by: Yahan Lu <yahan@iscas.ac.cn>
Commit-Queue: ji qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#77865}

Bug: v8:12228
Change-Id: I9312716f78e79fd0759c2f7adfef065b5df5cfda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275566Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Yolanda Chen <yolanda.chen@intel.com>
Cr-Commit-Position: refs/heads/main@{#77861}

This fixes a -Wshadow warning for NO_FLAG. The other option is to
make it an enum class, which makes test-conversions.cc a bit verbose.

Bug: v8:12244,v8:12245
Change-Id: I3ea429eb45e31b25d4c6658ceb86c33ba280ae51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3274015Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77860}

This reverts commit 72e01a06.

Reason for revert: Failing on Linux 64, local bisect to this change, run with --random-seed-stress-count=1000

Original change's description:
> Reland "[baseline] Enable concurrent sparkplug on future"
>
> This is a reland of 0e4554b4
>
> Original change's description:
> > [baseline] Enable concurrent sparkplug on future
> >
> > Bug: v8:12054
> > Change-Id: I9d5040c806232ecbe71c26b7d65acbc8005bbd00
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3233139
> > Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#77842}
>
> Bug: v8:12054
> Change-Id: I60849c6c9c7c7e6687422669e5636b2a283cc6ff
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275560
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77850}

TBR=leszeks@chromium.org,v8-scoped@luci-project-accounts.iam.gserviceaccount.com,victorgomes@chromium.org

Change-Id: I26b75edb26bd81128a2a266461e7a917dff3b176
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:12054
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3276912Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77858}

Bug: v8:12244,v8:12245
Change-Id: I98c3f5e4aeed2d2179c61d482999fb498c676639
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3273527Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77855}

Similar to previous bug v8:11771, this test needs deterministic GC
behavior so it is incompatible with concurrent inlining.

Bug: v8:12374, v8:4578
Change-Id: Ib3667744d1032524a0c2e697a970876dfc1677ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3272882
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77851}

This is a reland of 0e4554b4

Original change's description:
> [baseline] Enable concurrent sparkplug on future
>
> Bug: v8:12054
> Change-Id: I9d5040c806232ecbe71c26b7d65acbc8005bbd00
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3233139
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77842}

Bug: v8:12054
Change-Id: I60849c6c9c7c7e6687422669e5636b2a283cc6ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275560
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77850}

R=ecmziegler@chromium.org

Change-Id: Ia2502f8fec849b6622bf3cad9d65dae7bc0b83e0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275567Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77848}

Loop headers in the interpreter would start a new basic block, which
among other things would reset the liveness of that block. This meant
that a loop created after dead code, without a check for whether the
code is currently dead or not, would "resurrect" that block's liveness,
making the inside of the loop live even though the loop itself is
unreachable.

This works fine, since the loop is still unreachable, but can breaks
DCHECKs in bytecode liveness analysis for cases where a register is
supposed to be initialised before the loop, in the dead code, and is
then used inside the loop, in the resurrected code.

Normally this wouldn't be a problem, since blocks are normally killed on
the statement level and we check for deadness during statement
iteration, but `foo() = x` introduces an expression-level block killer
(being re-written to `foo[throw ReferenceError] = x`) and we don't check
for deadness after assignment Lhs preparation.

This does mean that we have to fix the InterpreterJumps test, to not try
to jump into the middle of a loop (since this could revive the loop).
This can only happen when manually creating bytecode, bytecode generated
from JavaScript is always reducible.

Bug: chromium:1230597
Change-Id: I8403ccdeae7e5450adf629026e2ca8a134c81877
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275557
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77846}

This reverts commit 90a9d6cb.

Reason for revert: Seems to make some test to fail flakily. Revert for now until this is fixed.

Original change's description:
> [heap] Support multiple clients in shared GC
>
> Add support for safepointing multiple isolates as described in the
> design doc (link is below). A safepoint across multiple isolates is
> considered a global safepoint to distinguish it from regular safepoints.
>
> The basic idea behind the implementation is that we reach a
> safepoint for each client. What's new is that now also main threads
> need to participate in the safepointing protocol and need to give up
> control in time. The slow paths of Park(), Unpark() and Safepoint() on
> the main thread need to be adjusted for this reason as well.
>
> This CL introduces GlobalSafepoint and GlobalSafepointScope to mirror
> IsolateSafepoint and IsolateSafepointScope.
>
> This CL adds the type IgnoreLocalGCRequests, it is used to prevent
> Park() and Unpark() from honoring the request from background threads
> to perform a local GC. This is used heap-internally to not have GCs
> (or even nested GCs) in certain locations. E.g. when initiating a
> safepoint to perform a GC we don't want a "recursive" GC to occur.
>
> Design doc: https://docs.google.com/document/d/1y6C9zAACEr0sBYMIYk3YpXosnkF3Ak4CEuWJu1-3zXs/edit?usp=sharing
>
> Bug: v8:11708
> Change-Id: I5aca8f5f24873279271a53be3bb093fc92a1a1eb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009224
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77812}

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: v8:11708
Change-Id: I85fbf896c59492fc571b3bfaa7f9e3ea8a883260
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275552
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77845}

Test needs young generation to work properly.

Bug: v8:12380
Change-Id: I5dca5bd6be10371ee9aabf263c4f8491917b9803
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275556
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77844}

This reverts commit 0e4554b4.

Reason for revert: Breaks due to read-only flags https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20debug%20builder/3926/overview

Original change's description:
> [baseline] Enable concurrent sparkplug on future
>
> Bug: v8:12054
> Change-Id: I9d5040c806232ecbe71c26b7d65acbc8005bbd00
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3233139
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77842}

TBR=leszeks@chromium.org,v8-scoped@luci-project-accounts.iam.gserviceaccount.com,victorgomes@chromium.org

Change-Id: I25bbe7f38d87fcc13931782d26cd6b75bba50848
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:12054
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275555Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77843}

Bug: v8:12054
Change-Id: I9d5040c806232ecbe71c26b7d65acbc8005bbd00
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3233139
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77842}

Changes:
- Enable allocation folding for wasm-gc graphs.
- Improve structure of wasm escape analysis code. Kill dead nodes.
- Revisit object node after eliminating a load or a store to that node.
- Add a couple of tests, rename one test file.

Bug: v8:11510
Change-Id: I8b3c5186cd0a8827744a05eba366ff79bc7bc975
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3264215Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77840}

The second parameter of Int64Mul may be a 64-bit immediate value,
treating it as a 32-bit value will lose the upper 32 bits.
Besides, add a test for this error.

Bug: v8:12373
Change-Id: I92e95f7906051c91f9076730e5490b0956416d68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3272195
Auto-Submit: Liu yu <liuyu@loongson.cn>
Commit-Queue: Liu yu <liuyu@loongson.cn>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77833}

The is_shared bit bumps the number of reserved bits for Strings'
InstanceType from 6 to 7. This has the side effect of shuffling the
InstanceType enum values.

There are no users of this bit yet. This is steps 1-2 from the following
design doc [1], in preparation for sharing internalized and
in-place-internalizable strings.

[1] https://docs.google.com/document/d/1c5i8f2EfKIQygGZ23hNiGxouvRISjUMnJjNsOodj6z0/edit?usp=sharing

Bug: v8:12007
Change-Id: Idf11a6035305f0375b4f824ffd32a64f6b5b043b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3266017
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77831}

Change-Id: Ic868b6f9bb17bb9d6e6fe2a7203a41383aef5cf7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3272206Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Vasili Skurydzin <vasili.skurydzin@ibm.com>
Cr-Commit-Position: refs/heads/main@{#77823}

Rename flags to align them with other flags that are named in an
enabled way and drop the "never" prefix.

Drive-by: Refactor compaction entry point.

Bug: v8:12251
Change-Id: If2b189152f3cd22038b87fe3cc2ba0db4953ae23
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270534
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77813}

Add support for safepointing multiple isolates as described in the
design doc (link is below). A safepoint across multiple isolates is
considered a global safepoint to distinguish it from regular safepoints.

The basic idea behind the implementation is that we reach a
safepoint for each client. What's new is that now also main threads
need to participate in the safepointing protocol and need to give up
control in time. The slow paths of Park(), Unpark() and Safepoint() on
the main thread need to be adjusted for this reason as well.

This CL introduces GlobalSafepoint and GlobalSafepointScope to mirror
IsolateSafepoint and IsolateSafepointScope.

This CL adds the type IgnoreLocalGCRequests, it is used to prevent
Park() and Unpark() from honoring the request from background threads
to perform a local GC. This is used heap-internally to not have GCs
(or even nested GCs) in certain locations. E.g. when initiating a
safepoint to perform a GC we don't want a "recursive" GC to occur.

Design doc: https://docs.google.com/document/d/1y6C9zAACEr0sBYMIYk3YpXosnkF3Ak4CEuWJu1-3zXs/edit?usp=sharing

Bug: v8:11708
Change-Id: I5aca8f5f24873279271a53be3bb093fc92a1a1eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009224
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77812}

ia32 port of 9ffb4829

Bug: v8:12284
Change-Id: Id396ee6d169c893804297934df63120704cef745
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3255663Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77809}

4 instructions, int32x4.trunc_f32x4_{s,u},
int32x4.trunc_f64x2_{s,u}_zero.

ia32 port of a7b208739d2dabe11ca4e792085aed3455e879d5.

Bug: v8:12284
Change-Id: Ia94ff572b63f9fd8e3bfe2dd8e5fa41212f84a76
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3255661Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77807}

This flag is now enabled by default for quite some time in production.
In addition that flag was already defined readonly and couldn't be
disabled, so let's remove this flag for good.

Bug: v8:10064
Change-Id: I0e71eee9d25960a96324d56c8f0191fe678dc6e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268907
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77806}

The GC already treats some embedded object pointers in Code as weak,
based on Code::IsWeakObject. If one of those embedded objects ends up
unmarked during a full mark-collect GC, then the Code is marked for lazy
deoptimization and the embedded objects are cleared. However, many of
those same objects are often held strongly by the deoptimization literal
array for the Code, which causes memory leaks. This change updates the
deoptimization literals array to store those objects weakly. Any Code
currently executing on the stack might need those deoptimization
literals in order to deoptimize, so the deoptimization literal array is
marked strongly in that case.

Design document:
https://docs.google.com/document/d/1gFRBYCeqz9Mysx8CVYQkldBbk3AZLo8UX0DMLZV_7qw/edit?usp=sharing

Bug: v8:4578
Change-Id: I02e86683c59371e9f88ecf523750c9c6afebdb39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160299Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#77805}

In assignments the lhs should be evaluated first and shouldn't be
re-evaluated when the value of the rhs is available. Fix it by
saving the receiver and the key registers into AssignmentLhsData
before building the assignment and use them later, instead of visiting
the AST again to retrieve the receiver.

In addition, now that we save the receiver register, use it to
perform the brand check even when we know for sure that it's
going to fail later because it's a write to a private
method or accessing the accessor in the wrong way (v8:11364),
so that the brand check error always appears first if it is present,
as specified in
https://tc39.es/proposal-private-methods/#sec-privatefieldget

Drive-by: unify the brand check error messages, and replace "Object"
with "Receiver" in the messages for clarity. The instance private
brand check now throws "Receiver must be an instance of class <name>"
and the static private brand check now throws "Receiver must be
class <name>". Also always set the expression position to the
property load position, because the brand check failure comes from
the load operation.

Bug: v8:12352, v8:11364
Change-Id: I61a8979b2e02b561dd5b2b35f9e0b6691fe07599
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3266964
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77797}

In the future we will allow arbitrary objects as host-defined options.
To prepare the embedders for the upcoming changes we migrate the API
to use v8::Data where possible.

Internally we still use i::FixedArray with primitive values until the
migration to context-stored host-defined options is completed.

Note: This CL also introduces a temporary cast and inheritance
between Data and PrimitiveArray which will be removed again.

Bug: chromium:1244145
Change-Id: I852d0d827708d32b6f3a6d03457234a006e2fd77
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3264285
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77795}

In order to construct the optimal source code combination for functions
(and especially the positions inside the optimal source code for each
function), we need to know all functions upfront.

Rewrite the d8-based snapshotter so that it discovers all objects first
(+ assigns ids), then does the actual snapshotting.

Bug: v8:11525
Change-Id: I4f4e5589575ee9738e8a83aa6cda2c8164803b4c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268915Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77794}

Adds support for aborting compaction when finalizing with stack:
- never_compact_with_stack: All pages are aborted;
- never_compact_code_space_with_stack: Only code space pages are
  aborted;

This flags allow simulating a worst case where a stack cannot
be considered precise, or evacuation candiate is refered to from
a stack slot that V8 has no info for.

Bug: v8:12251
Change-Id: Ice24ac87a985b8ecf7b5cbb5c106ad4a3ae1944b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3173682
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77792}

This CL fixes a memory leak where we would not properly pop all
Promises from the Isolate-wide Promise stack. This can happen under
the following conditions:
  - `await`ing a Promise in an async function
  - Debugger is active
  - AsyncEventDelegate is not set.

In the case above, the promise of the surrounding async function is
pushed onto the global Promise stack, but not poped before the
await. This CL fixes that.

R=bmeurer@chromium.org

Fixed: chromium:1225905
Change-Id: If03f6bfda48b8cb14bc6a68815fd702632edc68d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268464Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77790}

This reverts commit b9ddcbc8.

Reason for revert: Hits unreachable on MSAN, see https://bugs.chromium.org/p/chromium/issues/detail?id=1267854

Original change's description:
> [fastcall] Enable float support on arm64 simulator
>
> This CL adds support for handling calls to C functions with arbitrary
> signatures on the arm64 simulator. It adds infrastructure for
> encoding the signature data from CallDescriptor and FunctionInfo
> classes into a compact representation, stored in the simulator and
> called EncodedCSignature.
>
> Design doc:
> https://docs.google.com/document/d/1ZxOF3GSyNmtU0C0YJvrsydPJj35W_tTJZymeXwfDxoI/edit
>
> This CL is a follow up on the native support added in
> https://chromium-review.googlesource.com/c/v8/v8/+/3182232
> and is partially based on the previous attempt:
> https://chromium-review.googlesource.com/c/v8/v8/+/2343072
>
> Bug: chromium:1052746
> Change-Id: I0991b47bd644b2fc2244c5eb923b085261f04765
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060486
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77744}

Bug: chromium:1052746, chromium:1267854, chromium:1267841
Change-Id: If3d5aaab6b5f4309ce90add614d674aaa86b43c7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3268910
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77788}