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}
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/+/3688511
Reviewed-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/+/3687474
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#80942}
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/+/3687690
Reviewed-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/+/3683321
Reviewed-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/+/3684813
Reviewed-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}
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.orgCC=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}
