This CL introduces a test runner flag to detect if webassembly has been
disabled. Since all tests that require wasm are alrady skipped in
lite mode, we introduce a has_webassembly flag for the test runner which
checks for v8_enable_webassembly=true and v8_enable_lite_mode=false.
As a drive-by, we also do not set the V8_ENABLE_WEBASSEMBLY
preprocessor flag if lite mode is enabled.
The status files are updated by splitting wasm tests from the
"lite_mode" section and checking for "not has_webassembly" instead.
Note that the v8_enable_webassembly=false configuration is not tested
on any bot currently, but I will make sure that all tests keep passing
on further changes in this configuration.
R=machenbach@chromium.org
Bug: v8:11238
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Change-Id: I1841eb1f1633cb47e0c079f4a4a4d769ca3a9cbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710425
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72898}
Whenever we destroy an object that contains a
(Weak)(CrossThread)Persistent, we call the Persistent's dtor which frees
the relevant PersistentNode. To get the PersistentRegion for the node,
we get the value, then get the the relevant page which holds a reference
to the heap which holds the regions.
During a termination GC there is no marking and no weak callback
processing. That means that, when destroying a Persistent, the page on
which the object referenced by the Persistent resides may have already
been swept and destroyed. Then when we try to get the page we cleared or
unallocated memory and crash.
This issue presented as a sweeper crash in the web tests and
content_browsertests.
This issue affects only Weak(CrossThread)Persistent since the region for
their strong counterparts are already cleared at the start of a
termination GC.
This is not an issue in the Blink impl because (1) Blink finds the
elevant regions through ThreadState without going through pages, and
(2) Blink runs a full GC on termination that includes executing weak
callbacks.
Alternatively we could trace the Weak(CrossThread)Persistent region
which will run the weakness callbacks and clear all WeakPersistents.
The cost and outcome is equivalent.
Bug: chromium:1056170
Change-Id: I3db5b01424500eb695f9876247ef0c787d0d9ef2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2708645
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72897}
Backends do not care about the concrete type, they only need to know the
"kind" (e.g. "ref" or "i32").
In order to prepare Liftoff to use the value kind instead of the
value type for all stored data, this CL moves the kind out of the
ValueType and makes it a top-level enum.
R=manoskouk@chromium.org
Bug: v8:11477
Change-Id: I489d6c5207e6ff1b66e2afbe78a156d66df27eb3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707169
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72896}
Constant reloading of the null reference impacted some wasm-gc
benchmarks. This CL speeds some benchmarks by >5%.
Note: This solution is not ideal as it technically generates invalid
turbofan graphs. It is temporary until a proper optimization eliminating
excessive loads is implemented.
Change-Id: I7afa6fb8857f5dba3dde715bd30fe868ad06d92c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704668
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72894}
The criteria is:
1) Regular method before Unsafe one
2) int index before non-int index
3) TNode<Object> before TNode<Smi>
Bug: v8:6949, v8:11384
Change-Id: I499c835b956f6c92df26882ea37cb48e8fe737c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690592
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72893}
If a StackOverflow is caught, reload the pc and the limit from the
catching frame, not from the target.
R=clemensb@chromium.org
Bug: chromium:1180339
Change-Id: I41bf94e6c7525106e990306913e446f2c4269df1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710436
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72891}
On 64-bit platforms we reserve the maximum size of a WebAssembly memory.
Thereby the memory can grow in-place. On 32-bit platforms, however, we
allocate only the initial size, and grow the memory by reallocating the
memory. Due to memory fragmentation the memory therefore cannot grow
big. With this CL we allow to reserve 1GB of memory even on 32-bit
platforms. Thereby the memory can grow to at least 1GB.
R=gdeepti@chromium.orgCC=ulan@chromium.org
Bug: chromium:1175564
Change-Id: Iba44bb64ffa47322a205e8da3b7088e3edfeee62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707163
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72888}
This patch fixes a segmentation fault which occurs when using `--prof` flag on a Darwin ARM64 architecture.
See https://github.com/nodejs/node/issues/36656
Change-Id: Idc3ce6c8fd8a24f76f1b356f629e37340045b51e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2609413
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72886}
code to keep the RSB balanced
Besides, extract common code to
MaybeOptimizeCodeOrTailCallOptimizedCode
and cache the instance in a register,
Port: af3c5307f0
Port: 89ea44bf41
Port: adf035fb41
Change-Id: I3fde5b0995ea8aa51faeb3fd743cebef748ba745
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710212
Auto-Submit: Liu yu <liuyu@loongson.cn>
Reviewed-by: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Cr-Commit-Position: refs/heads/master@{#72884}
This reverts commit ed225df70c.
Reason for revert: Blocks the roll, causing compile failures in Chromium:
https://ci.chromium.org/p/chromium/builders/try/win_chromium_compile_dbg_ng/800868?
Original change's description:
> [objects] Cache the ExternalString's data in its resource
>
> For external uncached strings (also called "Small External Strings")
> with cacheable resources, we can cache its resource's data at the
> string's creation time. This allows us to safely read the data from the
> background as we wouldn't trigger a data() callback.
>
> For more information regarding the investigation and possible proposals
> see
> https://docs.google.com/document/d/101eAQqFpBPWFGNJicxtdlwYShJkTOUsEuxkVVeu5Hrk/edit?usp=sharing
>
> Bug: v8:7790, v8:11463
> Change-Id: I6164092b01a6ccb525a9516f476e066b35fb1f96
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685177
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72862}
Bug: v8:7790
Bug: v8:11463
Change-Id: I1d14c2f9872d156d43d5d95c8a032a37ba9379cb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2708824
Auto-Submit: Bill Budge <bbudge@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72880}
Use a slightly different instruction sequence for AVX, these
instructions issue to different ports, resulting in less resource
pressure. Full details in the bug.
Bug: v8:11464
Change-Id: Ie915a532f7453bab5c458038e8da725aa0e5d55b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2703451
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72879}
Port b57a0d190a
Original Commit Message:
Extract code sequence into macro-assembler for reuse between Liftoff and
TurboFan.
There is a bit of register-aliasing checking due to the rather strict
requirements for the code sequence depending on the CpuFetures that are
supported.
R=zhin@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: Ia7c8adf67ea04eda43966effe71919334da10b58
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2705157
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#72876}
Extract code sequence into macro-assembler for reuse between Liftoff and
TurboFan.
There is a bit of register-aliasing checking due to the rather strict
requirements for the code sequence depending on the CpuFetures that are
supported.
Bug: v8:11415
Change-Id: Idbc0ca43475db5650d1747c8a741e9f11b80d8e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698063
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72875}
We always built a new Phi node for the delegate merge, which is
incorrect when the target block's exception is already a Phi. Use
CreateOrMergeIntoPhi instead.
R=clemensb@chromium.org
Bug: v8:11472
Change-Id: I8af3ab07d536ddfe247ace04cc844207d32adb99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707167
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72874}
Forced GCs are used in testing configurations and under memory
pressure. Use atomic sweeping for C++ in those scenarios as testing
GCs require that destructors are immediately invoked after the GC
call.
Bug: chromium:1056170
Change-Id: I03c13fa7a30cf74076807834c5e6d0c1fe52bb87
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704543
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72873}
We had an off-by-one in the arm64 frame fill code due to double counting
the register already pushed by the prologue.
Bug: v8:11420
Change-Id: I9b4a3bcdc913886f0ba7a316f23f41eed3fc9311
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707168
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72872}
This is the first part of exception handling support in Liftoff. For
now, the only supported instruction is throw, and only with empty
payload or only i32 values.
R=thibaudm@chromium.org
Bug: v8:11453
Change-Id: I9fdf1328ef46655674a05186fb93216518886d03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704659
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72871}
Functions are easier to maintain and to debug than macros, hence
transform the macro into a function.
R=thibaudm@chromium.org
Bug: v8:11384
Change-Id: I6a5a836e14c33dc3c2240b6b06edcb05c6514710
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704074
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72870}
Code objects are exposed through JSFunction and SharedFunctionInfo.
If they are builtins, we don't have to worry about background threads
seeing partially initialized code objects. If they are optimized code
objects, we may. Background threads read the code fields with
AcquireLoad semantics. The fields are set on the main thread with
ReleaseStore semantics when appropriate.
Special care is taken when setting an optimized code object in a closure
in the interpreter entry stub. Since the MacroAssembler doesn't support
ReleaseStore semantics, this CL ensures that the optimized code object
is stored with those semantics in the feedback vector, where the
interpreter entry stub finds it.
Bug: v8:7790
Change-Id: I41ecedfe0e9d1ad5091cbe9a97f66c66ca9e07dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676633
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72869}
This fixes a build failure when compiling swiss-hash-table-helpers.h
on an SSE platform for a non-SSE target.
Change-Id: Ifc9bfc6b31d84d0e5dcc544a8eee8d6ea6e0cd12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704675
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Frank Emrich <emrich@google.com>
Cr-Commit-Position: refs/heads/master@{#72868}
We can remove some of the method definitions, as well as the
sloppy-ness from the method.
Bug: v8:6949, v8:11384
Change-Id: I04880daa3fcce097b79009f12bd24128a47c2c80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2690591
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72867}
The interface descriptor can be looked by via the builtins name, hence
we do not need the template parameter. This also removes redundancy (and
potential errors) for passing the builtin name twice, via the template
parameter and a function parameter.
R=thibaudm@chromium.org
Bug: v8:11384, v8:11453
Change-Id: Id4184a371e8ab8a66ff0b4eb65b4bd87f285149e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704172
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72866}
Allocate an array big enough to store label data for each byte in the
bytecode array. Use a linked list to store linked labels, and combine
the list with a pointer for an unlinked label.
Bug: v8:11429
Change-Id: Iadf00801f6ddd4460f7e0e1b53eee7be333f66e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704542
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72865}
In {MergeFullStackWith}, we were accidentally looking at the cached
instance in the current {cache_state_} instead of the state passed as
{source}. This could lead to missing reload of the instance after a
conditional branch.
R=thibaudm@chromium.org
Bug: chromium:1179182
Change-Id: Ida3c06491f7973a183c43745159abbf6aa8a058b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704081
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72864}
Change the frame fill to unconditionally subtract already pushed
registers from register count. This ensures that the decision to add a
push loop is dependent on the _remaining_ registers, not the _total_
registers.
Bug: v8:11420
Change-Id: Ide763654e66f0a8c827a00fca1b4a77be2052f76
Fixed: chromium:1179595
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704672
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72863}
For external uncached strings (also called "Small External Strings")
with cacheable resources, we can cache its resource's data at the
string's creation time. This allows us to safely read the data from the
background as we wouldn't trigger a data() callback.
For more information regarding the investigation and possible proposals
see
https://docs.google.com/document/d/101eAQqFpBPWFGNJicxtdlwYShJkTOUsEuxkVVeu5Hrk/edit?usp=sharing
Bug: v8:7790, v8:11463
Change-Id: I6164092b01a6ccb525a9516f476e066b35fb1f96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685177
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72862}
This reverts commit 76a2ab06a1.
Reason for revert: A few issues, e.g.
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8854931126653780144/+/u/Check__flakes_/ArrayWithCowElements
Original change's description:
> [compiler] Direct heap reads for JSArrayRef
>
> There are two aspects to the non-JSObject parts of JSArrayRef:
>
> - JSArrayRef::length. Relevant only in two spots, 1. when reading
> (immutable) array boilerplates and 2. for GetOwnCowElement.
>
> - JSArrayRef::GetOwnCowElement. May read into a copy-on-write backing
> store. Relies on the invariant that cow backing stores are immutable.
>
> This CL renames the length accessor to length_unsafe to make the
> danger explicit at callsites.
>
> For GetOwnCowElement the refactor is slightly larger, since we now
> need to read into the backing store while keeping full control of
> object reads (e.g. JSArray::length and JSArray::elements_kind). We
> make all reads explicit at the call site by requiring that elements,
> elements kind, and length are passed in as arguments to
> GetOwnCowElement. Inside GetOwnCowElement, consistency between these
> is *not* guaranteed due to concurrency. At runtime, consistency *is*
> guaranteed through the reference-equality check on the elements seen
> during compilation. The actual elements read is implemented in
> ConcurrentLookupIterator::GetOwnCowElement.
>
> Bug: v8:7790
> Change-Id: I9aa169ce4f2b1e2bfe1e9232007669eb7654a995
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695403
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#72834}
Bug: v8:7790, chromium:1180012
Change-Id: I50e72380c544b2b78e1e3dc87a8249281b710912
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704666
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72860}
The StackGuard in the sparkplug prologue builtin on x64 was called with
the frame in a weird state; in particular, the baseline code PC wasn't
on the stack. This could lead to oddities like the baseline code getting
collected by a GC during the interrupt.
Now we push the baseline code return address and set up a proper frame
for the interrupt.
Bug: v8:11420
Change-Id: I03b4c2f2d204ad413c5f54f9e8fc28182edf9085
Fixed: chromium:1177219
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704658
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72858}
This is a reland of
https://chromium-review.googlesource.com/c/v8/v8/+/2688058
This CL is part of a series that adds the C++ implementation of
SwissNameDictionary, a deterministic property backing store based on
Swiss Tables.
This CL adds the initialization code, factory functions and a
canonical SwissNameDictionary plus all helpers required for that.
Bug: v8:11388
Change-Id: I9cf66a3fa755288f7730f55abfb6e6cea82f6b03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2703653
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72857}
This reverts commit f731e13f00.
Reason for revert: perf regressions, chromium:1179757
Original change's description:
> Remove 'length' field from ScopeInfo
>
> ScopeInfo has a vestigial 'length' field from when it used to be a
> FixedArray. This change removes that field, which saves some memory.
>
> More specifically:
>
> - Make ScopeInfo inherit from HeapObject, not FixedArrayBase which
> supplied the 'length' field.
> - Privatize the FixedArray-style functions that provide access to
> ScopeInfo fields by index, and move them from scope-info-inl.h to
> scope-info.cc. Those functions are still used pretty heavily during
> initialization (ScopeInfo::Create, etc.), but at least we can avoid
> presenting them to the rest of the world.
> - Change FactoryBase::NewScopeInfo to allocate the updated object shape.
> It maintains the existing behavior of filling the newly-allocated
> object with undefined, even though that's not a valid ScopeInfo and
> further initialization is required.
> - Move part of AccessorAssembler::ScriptContextTableLookup into a new
> Torque macro, because it used to rely on casting ScopeInfo to
> FixedArrayBase.
> - In V8HeapExplorer::AddEntry, don't claim that ScopeInfo objects are
> arrays. I think it makes more sense to list them under "(system)" in
> the dev tools, like most other V8 internal types.
>
> Bug: v8:8952
> Change-Id: I8278e3a90027d4409f0d268da0fe7080754c6b8c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2601880
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72830}
Bug: v8:8952
Change-Id: I00a69da79e5ac6aaae4436a41ce773ae014cc775
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2706086
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Seth Brenith <seth.brenith@microsoft.com>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72855}
Rolling v8/build: 99c7b26..d9000c9
Rolling v8/third_party/aemu-linux-x64: X81JiseHcDpE_0A4yjc6A232-BwI6vJSzYlXeAnpNwcC..SesU5Vh9_5Zm4yE0Qtuyv2VQ8UhCuhRMW3IkFgT7n0sC
Rolling v8/third_party/depot_tools: 5e37f6d..f362f6f
Rolling v8/tools/clang: 9990265..6cf138c
Rolling v8/tools/luci-go: git_revision:77944aa535e42e29faadf6cfa81aee252807d468..git_revision:fd10124659e991321df2f8a5d3749687b54ceb0a
Rolling v8/tools/luci-go: git_revision:77944aa535e42e29faadf6cfa81aee252807d468..git_revision:fd10124659e991321df2f8a5d3749687b54ceb0a
Rolling v8/tools/luci-go: git_revision:77944aa535e42e29faadf6cfa81aee252807d468..git_revision:fd10124659e991321df2f8a5d3749687b54ceb0a
TBR=v8-waterfall-sheriff@grotations.appspotmail.com
Change-Id: Id952af26eb7019ac2603e8f8ad94e93e1fe47300
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2706521
Reviewed-by: 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/master@{#72852}
We can use UseScratchRegisterScope instead of requiring a
TempSimd128Register in the instruction-selector. This reduces register
pressure a little bit (when combined with unique register constraints).
Drive-by cleanup of some variable names in code-generator, s/tmp2/tmp/
when there is only 1 tmp.
Bug: v8:11384
Change-Id: I00a365624cbabeaeeaf78d1d08f0eb284c7e44ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2705523
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72851}
The atomic pause would not report any marked bytes which in turn would
mean that the used bytes counter would stay at 0 for testing GCs that
always use atomic marking.
Bug: chromium:1056170
Change-Id: Ie35d9b3bc88766c4ef56271f05d944f4835ba431
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704662
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72850}
My recent change https://crrev.com/c/v8/v8/+/2698057 changed the size of
bytecode for most functions, and attempted to update other heuristic
values to match. However, it caused V8 to be slightly too eager to
perform on-stack replacement in JetStream 2's gaussian-blur test case,
so that the function got compiled separately for each of two nested
loops rather than just once for the outer loop. This is the smallest
change that restores the previous behavior in that benchmark.
Bug: chromium:1179571
Change-Id: I03e98d6bff7355b775c1fdaf495e7444e7c6f095
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704882
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72849}
