The .ycm_extra_conf.py is out of date with the current build settings
and ycm versions. In particular, ycm expects a `Settings` function,
a couple of more flags need to be passed and some includes are marked
-isystem now. Also, we can use the C++ standard from the ninja files
instead of hard-coding it.
Change-Id: Ibaed29eb341346a86b6b736f95c97b41957f62de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3980257
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Olivier Flückiger <olivf@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84013}
Copy the instanceof fast path from TurboFan, which emits an
'OrdinaryHasInstance' when there is no @@hasInstance symbol (which can
eventually become a constant true/false if we can look through the
prototype chain), and a direct call of @@hasInstance otherwise.
In particular, the call to @@hasInstance requires a continuation builtin
(to call ToBoolean), so add support for these too.
Bug: v8:7700
Change-Id: I14aee4346e98cd650f190b811cc7a733e33addae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3990844
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84012}
Return empty node blocks back to the OS. Keep one block around to
support local allocation/deallocation patterns for up to 256 nodes.
Bug: v8:13372
Change-Id: Ib9e3a1b9a70fa4ad2b52e8479cc46e3c7316cd18
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3973270
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84011}
Before this CL Oilpan young generation didn't support running with
stack. The problem was in initializing stores that don't have the write
barrier. If a GC happens during object initialization, the following
pointer stores can be missed:
struct GCed: GarbageCollected<GCed> {
GCed():
m1(MakeGarbageCollected<>()), // calls GC
m2(MakeGarbageCollected<>()) // old-to-young ref missing barrier
{}
...
};
The CL solves it by recording in-construction objects in a dedicated
remembered-set, which is retraced on next GCs.
Bug: chromium:1029379
Change-Id: I17975e2e2253b2792f71fb64a639e5bdb2ef4935
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3990829
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84009}
The maglev graph builder assumes that values stored on registers were
created while visiting that bytecode, so that it can install the
appropriate lazy deopt information. For value re-use, moving between
registers, we therefore have to use the MoveNodeBetweenRegisters method,
otherwise we get DCHECK failures (and might install incorrect lazy deopt
info).
Fixed: v8:13444
Change-Id: I3b85ca20550f3224811c8505a727c32a500ac5c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3999280
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84007}
The CL (crrev.com/c/2905608) make ThinStrings concurrently readable, but
the condition was set incorrectly.
Change-Id: I1cc2c824f75fde7ec6a2343b8650cdfeb475427c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3973071
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Tao Pan <tao.pan@intel.com>
Cr-Commit-Position: refs/heads/main@{#84006}
This reverts commit 35c0931420.
Reason for revert: Looks like this is regressing our benchmarks (see https://crbug.com/1379440)
Original change's description:
> [tiering] Reset profiler ticks after OSR compilation
>
> After concurrent OSR was enabled, JS execution may stop not at OSR entry
> when concurrent OSR compilation finish. If no more feedback change,
> without reset profiler ticks, OSR urgency is increased from 0 by 1 per
> profiler tick after concurrent OSR compilation finish, it makes new
> OSR compilation can be quickly triggered, reset profiler ticks after OSR
> compilation for triggering the later OSR compilation under the same
> condition with the first OSR compilation. For example:
> for (;;) {
> for (;;) {
> } // OSR entry
> for (;;) {
> <- Executing JS code here when the OSR compilation finish
> }
> }
> 1. We start executing the nesting loop.
> 2. We reset profiler ticks once feedback change.
> 3. If the first inner loop happens to be executing after accumulating
> enough no feedback change profiler ticks, we start concurrent OSR whose
> entry belongs to the first inner loop.
> 4. We continue executing the nesting loop, if no new feedback change,
> increasing profiler ticks again.
> 5. Concurrent OSR whose entry belongs to the first inner loop completes.
> 6. If the second inner loop happens to be executing, without reset
> profiler ticks, we immediately start concurrent OSR whose entry belongs
> to the second inner loop.
> The second OSR code is almost same quality with the first OSR code.
> This CL can reduce OSR compilation amount by ~3.9% (2311 -> 2224) when
> running JetStream2.1.
>
> Change-Id: I4d64cd8963fd2b99d88a3c218841fe5d7c4dc34f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3819421
> Commit-Queue: Tao Pan <tao.pan@intel.com>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83944}
Fixed: chromium:1379440
Change-Id: Icc578316aa259b5e8e4a470cae2106c85594e4ed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3998651
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#84005}
Maps are now in old space, so start to report the first page in old
space now.
Bug: v8:12578
Change-Id: Icf08c9074558a2d47bb9f1f8df72cec9668d2b4e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3986087
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84002}
Before https://crrev.com/c/3054114 we needed to pad the frame size to 4k
so that it fits into a 'sub' instruction as an immediate.
Since frame sizes larger than 4k use special OOL code now, this is not
required any more.
We thus remove the padding to save stack space.
R=ahaas@chromium.org
Bug: chromium:1379364
Change-Id: I155628141d2c0438415ccff36a4de8f7d1ad4fd3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3991050
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83999}
The timeout parameter of WebAssembly's Atomic.Wait is of type I64. There
existed two sets of builtins to pass this I64 parameter from generated
code to a runtime function: one set for 64-bit platforms where the
parameter was passed directly, and one set for 32-bit platforms where
the parameter was passed as two I32 values.
With this CL we first convert the timeout parameter to a BigInt in the
generated code and then pass the BigInt to a unified builtin. Thereby
the builtin can be written completely in Torque instead of CSA.
For I64AtomicWait also the expected parameter is of type I64, so the
same handling is added for the expected parameter.
R=clemensb@chromium.org
CC=manoskouk@chromium.org
Bug: v8:13427
Change-Id: Ia2bb77081cf0db3615d965dbe0e5b97b806a8d1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3990690
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83997}
Compilation job for big function is aborted in compilation pipeline
currently, compilation job for big funciton can be avoided by not
marking optimization. Furthermore, set big interrupt budget for decrease
times of interrupt budget underflow.
Change-Id: I2940f0d5529a665abbfef165b93568e210217082
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3973639
Commit-Queue: Tao Pan <tao.pan@intel.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83996}
Instead of storing the return type in a local variable separately, just
get it from the signature when needed.
R=ahaas@chromium.org
Change-Id: If4c47fb77508b94ed65a2c27abc660e62235d18d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3991015
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83995}
Add "x <= 0 => x == 0" reduction when "x" is uint. This allows x64 to select shorter instructions:
Before:
REX.W cmpq r9,0x0
jna addr
After:
REX.W testq r9,r9
jz addr
This optimization is also ported to turboshaft.
Bug: v8:12783
Change-Id: I87dfd5879c047bb57d30e7a51a309106e3a519ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3967480
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Hao A Xu <hao.a.xu@intel.com>
Cr-Commit-Position: refs/heads/main@{#83994}
An Int32Constant might need to be tagged in Phi boundaries.
This exposes the Graph's smi constants to frames state
merger logic.
Bug: v8:7700, chromium:1378814, chromium:1379571
Change-Id: Ib373b44a76324eeb23cf9fef4483f70160cd54b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3993220
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83993}
Rolling v8/build: 9ce69a9..dad0f9c
Rolling v8/buildtools: c50c0de..74edfb8
Rolling v8/buildtools/linux64: git_revision:11dc0b1f438bd26380774e9d50fd4c63f346d41a..git_revision:a4d67be044b42963de801001e7146f9657c7fad4
Rolling v8/buildtools/third_party/libc++/trunk: 47b3117..37a5b4f
Rolling v8/buildtools/third_party/libc++abi/trunk: c7b6fcf..8dd4051
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/d2c6581..3ffa6b2
Rolling v8/third_party/fuchsia-sdk/sdk: version:10.20221027.2.1..version:10.20221028.1.1
Rolling v8/third_party/instrumented_libraries: 03ce9f0..7410f80
Rolling v8/third_party/jinja2: ee69aa0..4633bf4
Rolling v8/third_party/markupsafe: 1b882ef..13f4e8c
Change-Id: I5f96c730fd4222fb1ad5c64152f3d612aa4ac1e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3988968
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@{#83988}
g++ versions <= 8 cannot use UNREACHABLE() in a
constexpr function. As a workaround a new macro is defined to
instead use `abort` if this feature is not properly handled by the
compiler.
Change-Id: Id6daf02b86c38daa12b7e6f42629091c9833f6fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3988005
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#83985}
... which is now an alias for V8_EXTERNAL_CODE_SPACE_BOOL.
Bug: v8:11880
Change-Id: I6fe3ee1ab7de7820671dc1543b233dbe18bd88d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3990752
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83982}
Extract out a concept of a DeoptFrame from DeoptInfo, which separates
the frame state (like bytecode offset and registers) from deopt
information (like reason and PC).
The DeoptFrame is additionally subclassed to a separate
InterpretedDeoptFrame (with some tagged union magic rather than 'proper'
subclassing so that in the future all DeoptFrames are the same size and
aren't truncated by casting). This way we can add different frames in
the future, in particular builtin continuation frames.
Also this cleans up parent walks, since we no longer walk the caller
state and compilation unit separately.
Bug: v8:7700
Change-Id: I1cecb3ae805c55235b6d74ec114d72de98d3751e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3985914
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83981}
Add types for Number, JSReceiver and Name, and use them to possibly
avoid Check<Type>/To<Type>. Avoid inserting info in the
known_node_aspects when the same info is already available statically
from the node opcode.
Bug: v8:7700
Change-Id: Ie15228e1094ebfc03c83da9f71b1be97806be54d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3986490
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83972}
With --shared-space incremental marking might happen even on pages
in the shared heap. This means that scavengers during incremental
marking might be able to discover shared space pointers that point
to an evacuation candidate.
This isn't possible with the shared isolate where no incremental
marking was supported.
Bug: v8:13267
Change-Id: I68d09fda6d3ec44a488f12f454db4a29b481e266
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3990563
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83971}
This reverts commit e7f6d34cfe.
Reason for revert: Regressions and clusterfuzz bugs
Original change's description:
> [ic] Remove SameValue optimisation for constant fields
>
> We would previously try to preserve field constness if field assignment
> was assigning the same value. It's unexpected that real-life code would
> be assigning the same value multiple times to an intentionally constant
> field, so this was additional bookkeeping with unclear value.
>
> Replace this with not doing it, and considering any write to a constant
> field to convert it to mutable. In particular, this means that stores to
> existing constant fields in TurboFan become unconditional deopts, rather
> than emitting additional code to check whether the value is the same.
>
> Locally, this deopt doesn't fire on our peak-performance benchmarks.
>
> Bug: v8:5495
> Change-Id: I12216c5f10a00f42be32c64ca3afe7cf59b4e7f3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3976516
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83955}
Bug: v8:5495
Change-Id: Ifeeceb773af04e9dd5e069821cd128a1cdbedcf5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3990683
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@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@{#83970}
The following bots were removed or renamed:
v8_fuchsia_compile_rel
v8_linux64_gcc_compile_rel
v8_win_compile_dbg
v8_win64_msvc_compile_rel
v8_mac_arm64_compile_rel
v8_mac_arm64_compile_dbg
v8_mac_arm64_sim_compile_rel
v8_mac_arm64_sim_compile_dbg
v8_mac64_asan_compile_rel
They are all auto-generated as compilators.
Bug: chromium:890222
Change-Id: I893eb06497084976ed0b162ea2e252419c0884b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3988264
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Alexander Schulze <alexschulze@chromium.org>
Commit-Queue: Alexander Schulze <alexschulze@chromium.org>
Reviewed-by: Liviu Rau <liviurau@google.com>
Cr-Commit-Position: refs/heads/main@{#83967}
Rolling v8/build: 4e03165..9ce69a9
Rolling v8/buildtools: ddc9513..c50c0de
Rolling v8/buildtools/linux64: git_revision:3e98c606ed0dff59fa461fbba4892c0b6de1966e..git_revision:11dc0b1f438bd26380774e9d50fd4c63f346d41a
Rolling v8/buildtools/third_party/libc++/trunk: baa43f8..47b3117
Rolling v8/buildtools/third_party/libc++abi/trunk: 519e9ef..c7b6fcf
Rolling v8/buildtools/third_party/libunwind/trunk: 1f633d4..aabcd87
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/2f63d55..d2c6581
Rolling v8/third_party/fuchsia-sdk/sdk: version:10.20221026.0.1..version:10.20221027.2.1
Rolling v8/third_party/instrumented_libraries: f764ffc..03ce9f0
Rolling v8/tools/clang: 87d0b8c..38497db
Change-Id: I2b6f402b468a5607b3cbb347f015ac7634a5492f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3990203
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@{#83965}
Tests flagged as 'raw' need to run without the harness. The language/module-code/eval-gtbndng-indirect-faux-assertion test was failing only because it was running with the harness.
Bug: v8:10958
Change-Id: If00f3ec8abc697d9b3727691e12ae0da7ce8c785
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3984052
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83964}
