This reverts commit 656c74218f.
Reason for revert: crbug.com/v8/13715
Original change's description:
> [liftoff] Combine "InitMerge" with the actual merge
>
> "InitMerge" did compute the state at the merge point, and a following
> "MergeStackWith" or "MergeFullStackWith" would then generate the code to
> merge the current state into the computed state.
> As every "InitMerge" is followed by an actual merge, we can combine the
> two and save one iteration over the two states.
>
> The only change in generated code is that we initialize the merge state
> after a one-armed if from the if-state instead of the else-state. This
> could potentially make the if-branch slightly cheaper and the
> else-branch slightly slower, but will not negatively impact overall code
> size.
>
> This CL should save roughly 2% of Liftoff compilation time.
>
> R=dlehmann@chromium.org
>
> Bug: v8:13565, v8:13673
> Change-Id: Id323a15e7fd765727f46830509fbaf7f5498c229
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4203380
> Reviewed-by: Daniel Lehmann <dlehmann@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#85616}
Bug: v8:13565, v8:13673, v8:13715
Change-Id: I5342833aaa9c8665a514b3702eaf783d512dfa5f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4222633
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#85659}
Port 81aa89592b
Original Commit Message:
Known-pointer decompression used to be distinct from any-tagged-value
decompression, since the latter used to detect Smis and decompress them
with sign extension. However, we got rid of this distinction when we
introduced Smi-corrupting loads (allowing the top 32-bits of
uncompressed Smis to be undefined), which means that the TaggedPointer
and TaggedAny decompression is now identical.
We can remove a bunch of duplicate code by removing this distinction.
R=leszeks@chromium.org, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N
Change-Id: Ib741905e09c929806cf3f584c356a4a5187df270
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4221514
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#85658}
The last CL miscalculated the address of Isolate object. We should find the thread_local base address using `_tls_index_`. And, instead of calculating the address manually, all the location information is already available in `Location`. So, we can simply use the Location object to create a typed object.
Also, adding a testcase for `curisolate()` function.
Bug: v8:13394
Change-Id: I1da55bdf43a3b6100d141917eb97a1793939dca8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4220104
Reviewed-by: Seth Brenith <seth.brenith@microsoft.com>
Commit-Queue: Choongwoo Han <choongwoo.han@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#85654}
After a MinorMC we iterate over the set of young external strings,
finalize the unmarked ones, and clear their slots.
Since MinorMC no longer updates the young string set (to avoid iterating
over the set during evacuation) it may now contain an old string.
If after promoting an external string from young to old, we get another
MinorMC cycle before we get a full GC (that will "reset" the young and
old string sets), the next MinorMC cycle may treat the promoted string
as unreachable. This is because the string is in old space are is
therefore left unmarked.
Bug: chromium:1412669, v8:12612
Change-Id: I1cacc25b74d9d3dd221c0cc1f0d8b4c4eb83a04d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4219106
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85653}
This is a reland of commit 0d4200055b
gn complained about headers that are only included behind the
v8_use_perfetto build flag. Added "nogncheck" to suppress this
warning.
Original change's description:
> Reduce build size when building with Perfetto SDK
>
> Building Chromium with full Perfetto SDK included increases build time
> significantly. We can reduce this overhead by including only those
> parts that are required. See b/266913150 for context.
>
> Change-Id: I0cde5cb7df7b6151ec686e993488d8467c416fac
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4212390
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Mikhail Khokhlov <khokhlov@google.com>
> Cr-Commit-Position: refs/heads/main@{#85603}
Change-Id: Ifdcc9983230b5e7bab5f66a37f193d2cee698400
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4221573
Commit-Queue: Mikhail Khokhlov <khokhlov@google.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85650}
This reverts commit 2e357c4814.
Reason for revert: Speculative revert for https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Clusterfuzz%20Linux%20MSAN%20no%20origins/33231/overview
Original change's description:
> [wasm-gc] Introduce wasm null object
>
> We introduce a wasm null object, separate from JS null. Its purpose is
> to support trapping null accesses for wasm objects.
> This will be achieved by allocating a large payload for it (larger than
> any wasm struct) and memory-protecting it (see linked CL). The two null
> objects get mapped to each other at the wasm-JS boundary.
> Since externref objects live on the JS side of the boundary,
> null-related instructions in wasm now need an additional type argument
> to handle the correct null object.
>
> Bug: v8:7748
> Change-Id: I06da00fcd279cc5376e69ab7858e3782f5b5081e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4200639
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#85648}
Bug: v8:7748
Change-Id: Ie53febf49b946217e0057959c757d811a97ca1eb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4219105
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85649}
We introduce a wasm null object, separate from JS null. Its purpose is
to support trapping null accesses for wasm objects.
This will be achieved by allocating a large payload for it (larger than
any wasm struct) and memory-protecting it (see linked CL). The two null
objects get mapped to each other at the wasm-JS boundary.
Since externref objects live on the JS side of the boundary,
null-related instructions in wasm now need an additional type argument
to handle the correct null object.
Bug: v8:7748
Change-Id: I06da00fcd279cc5376e69ab7858e3782f5b5081e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4200639
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85648}
Known-pointer decompression used to be distinct from any-tagged-value
decompression, since the latter used to detect Smis and decompress them
with sign extension. However, we got rid of this distinction when we
introduced Smi-corrupting loads (allowing the top 32-bits of
uncompressed Smis to be undefined), which means that the TaggedPointer
and TaggedAny decompression is now identical.
We can remove a bunch of duplicate code by removing this distinction.
Change-Id: Id66671497d63ed885f9e537494c011317dfd4788
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4221398
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85647}
When folding constants in the MachineOperatorReducer, we should be
careful that arithmetic instructions producing int64 outputs aren't
replaced with booleans represented as int32.
Fixed: chromium:1407384
Change-Id: Ib536a53084b12bbb205308c642ee32c0f2e1e418
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4219023
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85646}
This flag, together with the DEFINE_EXPERIMENTAL_FEATURE macro, allows
declaring features as "experimental", implying that they are expected to
contain bugs and are not yet ready for fuzz testing for example.
Change-Id: I1288b6c2d28ef20d19d388bf56c57c44a25ba19b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4181025
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85645}
The "ProbeMemory" functions starts showing up on stack traces for random
illegal memory accesses hit by the arm64 simulator (see e.g.
https://crbug.com/1408957 or https://crbug.com/1409124).
Thus specify an explicit symbol name that will make it easier to see
that this is a v8-internal symbol related to the simulator.
R=mseaborn@chromium.org
Change-Id: If5753170cfee399aa59b11cfcd82314589990192
Cq-Include-Trybots: luci.v8.try:v8_mac_arm64_sim_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4200630
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mark Seaborn <mseaborn@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85641}
Loop peeling currently causes performance regressions in some cases.
To be able to gradually enable loop peeling in loops that would benefit
from it, as a first step loop peeling is enabled iff the loop contains
a PrepareStringForGetCodeUnit IR instruction.
Bug: v8:7748
Change-Id: I2c04101b9cd342e35a016e59da085cbb481bdbe1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4200642
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85640}
Some patterns that were valid with /u are invalid with /v.
This CL adds a UseCounter for such usages in /u to get an idea how often
they are used in the wild.
This is important information w.r.t the proposal to use /v instead of /u
for the pattern attribute (http://go/gh/whatwg/html/pull/7908).
Chromium CL: https://crrev.com/c/4221395
Bug: v8:11935
Change-Id: Idc023ceba9ce03eee578d6c387ce8a8f37db292f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4212393
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85639}
The {CallWasmFunctionForTesting} function currently receives arguments
as a pair of {int} and {Handle<Object>*}. Encapsulating this as a
{base::Vector} makes the relation more clear and improves readability at
call sites.
R=ahaas@chromium.org
Change-Id: I884f8d0dc1c33389b60cc53750f2e3bfcaf644a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4218353
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85638}
Change PushDeferredCode into MakeDeferredCode, and have it return a
Label*. This allows it to be passed in directly to functions expecting a
Label, e.g.
JumpToDeferredIf(cond, [](){...});
could be replaced by
JumpIf(cond, MakeDeferredCode([](){...}));
and we don't need to add "ToDeferred" overloads for the other Jump
helpers (JumpIfSmi etc.).
Bug: v8:7700
Change-Id: I716468030601964fba828666fde6aa4f2ed29c3a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4218392
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85637}
We see crashes on arm64 on Windows. Disable the use of preserve_most
there, until we figure out (and fix) the root cause.
R=mlippautz@chromium.org
Bug: chromium:1409934
Change-Id: Ic913039d36d158fb5ad368915d95c250d8724a07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4218354
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85634}
During deserialization all allocated objects are preinitialized with
Smi 0. During code cache deserialization GCs may happen. When
--code-stats is enabled as well, code stats are collected during GC.
In such situations crashes may happen because of fields in
BytecodeArray objects not being deserialized at the time of GC.
This CL introduces new raw_* getters for --code-stats which allows
accessing these fields while they still contain 0.
Bug: v8:13704
Change-Id: I767714ca1c936a031d71f3eb53d6401030ccce7e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4212406
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85632}
Instead use getsectiondata for both the 32 bit and 64 bit use case.
Bug: v8:13428
Change-Id: I1efeb3bb69862ad11008a6a4a3fb08581ab7cd2e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4218733
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85631}
The EffectControlLinearizer should use accurate representations
for the values it creates.
Fixed: chromium:1412099
Change-Id: I9b6d3d1aeb11e5a4863d82fd2e1bc5b7ce777742
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4218734
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85630}
The assumption is that {PopToRegister} most often finds a register stack
slot (this is backed by data). Hence put all spilling-related code
behind no-inline and preserve_most functions.
Also, annotate some methods that are supposed to be inlined with
V8_INLINE. This is not needed (they were already inlined before), but
this documents the intend better.
This saves some binary size and seems to also slightly improve
performance.
R=ahaas@chromium.org
Bug: v8:13565, v8:13673
Change-Id: Ib4b8bd361ee19c29221263f6383034933fe7dff5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4212407
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85629}
This patch doubles the performance of iterating over a stringview_wtf16.
It does this by:
- changing string.as_wtf16 to flatten any Cons strings; in TF this
is represented by a new operator
- introducing a Turbofan operator PrepareStringForGetCodeunit that
inspects the given string's internal representation and retrieves
the pointer to the actual characters
- adapting the code emitted for `get_codeunit` to consume the output
of this operator
- improving WasmLoadElimination to deduplicate both new operators for
peeled loops, so that as much work as possible only needs to be done
once.
This patch was authored about half-and-half by manoskouk@chromium.org
and jkummerow@chromium.org.
Bug: v8:12868
Change-Id: If9cf4c3ffeb5e1ca08b864cbc0bf868656ca2dec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4198142
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85628}
We sometimes get non-reproducible exception mismatches in the fuzzers.
This might come from OOM exceptions.
This CL makes us print some information about them, so we learn more
from the occasional fuzzer reports. In a follow-up we can then handle
OOM exceptions better, if that turns out to cause this.
R=ahaas@chromium.org
Bug: chromium:1412084
Change-Id: Ic0bf3880fe733320c2532c0f69d8f88fe9c9ff5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4217417
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85624}
The function relied on passed pointers always being compressed, which
is no longer the case with subtle::UncompressedMember<>.
Bug: chromium:1412021, chromium:1412221
Change-Id: I531e41d24fcab34e527db99f8047123f254e8a74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4217411
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85623}
- Mac Arm64 doesn't like cross-compiling to 32bit platforms
- Build the language server and torque files for the host platform
(x64, arm64) by default
No-Try: true
Change-Id: I4df68d416c58f58335fecc52b802c4bfe4ce2f24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4218352
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85621}
We have a shared large object space now. This CL supports
externalization of strings in shared LO space.
Bug: v8:12957
Change-Id: Ic540aed4d3e99248ef27bdccb525a0bc8ff7b28b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4217416
Auto-Submit: Patrick Thier <pthier@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85620}
The contract of passing in a Code object for builtins and
InstructionStream objects for everything else was confusing. In this
CL we change it to:
void VisitRunningCode(FullObjectSlot code_slot,
FullObjectSlot istream_or_smi_zero_slot)
where we *always* pass in both parts of the composite
{Code,InstructionStream} object. The istream_or_smi_zero_slot must
equal raw_instruction_stream() of the given code_slot. We pass in
both, because it is convenient at the single call site in frames.cc.
Drive-by: extract deopt literal iteration to a Code method.
Bug: v8:13654
Change-Id: I09d658fbd8d26bf483e1c778e566a53e1817f80f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4212399
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85619}
This accounts for a big difference between the total length of the
atomic pause (v8:gc:cycle:main_thread:full:atomic) and the sum of
the four phases, when GC stats are enabled.
Change-Id: I5d5abd1e6a8d28ae45a04739d2ca937ef54148af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4217418
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85618}
"InitMerge" did compute the state at the merge point, and a following
"MergeStackWith" or "MergeFullStackWith" would then generate the code to
merge the current state into the computed state.
As every "InitMerge" is followed by an actual merge, we can combine the
two and save one iteration over the two states.
The only change in generated code is that we initialize the merge state
after a one-armed if from the if-state instead of the else-state. This
could potentially make the if-branch slightly cheaper and the
else-branch slightly slower, but will not negatively impact overall code
size.
This CL should save roughly 2% of Liftoff compilation time.
R=dlehmann@chromium.org
Bug: v8:13565, v8:13673
Change-Id: Id323a15e7fd765727f46830509fbaf7f5498c229
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4203380
Reviewed-by: Daniel Lehmann <dlehmann@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85616}
No concurrent allocation lock should be needed when allocating in new space.
Bug: v8:12612
Change-Id: I5242817b49564e0b786c16cee017762631de6bc6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4215296
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85615}
This is a reland of commit 77d08fcde5
Original change's description:
> [static-roots] Use static map range checks instead of instance types
>
> Some instance types, or type ranges, corresponds to a range of pointers
> in the static read only roots table. Instead of loading the instance
> type of a map it can therefore be beneficial to compare the map itself
> against this range.
>
> This CL adds:
>
> * Add infrastructure to compute and output a mapping of
> `(instance_type_first, instance_type_last) ->
> (map_ptr_first, map_ptr_last)` for interesting ranges.
> * Extend InstanceTypeChecker to use these ranges.
>
> For single instance types that map onto a range of maps it is not
> obvious which check is faster. Checking the map range saves a load,
> whereas checking the instance type saves an additional jump.
>
> Bug: v8:13466
> Change-Id: I670fc10fad9920645c0ce0d976ae7e7a13a86e60
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4188379
> Reviewed-by: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Olivier Flückiger <olivf@chromium.org>
> Auto-Submit: Olivier Flückiger <olivf@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#85599}
Bug: v8:13466
Change-Id: I0317a7b88e391e0a7502cc056a2fe691d294fba1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4217131
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Olivier Flückiger <olivf@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85614}
The move constructor left the "other" (source) vector in an
unpredictable state, depending on the size: For "big" small-vectors
(using dynamically allocated storage) we would reset it to an empty
vector. "Small" small-vectors on the other hand were not reset.
Fix this to make it possible to reuse a SmallVector after moving its
content to another SmallVector. This also flushes out a bug more easily,
see https://crrev.com/c/4215292.
R=dlehmann@chromium.org
CC=thibaudm@chromium.org
Change-Id: Ia188c3639e9104dfbeb589bfc49e3228f4cbeda7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4215297
Reviewed-by: Daniel Lehmann <dlehmann@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85612}
CacheState::Steal didn't actually call the move assignment operator,
even though it should (and unlike what the comment says in its body).
The reason is the incompatible const-qualifier, such that the move
assignment operater wasn't selected during overload resolution.
Due to C++'s operator overloading, the compiler silently used the copy
assignment operator instead. That works, but is naturally slower.
This actually gave `Steal` the exact same behavior as `Split` until now,
which masked yet another bug, where we called `Steal` but should have
called `Split`.
This CL fixes both issues.
Bug: v8:13673
Change-Id: I940eb0fed383d78244f497bc6f7b67730038de42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4215292
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Daniel Lehmann <dlehmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85611}
There is no real difference between MacroAssembler and TurboAssembler
anymore. Initially the idea was to differentiate thread-safe
operations, but it got out of hand. With LocalHeaps we could ensure
differently by passing a local_isolate.
In this CL:
TurboAssemblerBase was renamed to MacroAssemblerBase
The file containing it also renamed from turbo-assembler to macro-assembler-base.
TurboAssembler and MacroAssembler were merged into MacroAssembler
in each of the architectures.
turbo-assembler-unittests-arch were included in
macro-assembler-unittests-arch
tasm renamed to masm
Bug: v8:13707
Change-Id: I716bbfc51b33ac890c72e8541e01af0af41b6770
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4212396
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85610}
