This CL applies the following changes:
- a number of redundant DCHECKs have been removed.
- MoveToTempLocation on PPC specifically checks for Simd128
usage even though Simd and Double scratch register numbers are the
same at the moment.
- kScratchReg usage is removed from under AssembleMove in PPC.
- SetPendingMove covers F32/F64 and Simd126 stack and scratch register
usage by AssembleMove using `IsFPStackSlot` and `IsFPRegister`.
Change-Id: I7e4257bb8cc1e66d59cdabe93c113b724cf91c52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4072585
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#84657}
It looks like the server-provided information changed back to what
it was before crrev.com/c/4023861, but rather than just revert that,
this patch makes the logic in our script even more robust.
No-Try: true
Change-Id: I9d60b1c61f85d9bde1275695dbd18c62fa4569bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4080387
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84656}
The test-run mode was broken after output improvements and the
introduction of pathlib.
This fixes the string concatenation with paths and updates the test
output to match the status quo. This also changes the test-run mode
to run exclusively when the --test-run option is passed. Now it's
either a test run or a normal run. Like that we can add the test run
as a separate test step on a bot. If both are needed in sequence
for something, gcmole could be called twice.
Bug: v8:12660
Change-Id: I58179d50950fa76d8f66b974325a8fed84dc91b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075727
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84655}
By applying the same special-case that the Torque builtin already has
to the runtime function.
This is a quick fix pending discussion what the right long-term solution
should be.
Bug: v8:13523
Change-Id: I5303d5ac598d00189f7eb2d9d78b81ad11b919b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075527
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84654}
After a shared GC, trigger all registered callbacks while the global
safepoint is active.
Bug: chromium:1395117
Change-Id: I16c61533d44fbeddda18414d2256203848420a99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079624
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84653}
This is a reland of commit bb288ea342
Changes since revert:
- Skip added test in single generation builds (shared heap is not supported in single generation).
- Use Isolate::Current() instead of GetIsolateFromWritableObject() for strings that reside in shared space (not only if the string is actually shared).
Original change's description:
> [strings] Don't try to record/update invalidated slots in shared space
>
> Strings in shared space are always direct (i.e. they don't contain
> pointers) and therefore cannot have any recorded slots.
>
> Drive-by: DCHECK no slots are recorded in shared space.
>
> Bug: chromium:1394741
> Change-Id: If1ef04d2fadcc14f552f69e99dc109d883e975c9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075908
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84630}
Bug: chromium:1394741
Change-Id: I6889b565f8a247ae1fe553158e29984e7c05563a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079224
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84652}
This isn't enough to run proper mjsunit tests, but it's enough to
compile a simple function like:
function foo(x, y) {
return (~x | y & x ^ y) >> 1 << 1;
}
Bug: v8:7700
Change-Id: Ied109e3e1d841156c964999d6d961644c943bc8c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4080226
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84651}
To handle stack overflow correctly, we need to check for stack overflow
during calls in the caller, before pushing too many arguments onto the
stack.
Handle this in Maglev same as in TurboFan and Sparkplug -- calculate the
maximum size of calls, and use this in the function entry stack check,
rather than checking on each call.
Bug: v8:7700
Change-Id: I521bee3f5386d5100f94142a5054eb9a1434284a
Fixed: chromium:1384403
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079009
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@{#84650}
This (micro)optimizes data dependencies of gcmole in two ways:
1. Only bundle icu folders 'common' and 'i18n', omitting particularly
icu's data and test folder, which aren't needed for running gcmole.
This reduces gcmole bundle size from 377MB to 239MB, reducing upload
and download times by a few seconds on g1 bots.
2. Process gcmole data dependencies during GN time only when gcmole
is configured via gn flag. Currently, the dependency files are also
processed on all other bots that aren't running gcmole.
Bug: v8:12660
Change-Id: Ib708fa2957e6e33698e51b2aee45929f4d467935
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4076331
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84648}
The evacuation threads can't use isolate()->fuzzer_rng() directly
since this class isn't thread-safe. This CL uses this RNG to create
thread-local RNGs for each evacuation thread.
Bug: v8:13549
Change-Id: I3a71617e494ae63fcebc2bab2ee2d7a7714de7bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4078965
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84647}
The OnProfileEndListener callback has to be reset before the isolate
dies to avoid a use-after-free when the Global which holds the callback
gets released.
Drive-by change: make the OnProfileEndListener callback
isolate-specific. At the moment a `profileEnd` call in IsolateA could
trigger the OnProfileEndListener callback of IsolateB, which could
cause all kinds of data races (the callback would access the isolate,
but the isolate is not supposed to get accessed by multiple threads
concurrently. With this CL there is one callback per isolate.
R=clemensb@chromium.org
Bug: chromium:1395237
Change-Id: Ifaa5b883a231f5519a3bfeb6187fb7d8faa02b02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4076465
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84646}
This is a reland of commit 347142f647
This CL fix a bug for bolck onclick event, and improve compatibility
for old turbo-x.json files.
Original change's description:
> [turbolizer] Show basic block id in schedule phase
>
> In the schedule phase of turbolizer, there is only RPO number was
> shown, when we want to debug Builtin PGO or other modules, we
> would like to see the block id instead of RPO number.
>
> this CL add the support for displaying basic block id for schedule
> phase in turbolizer.
>
> Change-Id: I7a71f259230564400b683d598f68b6d064f1eb4d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4068103
> Commit-Queue: Wenqin Yang <wenqin.yang@intel.com>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84625}
Change-Id: Ibaee4826678169d65e809bcad1e29587e480663f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4073861
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Wenqin Yang <wenqin.yang@intel.com>
Cr-Commit-Position: refs/heads/main@{#84645}
The fuzzers based on {WasmExecutionFuzzer} (wasm-code, wasm-compile)
were already switched over in https://crrev.com/c/4042288.
The wasm-async and wasm fuzzers were still testing against the
interpreter, even though WasmGC opcodes are enabled, which leads to
crashes due to incomplete interpreter support.
This CL now switches those remaining fuzzers to "liftoff as reference"
mode, and removes support for testing against the interpreter.
As Liftoff code runs a lot faster than the interpreter, we bump the
limit for the number of executed instructions from 16k to 1M.
R=jkummerow@chromium.org
Bug: chromium:1387316, chromium:1393379, v8:13496
Change-Id: Id3e6177cc89b49e69d03515f10eedaf0872bde82
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4078983
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84644}
For some reason, {OwnedVector} defines both a {start()} and a {begin()}
accessor which return the same value. As {begin()} is the name that the
standard library uses, this CL removes {start()} and switches all uses
to {begin()}.
R=mslekova@chromium.org
Change-Id: Ib505fe146db396f7589404c5a630e19248624729
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075865
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84643}
We already check that if streaming decoding fails, then also synchronous
decoding finds an error. This adds a DCHECK for the other direction: If
streaming decoding succeeds, then also synchronous decoding must
succeed.
R=ahaas@chromium.org
Bug: v8:13447
Change-Id: Iade188ee81b6d3df964f35777d1d3a71350a6811
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4071924
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84642}
The wasm export wrapper passes the expected type as a Smi parameter to
the {WasmJSToWasmObject} runtime function. However, since this wrapper
might be compiled by a different module that is currently running it,
it is not enough to pass the module-specific type index and the module
to reconstruct the type. Rather, we must pass the canonical type
index.
Bug: v8:7748
Change-Id: I84e34e855898477a135f213f07bca10e95ecf49a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4068123
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84641}
The `rep` field of ComparisonOp and EqualOp should be used to know
what is the representation of the things that are being compared,
rather than the output representation: the latter should always be
Word32.
Fixed: chromium:1395737
Bug: v8:12783
Change-Id: I01d29dd598da57bab3410f4b59e407e89871f207
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079223
Auto-Submit: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84638}
This refactors how we generate any decoding errors during streaming
compilation: Instead of generating an error message, we only remember
that decoding failed. After all bytes have been received, we then
synchronously re-validate the bytes. This ensures consistent error
messages between all decoding and compilation pipelines.
In order to achieve this, we now unconditionally store the full wire
bytes in the {StreamingDecoder}. This partially overlaps with the
section buffers that we already store, but we cannot continue filling
section buffers after a decoder error. This will be cleaned up in a
follow-up CL.
We can also remove most of the buffer-offset tracking, which will also
be done in a follow-up.
R=ahaas@chromium.org
Bug: v8:13447
Change-Id: I1d506356de6a0070c3bf2b26470dbf781f4f62e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4066922
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84636}
The chromium-side histogram is being deprecated in
https://crrev.com/c/4076250.
This CL removes the v8-side counter together with the `kAfterBaseline`
sampling mode.
R=ahaas@chromium.org
Bug: v8:12852
Change-Id: If7960824264dfc7e99e0c5c436de1dca90fbce4a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4076167
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84635}
When stopping incremental marking in IncrementalMarking::Stop we can't
blindly reset is_marking_flag_ for worker isolates as incremental
marking in the shared heap might be running at that point.
Since we are already here add a isolate() accessor to
IncrementalMarking.
Bug: v8:13267
Change-Id: Icb63306eef820577d59c6ca833429c1be00d294c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061322
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84634}
... which is an alias for __attribute__((const)) when it's available.
Bug: v8:7703
Change-Id: Ic585f48bc764ccf0c920ff82ba788cf1e88e0cdd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4076525
Auto-Submit: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84633}
This reverts commit bb288ea342.
Reason for revert: Failing on linux debug and TSAN run
- https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20debug%20-%20single%20generation/7820/overview
- https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/22912/overview
Original change's description:
> [strings] Don't try to record/update invalidated slots in shared space
>
> Strings in shared space are always direct (i.e. they don't contain
> pointers) and therefore cannot have any recorded slots.
>
> Drive-by: DCHECK no slots are recorded in shared space.
>
> Bug: chromium:1394741
> Change-Id: If1ef04d2fadcc14f552f69e99dc109d883e975c9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075908
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84630}
Bug: chromium:1394741
Change-Id: I938dcac9cb5c9154ec9a3c5504b29f3208e3e369
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4079145
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#84632}
The safepoint is already initiated by the HeapObjectIterator. In
addition the CombinedHeapObjectIterator wasn't updated for the shared
heap and always used an IsolateSafepointScope which didn't match the
global safepoint initiated by HeapObjectIterator.
Simplify this by relying on the safepoint scope in HeapObjectIterator.
This CL also moves the verification that all client isolates are
fully deserialized into the GC.
Bug: v8:13267
Change-Id: I59eff66a38fd8ecd8e90f68e6ed5abc5d2d4cec9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4076332
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84631}
Strings in shared space are always direct (i.e. they don't contain
pointers) and therefore cannot have any recorded slots.
Drive-by: DCHECK no slots are recorded in shared space.
Bug: chromium:1394741
Change-Id: If1ef04d2fadcc14f552f69e99dc109d883e975c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075908
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84630}
This reverts commit 347142f647.
Reason for revert: <There is a bug for onclick event.>
Original change's description:
> [turbolizer] Show basic block id in schedule phase
>
> In the schedule phase of turbolizer, there is only RPO number was
> shown, when we want to debug Builtin PGO or other modules, we
> would like to see the block id instead of RPO number.
>
> this CL add the support for displaying basic block id for schedule
> phase in turbolizer.
>
> Change-Id: I7a71f259230564400b683d598f68b6d064f1eb4d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4068103
> Commit-Queue: Wenqin Yang <wenqin.yang@intel.com>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#84625}
Change-Id: If6b3674e7bc333be7d323714e3d2ca5327826892
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4078511
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84629}
1) When transferring ArrayBuffers, retain resizability
2) Fix transmitting TypedArray flags; we cannot set the flags after
TypedArray creation, since the map would then be wrong.
Bug: v8:11111
Change-Id: Ic2fa3e6a4db1cb82a3751d2b114353fb477a54c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4064463
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84628}
This is a reland of commit af3678d122
Original change's description:
> [riscv] Add tracepoint instructions to help simulator debug
>
> Change-Id: I92f2c8600ab6ff2be3c0566f8dd5602cb47252cb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4050059
> Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
> Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
> Commit-Queue: ji qiu <qiuji@iscas.ac.cn>
> Cr-Commit-Position: refs/heads/main@{#84441}
Change-Id: If021236afa7f890123f95716e6ed622617b91b07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4074457
Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Commit-Queue: ji qiu <qiuji@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#84627}
In the schedule phase of turbolizer, there is only RPO number was
shown, when we want to debug Builtin PGO or other modules, we
would like to see the block id instead of RPO number.
this CL add the support for displaying basic block id for schedule
phase in turbolizer.
Change-Id: I7a71f259230564400b683d598f68b6d064f1eb4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4068103
Commit-Queue: Wenqin Yang <wenqin.yang@intel.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84625}
The --shared-space flag introduces incremental marking in the shared
heap, this forces us to also emit write barriers for stores into
shared objects.
Bug: v8:13267
Change-Id: I835c3050381cef84e96384fd69a3a77ee588679f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061356
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84622}
This differs from the patch that landed in so far as the libm target
is only defined if v8_use_libm_trig_functions is defined. Doing this
ensures building the 'all' target only builds libm is appropriate.
You can diff between patchset 1 and 2 to see the change.
This is controlled by a gn arg, which defaults to true for clang
builds. I'm limiting to clang builds as the macros for determining
endian type are currently clang specific. My understanding is that
chrome only uses clang. I can update the endian macros if necessary
for other targets.
Bug=v8:13477
Change-Id: I59cd450facc9fcb8987fe56e8cfc1c13522e1f6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4070924
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Auto-Submit: Scott Violet <sky@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84620}
MinorMC's parallel marker was mistakenly using CppMarkingState for the
mutator thread, which caused tsan reports due to pushing into the same
WorkList::Local.
Bug: v8:13475
Change-Id: I640ee23ff643a40910a73eab986795710cec1393
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4076445
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84618}
When invoking RememberedSet::CheckNoneInRange the end address is
exclusive, which means a slot might be recorded at that this address.
Bug: v8:13267, chromium:1395311
Change-Id: I20c23a69530b2c9b10c6213036145c4dcfb206a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075526
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84617}
Rename the vreg allocation to "SetValueLocationConstraints", which is a
more accurate description of what it does. Also, remove the actual vreg
state, since we don't care about unallocated operand vregs (ValueNodes
act as their own vreg).
This allows us to remove a post-processing pass which sets input
constraints for Phi nodes, which previously couldn't do so in the foward
pass due to loop Phis' back-edge inputs not having a vreg yet.
Bug: v8:7700
Change-Id: I24e75f0f600aa5fbd2169a189c0863e4153f3439
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4075529
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84615}
In a local debugging session, it happened to be be in frame 8, so was
slighly missed. Looking through the first 10 frames instead of 7 should
not hurt anyone but fixes that problem.
My stack trace:
#0 __pthread_kill_implementation
#1 __pthread_kill_internal
#2 __GI___pthread_kill
#3 ??
#4 __GI_abort
#5 v8::base::OS::Abort
#6 V8_Fatal
#7 v8::base::(anonymous namespace)::DefaultDcheckHandler
#8 V8_Dcheck
R=leszeks@chromium.org
No-Try: true
Change-Id: I6d8bfb482fe4c926a8ecfad8757286618a98f2c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061894
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84613}
The {async_counters_} field is not used, so we should remove it.
R=ahaas@chromium.org
Bug: v8:13447
Change-Id: I55c335b65f0ab12f8ccc4969741908cb33e1fa8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4067024
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84612}
As Wasm module can live longer than the isolate that initially created
them, it generally makes sense to use the WasmEngine's accounting
allocator for the decoded WasmModule.
Instead of passing that allocator through many functions, we can just
get it directly from the one global WasmEngine when we need it.
R=ahaas@chromium.org
Change-Id: I552f8e19072f2305a3186b821c2f5b3969eac83f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4071464
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84611}
The reasoning around EnsureTagged using known node aspects in merges was
previously broken. Consider the following case:
1. We have a Smi-feedback logical right shift.
2. We emit Int32ShiftRightLogical followed by CheckUint32IsSmi, and we
now know this is a Smi, so we record it in known_node_aspects.
3. We EnsureTagged the Int32ShiftRightLogical value in a merge, when
mergin it with another value.
4. EnsureTagged inserts UnsafeSmiTag (because the shift is a known
Smi), but inserts it _between_ the Int32ShiftRightLogical and
CheckUint32IsSmi.
5. During execution, we get a non-Smi value out of
Int32ShiftRightLogical. The "assert in Smi range" check in
UnsafeSmiTag fails.
In short, this is because we insert the conversion node immediately
after the value node, but th known_node_aspects is, at this point,
reasoning about known aspects later than this.
This patch fixes this by changing the logic around tagging entirely --
instead of EnsureTagged inserting the conversion immediately after the
node, it inserts it at the end of the predecessor requiring the
conversion.
This would mean that the conversion is emitted at the end of _every_
predecessor to the merge; we try to avoid this by additionally storing a
per-predecessor cache of the known_node_aspects at that predecessor's
control node, in particular storing whether there are any existing
tagged alternatives. This cache is checked when creating the Phi,
otherwise we continue using the untagged value. We'll be able to re-use
this cache for non-tagged Phis in the future.
A drive-by is that a bunch of code moves from the
maglev-interpreter-frame-state header to the .cc file -- this is to
avoid cyclical dependencies on between that header and the BasicBlock
one (which we now need for the append of the conversion node).
Bug: v8:7700
Change-Id: Ie441a8c7bd14a14dde8b12f91578f2dc713c4e33
Fixed: chromium:1393232
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4055116
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84610}
