In typed-optimization, Turbofan optimized NumberFloor(NumberDivide(...))
patterns where both inputs are known to be of Unsigned32 type, but the
replacement couldn't be typed consistently. This CL introduces a new
operator Unsigned32Divide, which has the same semantics, but can be
typed consistently and thus allows the simplified lowering verifier to
validate the graph correctly.

Bug: v8:12619
Change-Id: Iad77154d3d840c94edfd3ab91ffa37c840da0bc9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644790
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80967}

https://crrev.com/c/3471854 already disabled the RecordWrite builtin
specifically for incremental marking. Since this didn't regress performance as expected, we can now remove those versions of the
builtin.

This will simplify the barrier implementation a bit, but is also
required for the shared heap write barrier. Unlike the generational barrier, the shared heap barrier can't be elided for map values.

Bug: v8:11708
Change-Id: I44bc6ee79006a5be8c1b593dee7fc30c3b9cfa85
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3683341Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80966}

Bug: v8:12797
Change-Id: Ide50026c7dc35197876e66cc53a7936acb765aa9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687735
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80965}

Mirrors a Chromium change @
https://chromium-review.googlesource.com/c/chromium/src/+/3680123
and a v8 change @
https://chromium-review.googlesource.com/c/v8/v8/+/3687370/

Bug: chromium:1330114
Change-Id: I61b1e34d54a496dda25936efbcd339fa35e64fb1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3686476
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Auto-Submit: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80964}

Mirrors a Chromium change @
https://chromium-review.googlesource.com/c/chromium/src/+/3680123

Bug: chromium:1330114
Change-Id: I6fdfd93264e669965245f5ba696fb5b605e417fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687370
Auto-Submit: Gabriel Charette <gab@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80963}

Currently the Isolate is gotten off of the object that the operation is
being performed on. Shared objects return the shared Isolate, which is
incorrect as it shouldn't be used to run JS, nor does it have
HandleScopes open. Plumb the executing Isolate through.

Bug: v8:12547
Change-Id: I2f500cbb707b3ce2e8a78203df9920374c190d28
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3691967
Commit-Queue: Luis Fernando Pardo Sixtos <lpardosixtos@microsoft.com>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80962}

Not all V8 build configs support JS shared memory features. Trying to
create a new shared Isolate on such a config DCHECKs at runtime. Make
the shared Isolate test fixture conditionally initialize the shared
Isolate. Users must explicitly check for support.

Bug: v8:12547
Change-Id: I3df1ce7eb5ae9a3c136f88ea8f44c650cc0408ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687565
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80961}

Spec Text:
https://tc39.es/proposal-temporal/#sec-temporal.zoneddatetime.prototype.add
https://tc39.es/proposal-temporal/#sec-temporal.zoneddatetime.prototype.subtract

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

Also implement AO: CompareEpochNanoseconds
Spec Text:
https://tc39.es/proposal-temporal/#sec-temporal.instant.compare
https://tc39.es/proposal-temporal/#sec-temporal.instant.prototype.equals

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

Also add AOs: AddISODate, RegulateISODate

Change the return type of GetISO8601Calendar from MaybeHandle to Handle since it will never throw exception.

Spec Text:
https://tc39.es/proposal-temporal/#sec-get-temporal.zoneddatetime.prototype.hoursinday
https://tc39.es/proposal-temporal/#sec-temporal-addisodate
https://tc39.es/proposal-temporal/#sec-temporal-regulateisodate

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

Spec Text:
https://tc39.es/proposal-temporal/#sec-temporal.plaintime.prototype.add
https://tc39.es/proposal-temporal/#sec-temporal.plaintime.prototype.subtract

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

Spec Text:
https://tc39.es/proposal-temporal/#sec-temporal.plaindatetime.prototype.add
https://tc39.es/proposal-temporal/#sec-temporal.plaindatetime.prototype.subtract

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

Spec Text:
https://tc39.es/proposal-temporal/#sec-temporal.plaindate.prototype.add
https://tc39.es/proposal-temporal/#sec-temporal.plaindate.prototype.subtract

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

Related to commit 2b6cbda0

Bug: v8:5210, chromium:1269989, chromium:1313647
Change-Id: I0046bdb3fe76a3eaf45e773b1fab87b65476cc1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3690457
Auto-Submit: Liu Yu <liuyu@loongson.cn>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Reviewed-by: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Cr-Commit-Position: refs/heads/main@{#80954}

When a 8x16 shuffle matches a packed byte to dword zero extension,
1. input1 is S128Zero after canonicalization,
2. the indices {0,4,8,16} are consecutive value in the range [0-15] and
other indices are in the range [16-31],
the shuffle can be matched to packed byte to dword zero extend. These
shuffles are commonly used in image processing.

Change-Id: I14d1e35401dbc5ecd91f67c46ea9762628835d01
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3547667Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Fanchen Kong <fanchen.kong@intel.com>
Cr-Commit-Position: refs/heads/main@{#80953}

Port commit a52b44f0

Bug: v8:12908
Change-Id: Ifcafab2f29d416f39fa48082e86c3c3b72508bad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3690453
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Auto-Submit: Liu Yu <liuyu@loongson.cn>
Reviewed-by: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Cr-Commit-Position: refs/heads/main@{#80952}

Port commit a52b44f0

Original Commit Message:

    Prototype the instruction on the interpreter, and Arm64. Details of
    instruction lowerings on all relevant architectures can be found at:
    https://github.com/WebAssembly/relaxed-simd/issues/52

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

The CL splits the Oilpan giga-cage in two 2GB reservations: one for
normal pages and the other for large ones. The split enables fast
page-header lookup (assuming most objects reside on normal pages), which
is needed for:
1) the young generation project, where the remembered set will move to
   pages;
2) the shared-cage project, to find HeapBase* from page-headers.

Bug: v8:12231, chromium:1029379
Change-Id: I4ae9e8a75a307ed0dff9a2ec4f1247b80e17ebd9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3688519
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80950}

Bug: v8:11111
Change-Id: I52caef43e7f2b3921ef34eeb50e41f1dedf90e32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3689570
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80949}

... when allocating Code objects from background thread.

Bug: chromium:1329012, chromium:1330887
Change-Id: Ia2731ba463381c826d14591f4ba3b3fe15d15a0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3688517
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80948}

Using the constexpr {value()} accessor instead of the non-constexpr
implicit conversion operator makes GCC recognize the method as inlinable
again.
Before, we got (shortened):
  heap/heap-allocator-inl.h:167:18: error: inlining failed in call to
  always_inline ‘HeapAllocator::AllocateRaw’: function not inlinable

The issue was introduced by https://crrev.com/c/3683321.

R=mlippautz@chromium.org

Bug: v8:12887
Change-Id: I5879dc0afb23d1d5bb782bf9444703e9cba148f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3688515Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80947}

This was originally part of https://crrev.com/c/v8/v8/+/3662540, but
got accidentally lost during revert and re-roll.

Change-Id: I38097884e50f086e2a71319cf820c628ba736a8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687417
Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80946}

Calling memset directly is faster than std::fill for multi-byte element
types.

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

Port a52b44f0

Original Commit Message:

    Prototype the instruction on the interpreter, and Arm64. Details of
    instruction lowerings on all relevant architectures can be found at:
    https://github.com/WebAssembly/relaxed-simd/issues/52

R=irezvov@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N

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

The {AddOutOfLineTrap} method shows up with several percent of runtime
in performance profiles. The majority of that was spent copying entries
when growing the underlying vector.
Pre-reserving space in that vector removes most of that overhead.

R=thibaudm@chromium.org

Change-Id: I1befb75b070d4f803770c2afcc5c82ffb9bfb522
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3688511Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80943}

Applying the set of unittest changes from
https://crrev.com/c/3678208 to BE.

Change-Id: I02d0f2f388720e3acc35660042d5c2c76fa589e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687474Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#80942}

Fixed: v8:12935
Change-Id: Ib4dfdc276e6a9f465666b068bdbe31776429f359
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687699
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80941}

As the {CompilationTimeCallback} does not react to
{kFinishedCompilationChunk}, it does not need to stay alive after a
"final" compilation event.

Drive-by: Make the enum a boolean enum.

R=jkummerow@chromium.org

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

There are two flag updates from the Wasm C-API. Both are unnecessary:
FLAG_expose_gc is not needed because we call the internal API for
garbage collection; this is always allowed.
FLAG_experimental_wasm_eh is enabled by default, so does not need to be
set to true in that test.

R=jkummerow@chromium.org

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

Extend the effect of --freeze-flags-after-init to also protect updates
of individual flags instead of only the API.
For this, we wrap each flag in a {FlagValue} class which implicitly
converts to the value of the flag. Some cases still require the explicit
{value()} accessor though. That accessor is {constexpr}, in contrast to
the implicit conversion, because otherwise clang emits a lot of warnings
about dead code within "if (FLAG...)" scopes.

R=cbruni@chromium.org

Bug: v8:12887
Change-Id: I87d3457e49ceb317d34d6a21cf09c520d4171eb5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3683321Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80938}

... as a pair of Code and CodeDataContainer.

In order to stop creating and using trampoline Code objects for
builtins we need a different way to represent an "embedded builtin"
code lookup result of builtin trampoline Code objects.
We can't switch to CodeT for this purpose because GC still needs to
be able to locate not yet evacuated Code objects in order to update
old code pointers on the stack once Code objects are moved.

Bug: v8:11880
Change-Id: I296636a6728a11c8e3220b3fee43fd12ff633c1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3684813Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80937}

Bug: v8:12783
Change-Id: Icf9e5b29863a1d4bfc8924ea34476d2a9998c391
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3683322
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80936}

It mostly worked out of the box. Only the dictionary mode prototype
chain walk code paths had to be updated.

Bug: v8:11111
Change-Id: Ia8336964d29304916a34e305f32bb33bb06e211a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3683340
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80935}

This makes some checks a bit stricter to avoid accepting illegal relaxed
SIMD opcodes.

1) The default case in the Liftoff compiler should be UNREACHABLE,
   such that the switch case is required to cover all defined opcodes.
2) The {WasmOpcodes::IsRelaxedSimdOpcode} wrongly also returned {true}
   for opcodes like 0xfd300. We should really check nibbles 3-5 for the
   exact value 0xfd1.
3) {WasmOpcodes::Signature} was returning a non-null signatures for
   illegal opcodes like 0xfd200, because {IsRelaxedSimdOpcode} returned
   false, and then we would just use the lower bytes for the lookup in
   the SIMD signature table.

R=thibaudm@chromium.org
CC=gdeepti@chromium.org

Bug: chromium:1324081
Change-Id: Idbfde570ccd782e59b47b96e7ca8cc28fa7fae98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687309
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80934}

Reason: https://bugs.chromium.org/p/chromium/issues/detail?id=1331309

Reverted commits:

"[compiler] Remove the optimized OSR code if deoptimizing at inside of loop"

https://chromium-review.googlesource.com/c/v8/v8/+/3648219

"[compiler] Add condition use_ic to the removing the optimized OSR code logic"

https://chromium-review.googlesource.com/c/v8/v8/+/3679846

"[compiler] Add out of bytecode array to break condition of removing OSR"

https://chromium-review.googlesource.com/c/v8/v8/+/3686589


Bug: v8:12927, chromium:1330405, chromium:1330452, chromium:1330454, chromium:1330486, chromium:1330545
Change-Id: Idc335e1f6d236a7398b14b64c87da234106bee69
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687695Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80933}

We need to make sure that a fallthrough merge state immediately after an
unconditional deopt is also marked dead. This means rotating the loop so
that we do a first MergeDeadIntoFrameState pass on the current bytecode,
before advancing.

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

The value of the counter is never used, so remove it. This not only
cleans up code, but also makes triggering tier-up a little bit faster
because we do not need to take a mutex any more.

R=ahaas@chromium.org

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

This fully removes the kFinishedTopTierCompilation event, and any
handling of it. In a dynamic tiering world, that event has no meaning
any more.

R=ahaas@chromium.org

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

We introduce a Turbofan pass which optimizes wasm-gc nodes based on
the types of their inputs.

Bug: v8:7748
Change-Id: I281eb0785e9e4201ef925ec201d76dc3d274ad05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3679198Reviewed-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@{#80929}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/234a35b..a568526

Rolling v8/buildtools/third_party/libunwind/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libunwind/+log/5e737be..86ab9dd

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/1cac3de..3a2e446

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/f3d894f..13c50b4

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/393c871..4e79fda

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

Change-Id: I65224d5895760ea6db806a71a3bff944f673ac26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3688471
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@{#80928}