As this is a unary operation src operands must be the same.
Change-Id: Id6e3b11fdb942596c05c38591379e6d9fd71f19e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332865
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#69234}
This test uses a i64x2.shr_s to shift a v128 with all bits set by 1,
resulting in v128 with all bits set (no change). This value is then
dropped, and param[2] (3), is returned.
Without the fix, -1 is returned, since i64x2.shr_s overwrites the
register for param[2] with 0xffffffff.
Bug: v8:10752
Bug: chromium:1111522
Change-Id: I0310bf6039be780a6738689069cdbcfa3a24bbdb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335779
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69233}
We can use r0 itself without the need of loading it with "0",
if it is used as the first input of MemOperand.
Change-Id: I71aafea8bba098f925c55eb9127c6b37ac37cb7b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332864
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#69232}
Swizzles are shuffles that only use values from 1 operand, e.g.
v8x16.shuffle 0 1 2 3 0 0 0 0 4 5 6 7 0 0 0 0 (all the values are < 16).
Match such patterns and emit an optimized codegen that uses less
registers and instructions. Only implemented for x64 for now, the other
backends will come in follow-up patches.
Bug: v8:10696
Change-Id: Iffa694b04c97313eab7d138e4bdad7c0c85cda89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335419
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69231}
Add safepoints to GC methods in Heap. There is still stuff in
Heap::CollectGarbage which might work better or more precise in a global
safepoint. Be conservative here and move everything into the safepoint,
eventually we can start to move code out that is fine to run outside
the safepoint.
Bug: v8:10315
Change-Id: I656dfd72f032eff6f386cec63a02777506650aa7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335192
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69228}
Only expose top-level functions for DefineOutputs and AllocateRegisters in
the mid-tier register allocator, rather than exposing the MidTierRegisterAllocator
object, to be in-line with AllocateSpillSlots and PopulateReferenceMaps.
BUG=v8:9684
Change-Id: I93dcff77f5e50dab9b373b4415029361078d58e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2323361
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69226}
This ensures that large object has exactly the size of a regular page.
Avoids wasting memory due to alignment.
Bug: v8:10315
Change-Id: Ife8051313f1ea8c1fc0ba0afcc4e5db11f27adca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335191
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69225}
LocalAllocationBuffer is used on the background thread so it needs
to use CreateFillerObjectAtBackground for creating filler objects.
Bug: v8:10315
Change-Id: Ifc22d87e1e835cfdd65d82fc79b20ee74b2c87b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336795
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69224}
Add functionality to emit an event upon double
clicking on an event type on the timeline track
selected entries panel.
Bug: v8:10644
Change-Id: I54d4397abfeab471f01c2b24bae4eb1ff705afcd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2328787
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Cr-Commit-Position: refs/heads/master@{#69222}
Test now passes even if RO_SPACE sharing is enabled.
Bug: v8:10454
Change-Id: Ic7377c3367199383bb6a96a9beedcc52bbc3362f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335184
Commit-Queue: Dan Elphick <delphick@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69221}
This was wrong because ObjectBoilerplateDescription is a subclass of
FixedArray. The wrong order didn't cause problems because we explicitly
call the ObjectBoilerplateDescription constructor in the places that
matter.
Bug: v8:7790
Change-Id: I63b6b8741472862d2b1b9b843d7aa2490c620f87
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335180
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69219}
Let StressConcurrentAllocatorTask allocate small, medium and large
objects to test different code paths.
Bug: v8:10315
Change-Id: Ifff7e91bc95f0d926a58321b481183e9acf8bd32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335182
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69217}
This is a reland of b354e344fd
This CL adds 3 fixes:
* Unprotect code object before creating filler
* Allows AllocationObserver::Step to add more AllocationObservers
* Update limit in NewSpace::UpdateLinearAllocationArea
Original change's description:
> [heap] Refactor allocation observer in AllocationCounter
>
> Moves accounting of allocation observers into the AllocationCounter
> class. This CL removes top_on_previous_step_ for counters that are
> increased regularly in the slow path of the allocation functions.
>
> AdvanceAllocationObservers() informs the AllocationCounter about
> allocated bytes, InvokeAllocationObservers() needs to be invoked when
> an allocation step is reached. NextBytes() returns the number of bytes
> until the next AllocationObserver::Step needs to run.
>
> Bug: v8:10315
> Change-Id: I8b6eb8719ab032d44ee0614d2a0f2645bfce9df6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2320650
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69170}
Bug: v8:10315
Change-Id: I89ab4d5069a234a293471f613dab16b47d8fff89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332805
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69216}
A minor refactoring to the logic for triggering callbacks:
1. If compilation failed, do only trigger the kFailedCompilation event.
2. Use the TriggerCallbacks method also for triggering the
kFailedCompilation event.
R=thibaudm@chromium.org
Bug: chromium:1101340
Change-Id: I3446d708d28068448e6eca3e637c9af673f5311d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332171
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69215}
In preparation for adding new NCI (and TP) code kinds.
- Free the unused bit in Code::flags.
- Be more precise about the flag field sizes (int32 instead of int).
- Add and refactor related static asserts.
Bug: v8:8888
Change-Id: Ice0d4df9de528de77dfb5c04279cfdc4b030efc9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2328788
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69213}
The DevTools front-end uses so-called Wasm evaluator modules to get to
the values of variables in scope when the wasmDWARFDebugging experiment
is turned on. We rely on the `Debugger.executeWasmEvaluator()` method in
the Chrome DevTools Protocol (CDP) to accomplish this, which in turn is
controlled by this global flag.
Since we intend to gather more feedback from selected internal /
external teams on the DWARF debugging experience, we need to ship this
flag by default to make it easier to test the new experiment without
having to fiddle with additional flags to pass to Chrome on the command
line (and asking folks whether they really started Chrome correctly).
Bug: chromium:1041362
Change-Id: I1e170383fa7a34c41eec8c4867c38b7d8e871e8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335072
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69212}
I tripped over this str/bytes issue as part of bringing up the
Chromium build under Python3.
Bug: chromium:1112471
Change-Id: I723c7d9df8bcac24c160c549a03dcbd34c1d92f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2334222
Commit-Queue: Dirk Pranke <dpranke@google.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69210}
x64's implementation of i64x2.shr_s was overwriting the scratch
register. kScratchRegister is used to hold the extracted lane of the
SIMD register, but in certain cases [0], is also used to back up the
value of rcx. When this happens, the supposed backed-up rcx was
overwritten (definitely) by each extract lane, so we end up restoring
an incorrect value of rcx, leading to an eventual crash in certain
benchmarks, when this extracted lane was used as a memory operand (see
linked bugs).
[0] when register holding the shift value is not rcx, which sarq_cl
relies on
Bug: v8:10752
Bug: chromium:1111522
Change-Id: Iaf3264e16f94e78bad4290783757f0b722d40411
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2334354
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69208}
This is a stop-gap solution (while we wait for a proper spec)
that lets managed WasmGC objects perform round-trips through
JavaScript. On the JavaScript side, they appear as empty/opaque.
Bug: v8:7748
Change-Id: I0dd368bc14d622f3ef41871484228267359e9b5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316306
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69207}
After allocating a new code space, we do some initial allocations in the
new space (e.g. for the jump table). These allocations are not allowed
to fail.
If this in indeed what's happening in the linked bug, this CHECK will
give fuzzers a chance to find us a reproducer.
Drive-by: Introduce {WasmCodeAllocator::kUnrestrictedRegion} to remove
magic constants.
R=ahaas@chromium.org
Bug: v8:1111266
Change-Id: Ia76721653226bd4aa346b89ffab0c80f67892794
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2333250
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69204}
If we cancel the task in the thread where it's supposed to run,
task cancelling will always succeed.
This simplifies the logic.
Bug: v8:10239
Change-Id: I3fb5c93a49c52d958aa947d693700161bc18eee5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332807
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69203}
The majority of the content is the Atomics.waitAsync implementation
which I wrote.
"git blame" shows I've touched 123 / 274 lines in futex-emulation.h and
551 / 875 lines in futex-emulation.cc.
(Status before https://chromium-review.googlesource.com/c/v8/v8/+/2319989 which was moving
code around.)
No-Try: True
Change-Id: Ib31dc0bb778aed90d5c4c56ccb0e556655ce6946
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332813
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69202}
... since it's still a valid index.
Change-Id: I498ff27898cefa5df752ac0ad73408ce76ac06c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2327911
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69200}
Adds support for non-simple fp aliasing (e.g., Arm) for the fast
register allocator.
BUG=v8:9684
Change-Id: I6717ef1c6cb4e585fa4b6ea8cea7087e68f441e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2300483
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69198}
Allow the allocation of large old space objects through
LocalHeap::AllocateRaw. OldLargeObjectSpace::AllocateRawBackground will
allocate a large object on the background thread.
Bug: v8:10315
Change-Id: I9212f0c6770855dbe33490516aae7056987e192d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332804
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69195}
LocalHeap::AllocateRaw will be similar to Heap::AllocateRaw and
handle all allocations. LocalHeap::AllocateRawOrFail will perform a GC
and afterwards retry the allocation in a loop.
Bug: v8:10315
Change-Id: I68468962cf9102697aa547b2aa05c7ec6bafd19e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332801
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69193}
Bug: v8:7790
Change-Id: Ie296b0bcc6c3b26be5ad54f4558a75250a2f2157
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332232
Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69191}
Chrome is currently adding a 128-bit V8ContextToken to keep track of
V8 contexts across multiple isolates and processes. Having per-isolate
token exposed by V8 leads to confusion of these two tokens.
This moves v8::Context::Token to v8::metrics::Recorder and changes
the corresponding functions:
- v8::Context::GetToken => v8::metrics::Recorder::GetContextId
- v8::Context::GetByToken => v8::metrics::Recorder::GetContext
This CL is purely mechanical and does not change the behaviour.
Bug: chromium:1101749
Tbr: clemensb@chromium.org
Change-Id: I31bbfa02ebab1c0d91b00f0d08c1b236392d14d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2330023
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69188}
This reverts commit b354e344fd.
Reason for revert: Clusterfuzz found issues with this CL.
Original change's description:
> [heap] Refactor allocation observer in AllocationCounter
>
> Moves accounting of allocation observers into the AllocationCounter
> class. This CL removes top_on_previous_step_ for counters that are
> increased regularly in the slow path of the allocation functions.
>
> AdvanceAllocationObservers() informs the AllocationCounter about
> allocated bytes, InvokeAllocationObservers() needs to be invoked when
> an allocation step is reached. NextBytes() returns the number of bytes
> until the next AllocationObserver::Step needs to run.
>
> Bug: v8:10315
> Change-Id: I8b6eb8719ab032d44ee0614d2a0f2645bfce9df6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2320650
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69170}
TBR=ulan@chromium.org,dinfuehr@chromium.org
Change-Id: Icd713207bfb2085421fd82009be24a0211ae86da
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10315
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332667
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69187}
