Bug: v8:11325

Change-Id: I2eae55b49ea01567460bd0adfbb819c893ce7cd7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793210
Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Commit-Queue: ji qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#82054}

This very large changeset adds support for RISCV32.

Bug: v8:13025
Change-Id: Ieacc857131e6620f0fcfd7daa88a0f8d77056aa9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3736732Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82053}

Bug: v8:7834
Change-Id: I79646de331fde36626dd5604b38ef8dc60dafc3d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793003
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82052}

Change-Id: I4bbe5be6c6f13ee5664fa231d8dd9d59aa0ef579
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3792166Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#82051}

This is a reland of commit 33043888

Original change's description:
> [test262] Roll test262
>
> https://chromium.googlesource.com/external/github.com/tc39/test262/+log/3ddfa0cd..e41d581c
>
> Bug: v8:7834
> Change-Id: Id1c5b07f109ab6f60498eb7185becc508d16af1e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3786907
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81980}

Bug: v8:7834
Change-Id: Ic7e0378b11a05161b69965cff06985b9a2d954fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788719Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82050}

Also need to change how we got the prototype of Intl.NumberFormat
and Intl.PluralRules to install function in bootstrapper.cc code to avoid assertion in JSReceiver casting.

For m106
Flag: harmony_intl_number_format_v3
https://chromestatus.com/feature/5707621009981440
Design doc:
https://docs.google.com/document/d/19jAogPBb6W4Samt8NWGZKu47iv0_KoQhBvLgQH3xvr8
and
https://docs.google.com/document/d/14zxGub6Os6nARzH6XstOZX05w2537sZo_ZSSlGjGpBM

R2T: https://groups.google.com/a/chromium.org/g/blink-dev/c/vy6rCuh3r_0/m/1Q2FHx9hBAAJ
I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/mN6o7uk2hjM/m/I6-C006lBwAJ
LGTMs from API Owners: bratell.d@gmail.com, miketaylr@chromium.org, mkwst@chromium.org

Bug: v8:10776
Change-Id: I2c11e1c53390bdc6246caf084661d82e08a4d94c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3790120
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82049}

arrayref, dataref and i31ref get changed to (ref null t).

Bug: v8:7748
Change-Id: Iae0e6969a1f71ccf1f193c267d761b7a1796f67b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788093
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82048}

CreateJob() doesn't schedule anything until Join() or Notify*() is called. CreateJob().Join() will thus schedule the right number of
workers for the job right away (taking into account the main thread
contributes), whereas PostJob().Join() schedules 1 worker that won't
be necessary once doing Join() and the main thread kicks in.
This has the effect of reducing 1 unnecessary context switch each time
the jobs are schedule.

Bug: chromium:1287665
Change-Id: Ie262f8904cc8ac78d9e5cbd23ef28dc5b013a625
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3746080Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82047}

It was delegating to GetDerivedMap but not handling the possible
error coming from it.

Bug: v8:11111,chromium:1347722
Change-Id: I348ed721281d8edd324f0e364d8ed45602cb9f54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791063Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Marja Hölttä <marja@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82046}

This is a reland of commit e895b7af

The unit test has been updated to work correctly when
--stress-incremental-marking is enabled.

Original change's description:
> Background merging of deserialized scripts
>
> Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions
> with which an embedder could request that V8 merge newly deserialized
> script data into an existing Script from the Isolate's compilation
> cache. This change implements those new functions. This functionality is
> still disabled by default due to the flag
> merge_background_deserialized_script_with_compilation_cache.
>
> The goal of this new functionality is to reduce memory usage when
> multiple frames load the same script with a long delay between (long
> enough for the script to have been evicted from Blink's in-memory cache
> and for the top-level SharedFunctionInfo to be flushed). In that case,
> there are two Script objects for the same script: one which was found in
> the Isolate compilation cache (the "old" script), and one which was
> recently deserialized (the "new" script). The new script's object graph
> is essentially standalone: it may point to internalized strings and
> readonly objects such as the empty feedback metadata, but otherwise
> it is unconnected to the rest of the heap. The merging logic takes any
> useful data from the new script's object graph and attaches it into the
> old script's object graph, so that the new Script object and any other
> duplicated objects can be discarded. More specifically:
>
> 1. If the new Script has a SharedFunctionInfo for a particular function
>    literal, and the old Script does not, then the old Script is updated
>    to refer to the new SharedFunctionInfo.
> 2. If the new Script has a compiled SharedFunctionInfo for a particular
>    function literal, and the old Script has an uncompiled
>    SharedFunctionInfo, then the old SharedFunctionInfo is updated to
>    point to the function_data and feedback_metadata from the new
>    SharedFunctionInfo.
> 3. If any used object from the new object graph points to a
>    SharedFunctionInfo, where the old object graph contains a matching
>    SharedFunctionInfo for the same function literal, then that pointer
>    is updated to point to the old SharedFunctionInfo.
>
> The document at [0] includes diagrams showing an example merge on a very
> small script.
>
> Steps 1 and 2 above are pretty simple, but step 3 requires walking a
> possibly large set of objects, so this new API lets the embedder run
> step 3 from a background thread. Steps 1 and 2 are performed later, on
> the main thread.
>
> The next important question is: in what ways can the old script's object
> graph be modified during the background execution of step 3, or during
> the time after step 3 but before steps 1 and 2?
>
> A. SharedFunctionInfos can go from compiled to uncompiled due to
>    flushing. This is okay; the worst outcome is that the function would
>    need to be compiled again later. Such a risk is already present,
>    since V8 doesn't keep IsCompiledScopes for every compiled function in
>    a background-deserialized script.
> B. SharedFunctionInfos can go from uncompiled to compiled due to lazy
>    compilation. This is also okay; the merge completion logic on the
>    main thread will just keep this lazily compiled data rather than
>    inserting compiled data from the newly deserialized object graph.
> C. SharedFunctionInfos can be cleared from the Script's weak array if
>    they are no longer referenced. This is mostly okay, because any
>    SharedFunctionInfo that is needed by the background merge is strongly
>    referenced and therefore can't be cleared. The only problem arises if
>    the top-level SharedFunctionInfo gets cleared, so the merge task must
>    deliberately keep a reference to that one.
> D. SharedFunctionInfos can be created if they are needed due to lazy
>    compilation of a parent function. This change is somewhat troublesome
>    because it invalidates the background thread's work and requires a
>    re-traversal on the main thread to update any pointers that should
>    point to this lazily compiled SharedFunctionInfo.
>
> At a high level, this change implements three previously unimplemented
> functions in BackgroundDeserializeTask (in compiler.cc) and updates one:
>
> - BackgroundDeserializeTask::SourceTextAvailable, run on the main
>   thread, checks whether there is a matching Script in the Isolate
>   compilation cache which doesn't already have a top-level
>   SharedFunctionInfo. If so, it saves that Script in a persistent
>   handle.
> - BackgroundDeserializeTask::ShouldMergeWithExistingScript checks
>   whether the persistent handle from the first step exists (a fast
>   operation which can be called from any thread).
> - BackgroundDeserializeTask::MergeWithExistingScript, run on a
>   background thread, performs step 3 of the merge described above and
>   generates lists of persistent data describing how the main thread can
>   complete the merge.
> - BackgroundDeserializeTask::Finish is updated to perform the merge
>   steps 1 and 2 listed above, as well as a possible re-traversal of the
>   graph if required due to newly created SharedFunctionInfos in the old
>   Script.
>
> The merge logic has nothing to do with deserialization, and indeed I
> hope to reuse it for background compilation tasks as well, so it is all
> contained within a new class BackgroundMergeTask (in compiler.h,cc). It
> uses a second class, ForwardPointersVisitor (in compiler.cc) to perform
> the object visitation that updates pointers to SharedFunctionInfos.
>
> [0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit
>
> Bug: v8:12808
> Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#81941}

Bug: v8:12808
Change-Id: Id2036dfa4eba8670cac899773d7a906825fa2c50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787266Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#82045}

1. A remainder equal to zero means no deopt.
2. We need the input value in the input register, so we need to treat
   rax as a clobbered temporary instead of a fixed input.

Bug: v8:7700
Change-Id: I9a7b7f3cc48e17b262aa7f9084fa864ad505be54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788099
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@{#82044}

Port ec6368bf

R=yahan@iscas.ac.cn, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N

Change-Id: I268121f4b3ec66ca3b545551c337066ec5d7cdc5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791905
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#82043}

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

This is a reland of commit ef1e65d9

Original change's description:
> [maglev] Inline allocation for heap numbers
>
> Bug: v8:7700
> Change-Id: I2ce46fcfaab6716e6a31167ed517d2e8d9e433d8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788094
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82027}

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

While marking uses, record what values are used inside a loop, but
defined outside of it. Then, on the loop end, extend the lifetime of
these values.

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

Label already supports forward references through the label itself, so
we don't need to keep track of that separately.

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

Memory64 currently does not use trap handling, so we should not allocate
a guard region (10GB total reservation).
This is implemented by adding a {WasmMemoryFlag} enum in the backing
store header, which replaces the previous {MemoryIndexType}. The flag is
not stored with the backing store, as the backing store does not care
about the index type, and we might want to share the same backing store
for memory32 and memory64 (if sizes permit this).
Instead, we (still) store the flag with the WasmMemoryObject and pass it
to the backing store methods.

R=jkummerow@chromium.org

Bug: v8:10949
Change-Id: I284b85b98d181ba5e8d454b24bfa48f6ac201be5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789506Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82038}

I forgot to remove the -1 when hoisting it.

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

Register merges participate in the same parallel gap move as phi inputs,
but their allocation is not aware of the phis' existence (since the
register merge allocation sees the register state _before_ phi input
allocation, which is because that's what parallel move requires). This
means that they might move into a register that is used by a Phi, and
possibly will clobber its value.

Avoid this by recording what registers phis move values into during code
gen, and skipping register moves into those registers. Also DCHECK that
the recorded gap moves can't clobber a target register from a previous
gap move. Additionally, add printing for register merges (both in
regalloc tracing and graph printing).

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

Bug: v8:7748
Change-Id: Ifd4caec2015894f736dd94356298f6ee35ac852b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779911Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82035}

This reverts commit ef1e65d9.

Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20debug/42329/overview

Original change's description:
> [maglev] Inline allocation for heap numbers
>
> Bug: v8:7700
> Change-Id: I2ce46fcfaab6716e6a31167ed517d2e8d9e433d8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788094
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#82027}

Bug: v8:7700
Change-Id: I63ba2b1c879db652270fa1a83e32f6fec948333b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791064
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82034}

This is deprecated since 10.5 and replaced by the new callback which
receives more OOM details.

R=mlippautz@chromium.org

Bug: chromium:1323177
Change-Id: I9385da33c3d9227144ebc47d6dddae702701ff82
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789509Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82033}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/1404d7f..ce68e6e

R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com

Change-Id: I3c4085d6ceec054f441fcfd53632b3cac7b85670
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791003
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82032}

Matches changes in https://crrev.com/c/3780308

No-Tree-Checks: true
Bug: chromium:1347876
Change-Id: Ifacff208785e87f31c9034361867ffde7c83a898
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3790966Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82031}

Bug: v8:13083
Change-Id: I3c96d9f6cc1e459f4f5704ddfcab218c39643010
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3790965Reviewed-by: Almothana Athamneh <almuthanna@chromium.org>
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82030}

Strips the Name section off a module.

Change-Id: Ie28b80e610e4a858689f6a8aa01c0855c4c905a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787876
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82029}

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

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

Trigger tier-up faster for small functions, while waiting longer
for big functions, while trying to keep the overall amount of
optimization roughly the same.

Change-Id: I279daa21e151e9db20340089f9fa111141c6e645
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779910Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82026}

Change-Id: I07eaf3e1cfdff8190b91adfc3c428fe356e5f7a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791060Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82025}

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

Advance the deprecation of structs, classes, and methods which do not
make sense any more after dynamic tiering.

They were marked V8_DEPRECATE_SOON in 10.5.

R=mlippautz@chromium.org

Bug: v8:12899
Change-Id: I12b21f7d968a161b285b558d6e2437b0d03ef696
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789510Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82023}

Now with smaller repro

Bug: v8:11111,chromium:1347721
Change-Id: I637d85e91249aa8eb433f6e00e4fd385d5b950ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789519
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82022}

after ccefc2e2.

Bug: v8:13023
Change-Id: I5830296fa03e75e503cea116e90ff27327b0b642
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3790960Reviewed-by: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82021}

We visit the pointers in the same order as the ASCII diagram.

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

This method is only called from {AllocateWasmMemory}, so does not need
to be public.

R=jkummerow@chromium.org

Bug: v8:10949
Change-Id: Idf411179b6cf816adc111ceebf79335177e3440b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789502Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82019}

DoubleRegister RegisterMerge could get assigned a Tagged representation
operand if the node in the merge was null.

Also, we had a wrong DCHECK when materialising these moves, as a result
of templatifying the gap move implementation.

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

Add CI builder-pair for Mac-arm64 with no pointer compression with a matching
optional trybot. Also rename existing similar builder for Linux to have "no"
in the name as well.

Bug: v8:13083
Change-Id: I33389b8f224f12cf9fd3abf78f9cbabdf6ee5bfc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779914Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82017}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/8ec71a4..1404d7f

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/184bc29..37aede2

R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com

Change-Id: I7490ab280878824e90336ff9978adfd404c97f9f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789873
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82016}

Rolling v8/buildtools/third_party/libunwind/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libunwind/+log/955e2ff..2a908ee

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/b1e3787..84a7988

Rolling v8/third_party/fuchsia-sdk/sdk: version:9.20220726.1.1..version:9.20220727.1.1

R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com

Change-Id: I1e7a959bb2a4c0c9c2c52c692a626cabeddc8d9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3789872
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#82015}