Baseline compiler generates instructions for bytecode JumpLoop with
the below layout:
[OSR Check Armed]
[OSR Handle Armed]
[Jump Loop Header]
This CL advances [Jump Loop Header] and the layout will be:
[OSR Check Armed]
[Jump Loop Header]
[OSR Handle Armed]
This can reduce the sizes of loops in baseline code.
Change-Id: I0a3996fddffd33caaef965c05f5c2593ad8951bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3759947
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Hao A Xu <hao.a.xu@intel.com>
Cr-Commit-Position: refs/heads/main@{#81762}
- Avoid adding an Invalid type that can never be reached during
traversal;
- Expose class names as object names;
Bug: chromium:1321620
Change-Id: Ie3d9f78d97703535ecf67d56235d564ab6a9a7e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763866
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81758}
This CL refactors simd load/store to accept a scratch register
which will be used in macro-asm.
LE enforced versions of them is also introduced.
Change-Id: I97f4f4870d7889204b1d42cf50de85e234ecae36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3765514
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#81757}
Previously these values weres stored only in the Code object associated
with the embedded builtins.
Bug: v8:11880
Change-Id: I8adf3f654c5c729a8cb58fc6941999b4c251896a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3764442
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81755}
Currently the same reduction is used for both TypedArray's and
DataView's byte{Length,Offset} accessors. But their behavior differ on
detached buffers: TypedArray returns 0 while DataView throw.
Do not do the optimization for DataViews if we can't depend on the
detach protector.
Bug: chromium:1344549
Change-Id: I38b533a62f756869380cb5c19fe254e03979e81a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763785
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81754}
By about 10x-20x depending on platform and configuration.
Shorter test strings make the set of all possible substrings
considerably smaller.
Fixed: v8:13074
Bug: v8:12868
Change-Id: I46ae94fbcba43080d06b1b825feae6b2acf819d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763861
Reviewed-by: Andy Wingo <wingo@igalia.com>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81753}
Move everything past the Smi check and "pointers-from-here" check in the
write barrier into deferred code. This matches what TF does for
kArchStoreWithWriteBarrier.
Bug: v8:7700
Change-Id: I869e6d5c85c01a3e265abca6cfa6f86066c1ab96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3764443
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81752}
For prototype loads from strings, we require an access check, since
string maps are shared between native contexts. This makes our prototype
constant load optimisation bail out to a generic load.
We can, however skip this check given the knowledge that this is a
prototype load from a primitive, and instead emit a string check. We can
also be a slight bit more tolerant of multiple different string maps,
same as TF.
Bug: v8:7700
Change-Id: I4ad858cadea68246f903443d19fa6cdd65a14564
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762576
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81751}
This CL refactors the implementation of inner pointer resolution, based
on the marking bitmap. MarkCompactCollector::FindBasePtrForMarking has
most of its code that processes the marking bitmap moved to a utility
function FindPreviousObjectForConservativeMarking, which iterates
backwards to find the closest previous object on the page that has been
marked.
Bug: v8:12851
Change-Id: I980ac5712d8b1df792196d77edb9526ca2e13e2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3758227
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81750}
Assembler::CheckBuffer() was defined inline in a header file but without
inline linkage, causing an undefined symbol link error on arm64 macOS.
Fixes: https://github.com/nodejs/node-v8/issues/233
Bug: v8:13055
Change-Id: Ifb638705e95de72b2e8d472e7092e88d77cf8ba8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3749583
Auto-Submit: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81749}
Add the build flag `v8_enable_pointer_compression_8gb` which will enable
aligning all alocations to at least 8 bytes, instead of 4. The build
flag will affect tagged values (Smis and compressed pointers) that are
now aligned to 4 bytes. This new alignment is needed to support larger
V8 cages, with sizes of 8GB and larger.
Bug: v8:13070
Change-Id: I15fe1e0c8e0a105e831b756f502a4fcbf72f45a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3757891
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Teo Dutu <teodutu@google.com>
Cr-Commit-Position: refs/heads/main@{#81748}
As sandboxed pointers are now default-enabled when the sandbox is
enabled, it is no longer possible to deactivate the sandbox at runtime.
This CL therefore removes all the logic that was required to support a
sandbox that could be disabled at runtime, moves the initialization of
the sandbox into V8::Initialize, and deprecates V8::InitializeSandbox.
This change also makes the sandbox initialization deterministic if
FLAG_random_seed is supplied.
Bug: v8:10391
Change-Id: Ibd49f7c251b7c58c642f18a551ecc2c391740970
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/+/3762583
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81746}
Raw data access is already possible via GetBackingStore()->GetData().
This API exposes a more efficient way for accessing
JSArrayBuffer::backing_store (which, despite the confusing name, is no
the BackingStore but its raw data pointer).
Bug: v8:10343
Change-Id: I695cea91e2c3de75ce6c86bac6e413ce6617958b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3764341
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81745}
Duplicate the logic of trying to build Int32 comparisons to also try to
build Float64 comparisons if preceeding a branch. Also, make sure to do
the opposite (emit a tagged value) for the internalized string compare
case.
Bug: v8:7700
Change-Id: Ib34761fa0fdc26d4ad9b6adb960b0b17ec8e1f21
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762582
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81742}
After last refactoring of ETW generation, I introduced a regression
in the method that checks when SourceLoad should happen, and
reverted the condition used to know if a new SourceLoad should
happen.
Bug: v8:12932
Change-Id: I69f5d0700f6af9b124bb0f55750c8d91e56e9e0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762585
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: José Dapena Paz <jdapena@igalia.com>
Cr-Commit-Position: refs/heads/main@{#81741}
This CL adds a new vector scratch reg to PPC (v15)
and uses it during Simd swap operations.
Functions are also changed to accept scratch registers
as input.
Change-Id: I0220504ddf154148d2b83207b42ab2b7a794698c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763863
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#81733}
The header is only slightly refactored:
* function names are slightly shortened,
* global functions and enums are converted to static methods and enums
of a MemoryProtectionKey class.
This is a first step towards adding PKU support for V8 code space.
Bug: v8:13023
Change-Id: Iebcb075b07286d18d6834fbcf6697327f08c9f50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762584
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81732}
This reverts commit 8218c06158.
Reason for revert: compile failures, e.g.:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20release%20builder/11040/overview
Original change's description:
> [wasm] Reset PKRU before spawning new threads
>
> We sometimes hit the DCHECK in the wasm code manager:
> DCHECK_IMPLIES(writable, !MemoryProtectionKeyWritable());
>
> This is because we spawn new threads while having a
> {CodeSpaceWriteScope} open. In the case of PKU, this changes the PKRU
> register to allow writes to the code space, and the value of that
> register is inherited by any new thread. If this thread then tries to
> switch to writable code spaces, it hits the DCHECK. It would hit a
> similar DCHECK when trying to execute code.
>
> We fix this issue by temporarily resetting the PKRU register to
> non-writable while we call the {NotifyConcurrencyIncrease} method. This
> is not a very robust solution, as any new call that potentially happens
> inside a {CodeSpaceWriteScope} needs to do the same, but refactoring the
> code to avoid spawning new threads while being in writable state would
> be a lot of work with other downsides.
>
> R=jkummerow@chromium.org
>
> Bug: v8:13075
> Change-Id: Ibc7270aa597902dc6d9649cb6bcdfce8b1a9bafc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762579
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81729}
Bug: v8:13075
Change-Id: I235e7263856a37cf0f4aa1c27493aac8e6db7910
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763587
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81730}
We sometimes hit the DCHECK in the wasm code manager:
DCHECK_IMPLIES(writable, !MemoryProtectionKeyWritable());
This is because we spawn new threads while having a
{CodeSpaceWriteScope} open. In the case of PKU, this changes the PKRU
register to allow writes to the code space, and the value of that
register is inherited by any new thread. If this thread then tries to
switch to writable code spaces, it hits the DCHECK. It would hit a
similar DCHECK when trying to execute code.
We fix this issue by temporarily resetting the PKRU register to
non-writable while we call the {NotifyConcurrencyIncrease} method. This
is not a very robust solution, as any new call that potentially happens
inside a {CodeSpaceWriteScope} needs to do the same, but refactoring the
code to avoid spawning new threads while being in writable state would
be a lot of work with other downsides.
R=jkummerow@chromium.org
Bug: v8:13075
Change-Id: Ibc7270aa597902dc6d9649cb6bcdfce8b1a9bafc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762579
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81729}
It's flaky in that config, and the failures are not considered actionable.
Bug: v8:12267
Change-Id: Ibc020cd7d28ddda431ec5f79f3c1952a14ffbfa9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3763582
Auto-Submit: Adam Klein <adamk@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@{#81728}
Test was already skipped for quite some time.
Bug: v8:8169
Change-Id: I1cb4f024e43a42c48b425ad0c713fb85bbfb2354
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762580
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81727}
The {std::min} followed by a loop does ensure that the new length is
bigger than {needed_value}, but does not ensure that we always allocate
at least {kInitialLength}. Maybe this was intended to be {std::max}?
Anyway, this CL replaces the loop by a computation which ensures that we
allocate a power of two that is greater than {needed_value} and at least
{kInitialLength}.
It also adds a CHECK to guard against integer overflows.
R=jkummerow@chromium.org
Bug: v8:13063
Change-Id: I374d304204a499536643a6c5df7111231d41d4bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3760674
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81724}
When testing the serializer (e.g. via --stress-snapshot), raw external
references (i.e. just raw pointers) can be embedded inside the snapshot.
When those pointers are sandboxed, the corresponding external pointer
tag also needs to be encoded in the snapshot. This CL adds the necessary
logic to support this by introducing new serializer Bytecodes for raw
external references and encoding the raw pointers together with the tag.
Bug: v8:10391
Change-Id: I7b3710c2144e19f7507e3f6db537d250d102ee28
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/+/3762575
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81723}
This extends the idea already used by "MaterializeMergedConstants":
certain values have to be processed by every br*, so to protect against
cascades of conditional jumps causing lots of repeated work, it makes
sense to do such processing just once.
For the module in the linked bug, this reduces Liftoff generated code
size from 69MB to 181KB.
Fixed: v8:13072
Change-Id: Ie9f98240e93751988067d4774d4a09b2b39bdad6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3760444
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81722}
Avoid materializing a compressed value into a register if that value is
only used for a compare afterward. Instead, emit it directly as an
immediate on the cml. We can only do this for the Cmp(Register,...)
overload, not Cmp(Operand,...), since the latter already has the lhs as
a complex operand.
Change-Id: I99f192c9919e401164d31d2e2e1c3a0c21a6aaf0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762577
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81721}
As sandboxed pointers assume a constant sandbox size (they are
essentially n-bit offsets), it is no longer useful to be able to create
smaller sandboxes. This CL simplifies the sandbox initialization logic
accordingly and adds CHECKS to ensure a fixed-size sandbox is created.
Bug: v8:10391
Change-Id: I6541ab769001e60c0256d3a719f926128a0a20b0
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/+/3647684
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81720}
Use the Operand overload of Cmp to avoid loading the object map into a
temporary in CheckMaps; this also avoids uncompressing the map pointer
when loading it.
It does mean that the migration path of CheckMapsWithMigration has to
re-load the map, and heavier use of the scratch register in that
implementation, but it's a deferred path so that should be ok.
Bug: v8:7700
Change-Id: I6741d5b5a8ad402bdef9025c43a86aca21db050e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3762574
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81719}
