The verbose output shown on bots didn't print the first failing result
of a flaky test before. Now the result line shows all results and
the details in the end show the output of the first failure.

Previously it was confusing as it seemed that the json results and
the test runner output differed.

We now print PASS in all caps like the other statuses. A test for
this case already existed and the output is now updated.

Bug: v8:8434
Change-Id: I473ec392e0028bf64b3da53d4b37446ffcd17277
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2919670
Commit-Queue: Liviu Rau <liviurau@chromium.org>
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74792}

Without the explicit constexpr keyword, Clang seems to be able to treat
these methods as constexpr, whereas MSVC will not.

Bug: v8:11760
Change-Id: I9f6492f38fb50dcaf7a4f09da0bd79c0da6a50eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912916Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74791}

The new functionality is hidden behind the --wasm-gc-js-interop flag.

Bug: v8:11804
Change-Id: I9dd779efe3dbf3c773948b6fd8872e3aea8cd7a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912784
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74790}

Change-Id: I55a80003a148c80f2b7a1f644c127d81963f8ac7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2918141Reviewed-by: Milad Fa <mfarazma@redhat.com>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74789}

Bug: v8:11367
Change-Id: I2d21d3deea73a9930acb3bf2efd3268ec1fd64b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2919830Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74788}

This fixes a compile error in no-wasm / jitless builds introduced in
https://crrev.com/c/2912779.

R=neis@chromium.org
CC=manoskouk@chromium.org

Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
Change-Id: Ia256679dba5093b30821859376aba81b4900efed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2919829Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74787}

This is no longer supported and currently fails later when V8 is
executed if taken, so remove it and fail early during initialization.

BUG=chromium:1208472

Change-Id: I0a1fe947facef0128c6695a4091c5fe8d4c56cc6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2919668
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74786}

ThinStrings are essentially a pointer to an InternalizedString. Read
them concurrently in places where we read InternalizedStrings.

Bug: v8:7790, v8:11791
Change-Id: I3be4dd27336f58706c9c57d5042f96cb8f56bcaa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905608
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74785}

Also change:
- {NormalPageSpace, LargePageSpace}::From()
- ObjectAllocator::*

Bug: v8:11822
Change-Id: I78a1a5379e16fc1e1c95136d7aa8cc34caed0413
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917042
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74784}

This CL adds support for testing web snapshots through mjsunit tests.
To allow for taking and using web snapshots from JavaScript, two
methods, Realm.takeWebSnapshot() and Realm.useWebSnapshot(), are
introduced in d8.

Both of these methods accept a Realm as a parameter, allowing for
mjsunit tests to create and use the snapshot in different realms.

To return the snapshot data, Realm.takeWebSnapshot() creates and
returns a snapshot object with the snapshot data stored as an embedder
field.

Bug: v8:11525, v8:11706
Change-Id: I6e514e10eabf5bdb96d81e2697d4ddc49d92de73
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905610Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Vicky Kontoura <vkont@google.com>
Cr-Commit-Position: refs/heads/master@{#74783}

Port ec4fd32c

Change-Id: Ia952dc6f7478b90dc61ceb029f10feb79243d01d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2918988
Auto-Submit: Liu yu <liuyu@loongson.cn>
Reviewed-by: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#74782}

Inline the SaveFPMode flag directly into the TSANRelaxedStore stubs:
 - Saves one register for input arguments
 - Avoid branches in the TSANRelaxedStore stubs

Bug: v8:7790, v8:11600
Change-Id: Ib1083f8c1a7e856028ff606ba8c2a93efb10db69
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917037Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74781}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/d3e8244..74f9de2

Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/b9af93e..fba2905

Rolling v8/buildtools/third_party/libc++abi/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libcxxabi/+log/767de31..da3e6cb

Rolling v8/third_party/aemu-linux-x64: uDQJbkoDWGwLYtnDu3A7LnRVwsKkaFQkUWtChrVO_hYC..Hf11zqHzrfja2miAIic8j5jVjfs3rcuSFj8vUK-AVYAC

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/7da48e9..3caaaaa

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/51e3708..72bc20e

Rolling v8/third_party/fuchsia-sdk: https://chromium.googlesource.com/chromium/src/third_party/fuchsia-sdk/+log/efa4658..1ea7a15

Rolling v8/third_party/googletest/src: https://chromium.googlesource.com/external/github.com/google/googletest/+log/23ef295..a3460d1

Rolling v8/third_party/jinja2: https://chromium.googlesource.com/chromium/src/third_party/jinja2/+log/11b6b3e..6906af9

Rolling v8/third_party/zlib: https://chromium.googlesource.com/chromium/src/third_party/zlib/+log/5b8d433..e4c7c48

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/a38f01b..d663c27

Rolling v8/tools/luci-go: git_revision:9cd9603def7a649cd3e29517180d6622be2fa898..git_revision:03ab00ce4982877f2d4a0b0db48cd355e5ca65ab

Rolling v8/tools/luci-go: git_revision:9cd9603def7a649cd3e29517180d6622be2fa898..git_revision:03ab00ce4982877f2d4a0b0db48cd355e5ca65ab

Rolling v8/tools/luci-go: git_revision:9cd9603def7a649cd3e29517180d6622be2fa898..git_revision:03ab00ce4982877f2d4a0b0db48cd355e5ca65ab

TBR=v8-waterfall-sheriff@grotations.appspotmail.com

Change-Id: I619a7c566f37c879da74e36601542519cc46c632
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2918435Reviewed-by: 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/master@{#74780}

BranchElimination and CsaLoadElimination interracted badly and created
quadratic behavior when run together. This happened when
CsaLoadElimination kept updating arguments of a Merge, and
BranchElimination kept going through all of them to find the common
prefix of all path conditions. Therefore, we separate BranchElimination
and CsaLoadElimination in the csa and wasm optimization pipelines.

Additional changes:
- Split WasmOptimizationPhase from CsaOptimizationPhase.
- Remove now-redundant argument from CsaOptimizationPhase::Run.
- Fine-grain how statistics are measured in the wasm pipeline.

Change-Id: Id166f4f7d1ea69a1a7b7ca108af4ffedbcda8abb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912779
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74779}

Note that Arm32 is already saving the full register in
https://source.chromium.org/chromium/chromium/src/+/main:v8/src/codegen/arm/macro-assembler-arm.cc;l=2250;drc=ec4fd32cf7f945923fa6bb332c061ecbdaaaa405

Change-Id: I1f5fe60ca350583fb4cb877ccad74f5e260c3665
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912778
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74778}

.. when concurrent-inlining, use direct reads instead.

Two fields were changed to have a non-atomic getter and acq-rel
accessors:

- Map::prototype_info
- PrototypeInfo::object_create_map

Bug: v8:7790
Change-Id: I05e888240d73ab6e961b1048a25713ec45fb0305
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876852Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74777}

For memory accesses that are statically known to be in bounds, avoid the
out-of-line code for the trap handler. This makes trap handler metadata
smaller, reduces code size (by avoiding OOL code), and enables more
optimizations at later phases, because unprotected memory loads can be
reordered and reused.

Drive-by: Use {GetMemoryAccessKind} consistently.

R=ahaas@chromium.org

Bug: v8:11802
Change-Id: Ia824d3355a95f446a796c5b06f69ecaa1500709b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912585Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74776}

This is a reland of 6d99f933

No changes since revert.

Original change's description:
> [compiler] Replace EnsureElementsTenured by IsElementsTenured
>
> We can't mutate heap state from the compiler thread; turn this into a
> predicate and emit generic code if it returns false.
>
> Bug: v8:7790
> Change-Id: I6186a87e178d0c0206b6e7659fa2a41bf65fd835
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876845
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74596}

Tbr: neis@chromium.org
Bug: v8:7790
Change-Id: I9cfdcf9929870a8314486292bab91e83cb448410
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917605Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74775}

This is a reland of 5258364e

No changes since revert.

Original change's description:
> [compiler] Make NativeContextRef never-serialized
>
> Most NativeContext elements are immutable after initialization;
> additionally, we now use acquire-release semantics to load/store
> elements when possible. Reading and constructing Refs for elements
> is thus possible from the background.
>
> A few notes:
>
> - A few elements are not immutable; if read from the background
> thread, these must use acquire-release semantics.
> - Elements can be stored from generated code; these are not compatible
> with bg-thread accesses.
> - While elements can be read safely from the native context, the
> elements themselves may still require serialization; this is done in
> NativeContextRef::Serialize.
>
> Bug: v8:7790
> Change-Id: I12e9611a292e7dd912438c712390731a5422407d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2897254
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74604}

Tbr: neis@chromium.org
Bug: v8:7790
Change-Id: Ica736a4afda2be7276508fe2f734293d0b9eeaf1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917606Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74774}

This changes the test runner to automatically treat cases in which
both a flag and its negation are present as a flag contradiction.
Example: "--foo --no-foo".

With this change it's no longer necessary to explicitly specify these
trivial contraditions in variants.py.

Note: since negations are created through simple string operations,
bogus constructions are possible ("--nobodys-perfect" ->
"--bodys-perfect"). We accept these as unlikely-to-cause-problems.

Bug: v8:10577
Change-Id: Ic52a92ed1e884b495ee4136f6e2f3257cca243c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2904218Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74773}

... to get better error messages.

Bug: v8:7790
Change-Id: I2296e78804e243177a7e984a0284561cd41c61bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917602
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74772}

This reverts commit 916eb869.

Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20gcc/11805/overview

Original change's description:
> Reland "[wasm][bug] Fix a couple of bugs in validation of unreachable code"
>
> This is a reland of 4a037f87
>
> Changes compared to original change: None. This seems not to create
> problems after all.
>
> Original change's description:
> > [wasm][bug] Fix a couple of bugs in validation of unreachable code
> >
> > Changes:
> > - SetBlockType now instantiates the block's start merge with values of
> >   the correct type in unreachable code.
> > - EnsureStackArguments now keeps the existing stack values and moves
> >   them over the new bottom values.
> > - Drop stack size validation in Drop().
> > - Add new tests in unreachable-validation.js.
> >
> > Change-Id: Ie68b3d9abb0a41d1623d4a123fb526e71941c4e7
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2902733
> > Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#74650}
>
> Change-Id: Id620f7fb6677b772b0dcfd38108256384db44439
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905598
> Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74677}

Tbr: manoskouk@chromium.org
Change-Id: Ia24aa453735464bdd3aafca4617beabb0cbf8823
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917601
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74771}

In commit 4a5adb43, mips may allocate a
bit more memory than actually needed, and move the beginning of the
StackSlot in order to have it aligned.

After commit e639eafe, we allocated
the memory that was actually needed, so we do not need extra alignment
anymore.

Change-Id: I4c4c01794ed1d2cc5b8c89196eae6834f0da0b6e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917578Reviewed-by: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Auto-Submit: Liu yu <liuyu@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#74770}

This CL assures builds with "v8_enable_webassembly = false"
compile successfully.

It is an addition on top of this original port:
e73c7b21

Change-Id: Ic27b3006087e4d4de6fe599a9f469d1f80cf8a8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2918136Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74769}

Change-Id: Ia709a1c578d05d722690c57ae44019bda4eb8d5d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2918213
Auto-Submit: Junliang Yan <junyan@redhat.com>
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74768}

Implementation copied from d8. Gated behind a build-time flag.
Can be useful for debugging issues.

Change-Id: I444d625242b1fb8fe9139472a06cb1a90269401a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2906233Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74767}

Change-Id: I795d45a02f49e3a0cc62ce5d87b75a1af7b2dcc1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917913
Commit-Queue: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Auto-Submit: Junliang Yan <junyan@redhat.com>
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74766}

Change-Id: Idb38b9f97b5a507abd6f65f0d6c126255069f979
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917914Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74765}

Fixes an issue with tests mjsunit/compiler/call-with-arraylike-or-spread*
that fail when run with the fuzzer.

Bug: v8:11821
Change-Id: I6b75c065397d66062a7f552198ca92d151d89a4b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917814Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#74764}

For mprotect-based write protection of WebAssembly code memory, we open
{NativeModuleModificationScope}s each time a thread needs write-access
to the code space. While fine-grained switching is good for security
(the permission should only be granted for as short as possible,
especially since it is process-wide), this can degrade performance
considerably for two reasons (we measured up to 10x slower Liftoff
compilation time cf. having no write protection):

1. Switching permissions with mprotect() (and likely with similar
functions on non-POSIX platforms) is just inherently expensive due to
the syscall, modifying page tables, and potentially subsequent TLB
flushes. For a simple benchmark (compiling Unity with --liftoff-only)
--wasm-write-protect-code-memory increases the number of mprotect
syscalls from ~2.6-2.8k to 6-8k (!).

2. Modifying the permissions in {SetWritable()} is synchronized
across threads via the {NativeModule::allocator_mutex_}. With many fine-
grained permission switching requests, lock contention on this mutex
incurs a very high number of futex syscalls (measured on Linux only,
but the problem is likely a general one). For the same simple benchmark
as above (compiling Unity), --wasm-write-protect-code-memory increases
the number of futex syscalls from ~1k to 20-40k (!).

Both problems are fixed in the CL here, following this simple recipe
(in case we get more of these issues in the future):
1. Identify the hot syscall either via sampling-based profiling with
`sudo perf record -g -F10000 d8 ...` (needs sudo for kernel stacks) and
then looking into the record or a flamegraph, or with event-based
profiling with `sudo perf stat -g -e 'syscalls:sys_enter*' d8 ...`.
In particular, if {NativeModuleModificationScope}s are repeatedly
opened (behind a function) in a loop, this can be a problem.
2. Add a scope object outside of the loop, potentially to a function
upwards in the call hierarchy of the hot loop/function.
3. Remove the scope object in the innermost function/hot loop.
4. Check all callers of the hot function (which now no longer has a
scope object), whether additional scopes need to be added there for
correctness.

The following two offenders were especially visible in the profile:
- Most of the mprotect calls were coming from {PatchJumpTablesLocked}.
Pulled the scope object up into {PublishCode}.
- Most of the lock contention was caused by {AddCodeWithCodeSpace}.
There already was a scope object up the call chain in {AddCompiledCode}.
- Fixed scope inside the loop in {FreeCode} for good measure as well.

R=clemensb@chromium.org
CC=​​​jkummerow@chromium.org

Cq-Include-Trybots: luci.v8.try:v8_linux64_fyi_rel_ng

Bug: v8:11663, chromium:932033
Change-Id: I89e4a1f0998f06e4d4b5e360e0bf81836d4240f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912786
Commit-Queue: Daniel Lehmann <dlehmann@google.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74763}

Bug: v8:11804
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel_ng
Change-Id: I81ba1408fb2701450a82c4abc29d2422746af78e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917041
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74762}

Change-Id: I6d2469cdaee5a2c4bf5ce72f8a83a458d4135cc4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917573
Auto-Submit: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74761}

This patch constantize the table size, both for primary and secondary tables, whenever the table size
is known to never change.

By default WebAssebly tables can be grown indefinitely, but producers can specify a maximal limit.
In particular, producers can specify that the initial size of the table also correspond to the
maximum size, in which case the table cannot be grown and the size is constant.

This is a common case, for example when generating WebAssembly from a C++ codebase the list
of indirectly called function does not need, in general, to change at runtime.

Change-Id: I7f6bab60841ee8eb8bdfd996c34513f69b74d5d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912586Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74760}

https://chromium.googlesource.com/external/github.com/tc39/test262/+log/6d353a..d454b8

Bug: v8:7834
Change-Id: I74f4e48b036385a77679b39085125e7a60c90047
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2912917Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74759}

Note: OutOfLineRecordWrite on arm/arm64 only takes "object" and "value"
as arguments. The currently can be the same and thus we don't add any
additional DHCECKs there.

Change-Id: I757d1f3ba9c0d0c5994ecedf26728454e32f41a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2916813
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74758}

This reland is a manual revert of the previous revert
(commit 815bab9f). Manual
due to merge conflicts. No other changes.

Original change's description:
> [compiler] Remove one ObjectRef constructor
>
> Remove the handle-taking ObjectRef constructor in favor of
> (Try)MakeRef as bottleneck.
>
> Bug: v8:7790
> Change-Id: I3cc3a1dcef4bac53a91c573d1a532332b88c6eb4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2883664
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74593}

Bug: v8:7790
Tbr: jgruber@chromium.org
Change-Id: Iafc68f68df06ca9f404427d272b663c218d6550a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917039Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74757}

Switches internals of BasePage and some getters to references that are
guaranteed non-null.

Bug: v8:11822
Change-Id: I484c4451720dc7e04f8b89dbe4fef03a3eaf817e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917038Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74756}

The spec uses the CreateDataProperty abstract operation to add
properties to the result object of Object.fromEntries.

Confusingly, the FastCreateDataProperty Torque macro is special-cased
for adding array element properties instead of generic keyed properties.
The slow path for FastCreateDataProperty goes to runtime, which was
being hit everytime in Object.fromEntries since the result object is not
an array.

This CL switches to using StorePropertyInLiteral instead, which
corresponds to the CreateDataProperty spec operation, and also has fast
paths that stay in CSA.

Bug: v8:11814
Change-Id: I72a6809bde556f0888806307816e200bd47edf8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2915755Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74755}

After https://crrev.com/c/2905605, input type might
also be a register in which case different number of instructions
get emitted. The number also changes if constant pool is
disabled.

Port: 54d84cf3

Change-Id: I9a7adb02de55caebaad552c1e15440c97b4384b0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2914055
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/master@{#74754}

This was missing for transitioning stores.

Bug: chromium:1209558
Change-Id: Ib75d919ef748cffd12f0add09ac2718f434eb684
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2916815Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74753}