Rolling v8/build: a568526..5ef7447
Rolling v8/buildtools/linux64: git_revision:37baefb026b199605affa7bcb24810d1724ce373..git_revision:2f71761a90bdccdb5f4a99e8b231c96aba0967d9
Rolling v8/buildtools/third_party/libc++abi/trunk: c30c515..11395e5
Rolling v8/buildtools/third_party/libunwind/trunk: 86ab9dd..1644d07
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/3a2e446..45853b3
Rolling v8/third_party/depot_tools: 13c50b4..6754c49
Rolling v8/third_party/fuchsia-sdk/sdk: version:8.20220531.3.1..version:8.20220607.2.1
Rolling v8/tools/clang: 4e79fda..a455f33R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: I388c75fffc589bcc2702f9d36fec250a6d6d37c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3691131
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@{#80987}
GCC doesn't accept 'lr' in inline assembly, specifically for the
list of clobbered registers. Change all uses to 'x30', for
consistency.
Bug: v8:10026
Change-Id: I5654fee4ca398dfdd99c34d09fc5294d169a9bd8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3693701
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/main@{#80980}
Port e50d19cb11
Original Commit Message:
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.
R=dinfuehr@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: Ic1a31fad3faaafeab077590d71d6d998eaddcc6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3691128
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#80979}
Mostly in comments, again, not much to be said...
Bug: v8:12425
Change-Id: I6d6c70b4e4dba70ec6ac7574caecc77b65316050
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3693698
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80977}
I noticed in a recent build that C++ files from cctest didn't start
compiling until after several slow non-parallel tasks such as running
mksnapshot and linking v8_for_testing. I don't see any reason that
cctest sources should wait for those tasks, so in this change I propose
adjusting the build dependencies for more parallelism.
Change-Id: I2472117c8555ac397fa1232954c8b699d6429d38
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3690170
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#80976}
When the sandbox cannot be initialized, it's either because there is not
enough virtual address space available, or because there is not enough
memory for the kernel data structures needed for the reservation (this
typically happens on Windows 7/8 where reserving virtual memory is
expensive). Both cases should be reported as OOMs, not CHECK failures.
Bug: chromium:1325302
Change-Id: I17bde9bcd4fbd6e3d54075b8891287c8fb01c1d7
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3688406
Auto-Submit: Samuel Groß <saelo@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80975}
Port: f149912f33
Drive-by: Defined EnqueueFunction under baseline-batch-compiler
for platforms without spakrplug support, currently getting
a link error when making a debug build.
Bug: v8:12887
Change-Id: I4fc8584ef09ad024280f7e40554a5e73a207b64f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3688474
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80972}
Use doubleword load/store to swap values in FPSackSlots instead of word
load/store.
Besides, fix error in gap resolver.
Change-Id: I57e9d577a6001bc970ce6b56b6f890eb3e4d196c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3688325
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@{#80971}
Drive-by: Make the code less verbose my returning the input node from
SetInt32Type.
Bug: v8:7748, chromium:1332385
Change-Id: I2fde9c2168af1365e305e7e8d894b03487e8a8d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687692
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80970}
It is now considered best effort, that in-place internalizable strings
are promoted into the shared old space instead of non-shared old space.
This was previously an invariant, but it doesn't hold if the whole page
containing the shared string is promoted instead of individual objects.
In addition with conservative stack scanning individual objects won't be
moved.
Bug: v8:12007
Change-Id: I7474738b02b0c18080cb2e82268a02bf9b480c40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3688512
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80969}
This build flag was removed in https://crrev.com/c/3314864.
Bug: v8:12470
Change-Id: I365a1914ff096d07ae41d8bf35150615a9c91736
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3676853
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80968}
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/+/3683341
Reviewed-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}
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}
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/+/3547667
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Fanchen Kong <fanchen.kong@intel.com>
Cr-Commit-Position: refs/heads/main@{#80953}
Port commit a52b44f093
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}
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/+/3688515
Reviewed-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}
