This reverts commit da7322c05f.
Reason for revert: Breaking the pointer compression bots, e.g.:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20pointer%20compression/3047
Original change's description:
> [csa] verify skipped write-barriers in MemoryOptimizer
>
> With very few exceptions, this verifies all skipped write-barriers in
> CSA and Torque, showing that the MemoryOptimizer together with some
> type information on the stored value are enough to avoid unsafe skipped
> write-barriers.
>
> Changes to CSA:
> SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
> MemoryOptimizer by default.
> Type information about the stored values (TNode<Smi>) is exploited to
> safely skip write barriers for stored Smi values.
> In some cases, the code is re-structured to make it easier to consume
> for the MemoryOptimizer (manual branch and load elimination).
>
> Changes to the MemoryOptimizer:
> Improve the MemoryOptimizer to remove write barriers:
> - When the store happens to a CSA-generated InnerAllocate, by ignoring
> Bitcasts and additions.
> - When the stored value is the HeapConstant of an immortal immovable root.
> - When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
> - Fast C-calls are treated as non-allocating.
> - Runtime calls can be white-listed as non-allocating.
>
> Remaining missing cases:
> - C++-style iterator loops with inner pointers.
> - Inner allocates that are reloaded from a field where they were just stored
> (for example an elements backing store). Load elimination would fix that.
> - Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
> We could handle that in Torque.
> - Double-aligned allocations, which are not lowered in the MemoryOptimizer
> but in CSA.
>
> Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
> can be handled by overload resolution (in Torque and C++).
>
> R=jarin@chromium.org
> TBR=mvstanton@chromium.org
>
> Change-Id: I0af9b710673f350e0fe81c2e59f37da93c024b7c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571414
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61016}
TBR=mvstanton@chromium.org,jarin@chromium.org,tebbi@chromium.org
Change-Id: I36877cd6d08761726ef8dce8a3e3f2ce3eebe6cf
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585732
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61038}
With very few exceptions, this verifies all skipped write-barriers in
CSA and Torque, showing that the MemoryOptimizer together with some
type information on the stored value are enough to avoid unsafe skipped
write-barriers.
Changes to CSA:
SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
MemoryOptimizer by default.
Type information about the stored values (TNode<Smi>) is exploited to
safely skip write barriers for stored Smi values.
In some cases, the code is re-structured to make it easier to consume
for the MemoryOptimizer (manual branch and load elimination).
Changes to the MemoryOptimizer:
Improve the MemoryOptimizer to remove write barriers:
- When the store happens to a CSA-generated InnerAllocate, by ignoring
Bitcasts and additions.
- When the stored value is the HeapConstant of an immortal immovable root.
- When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
- Fast C-calls are treated as non-allocating.
- Runtime calls can be white-listed as non-allocating.
Remaining missing cases:
- C++-style iterator loops with inner pointers.
- Inner allocates that are reloaded from a field where they were just stored
(for example an elements backing store). Load elimination would fix that.
- Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
We could handle that in Torque.
- Double-aligned allocations, which are not lowered in the MemoryOptimizer
but in CSA.
Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
can be handled by overload resolution (in Torque and C++).
R=jarin@chromium.orgTBR=mvstanton@chromium.org
Change-Id: I0af9b710673f350e0fe81c2e59f37da93c024b7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571414
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61016}
Plus a script to compile/link/run them.
Change-Id: Iac8ffcda3a73902261c07a7b4e5d967a19414c75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564058
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60911}
Imported from https://github.com/WebAssembly/wasm-c-api/ and
updated to work inside V8.
Tests will be added in an upcoming CL.
This is experimental; it is not yet recommended to rely on it.
Change-Id: I05914f4b63298bf7c848c4d4c8811f0f6eb882e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1516478
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60910}
Change-Id: Ic31b33ef4c290aee31be2d66295978908f568775
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563410
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#60775}
This changes the syntax for constructing structs and classes to explicitly
mention the fieldnames, similar to JavaScript object literals.
The fields still have to be listed in the same order as in the struct/class
declaration.
As in Javascript, {foo: foo} can be abbreviated as {foo}.
Example:
macro NewJSArray(implicit context: Context)(
map: Map, elements: FixedArrayBase): JSArray {
return new JSArray{
map,
properties_or_hash: kEmptyFixedArray,
elements,
length: elements.length
};
}
Drive-by cleanup: Make struct and class constructors follow the same pattern
in the parser and the AST.
Bug: v8:9018 v8:7793
Change-Id: I22ff7f68270e4f406aa80731a709d41ea52f52bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1551999
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60622}
The bottlenecks to prevent storing signalling NaNs in backing stores
were not perfect. This change makes it harder by ensuring that all
the Torque-side "[]=" operator overloads for FixedDoubleArray stores
have signalling NaNs silenced.
Bug: chromium:944435
Change-Id: I295d9b34f4c896db30989bb9db1a2b452daa03ae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1538517
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60459}
With the recent changes to Array#sort, the main algorithm does not
need to bail out anymore. Only the initial copying into the workarray,
as well as the final copying back into the original backing store
might cause a switch from fast-path to the slow-path.
This CL changes the slow-path so sorting itself is not restarted and
the slow-path will continue copying where the fast-path left off.
R=jgruber@chromium.org
Bug: v8:7382
Change-Id: I4ab61daa62bb816f4f6e16e60bde1f948ad1e7db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1507717
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60151}
With the recent changes to Array#sort, some bailout labels and
accessor checks became superfluous. This CL removes them along
with some other minor cleanup work.
R=jgruber@chromium.org
Bug: v8:8834
Change-Id: I7429482ceaccbe743e2b8190d83bfa2c34875b11
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1507678
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60150}
These changes fix Python 3 compatibility errors in third-party libraries
I'm not sure if these problems can be fixed this way.
But! (1) In deps/inspector_protocol no file roll.py
it looks like the repository v8 it shouldn't be, either.
(2) I have not found a separate repository for binutils.
Bug: chromium:935197
Change-Id: Ied2bb83e0539aa392f8fc7c3aeef662612f37d06
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1484302
Reviewed-by: Sergiy Belozorov <sergiyb@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Sergiy Belozorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60085}
Constructors have been removed. Initialization syntax with {}
for structs and classes is now limited to the initialization
expressions for the fields, so "constructors" deviating from
that explicit and complete list of field initialization
values must be declared as separate macros.
Bug: v8:7793
Change-Id: Ibc26e685c0c8a182732df90b1631eae9371309cb
Reviewed-on: https://chromium-review.googlesource.com/c/1489080
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59917}
This CL changes Array#sort to work roughly like:
1) Call [[Get]] on the receiver in [0, length) and store to FA
2) Use the existing TimSort to sort that FA
3) Call [[Set]] on the receiver in [0, length) using the result
This has the advantage that we no longer need different fast-paths
for the sorting algorithm itself, only for step 1 and 3. This results
in a code size reduction of ~2650 bytes.
This CL does not include optimizations that elides step 1 or 3.
Change-Id: I7f2e35067a6ec356add8b0c50b160d76813c536d
Reviewed-on: https://chromium-review.googlesource.com/c/1458237
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59653}
In the process, cleanup the StoreFixedArray* operators
and change most FixedArray element accesses so that
they explicitly use the '.objects' and '.floats'
fields.
Bug: v8:7793
Change-Id: I3e45a9b7536ec76e1413b7e508d79a56b37604ff
Reviewed-on: https://chromium-review.googlesource.com/c/1460948
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59649}
... to ec358ccfd63a2a657c147329c7793d217e278a58.
This adds support for CBOR <-> Value.
v8 changes:
- Add StringUTF8Adapter (from Pavel's change)
- Add Binary::fromSpan (needed for the cbor->BinaryValue conversion).
Change-Id: I09746dc361df0b150b23697a20b287613558c003
Reviewed-on: https://chromium-review.googlesource.com/c/1470955
Commit-Queue: Pavel Feldman <pfeldman@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59583}
For macros expanding to function definitions, I removed the spurious ; after
macro invocations. For macros expandign to function declarations, I made the ;
required and consistently inserted it.
No behavior change.
Bug: chromium:926235
Change-Id: Ib8085d85d913d74307e3481f7fee4b7dc78c7549
Reviewed-on: https://chromium-review.googlesource.com/c/1467545
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59558}
This CL changes most Call* macros (and some others) in Array#sort to
pass the context and sortState implicitly. This improves
readability, especially for loads and stores.
R=jgruber@chromium.org, tebbi@chromium.org
Bug: v8:8567
Change-Id: I6528d080bb01ab676de3ba6a7bf8223b98b6db7f
Reviewed-on: https://chromium-review.googlesource.com/c/1450114
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59320}
This CL is mostly a mechanical change. Loading either the receiver,
the backing store or the temp array from the sort state is pushed down
into each respective Load/Store builtin. This eliminates the need
for reloading the elements pointer after each compare function call.
R=jgruber@chromium.org, tebbi@chromium.org
Bug: v8:8562
Change-Id: I453e98635f9d891da58cf7b2a86c5c58f4a4069c
Reviewed-on: https://chromium-review.googlesource.com/c/1449613
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59291}
This CL changes Array#sort to use the generic path for fast elements
kinds if --force-slow-path is present. Note that the IsFastJSArray macro
includes this check but not the Cast itself.
R=jgruber@chromium.org
Bug: v8:8215
Change-Id: I1135ab9db15effd86020f49f4ae23ba1e1da07f8
Reviewed-on: https://chromium-review.googlesource.com/c/1435940
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59097}
This was deleted source side in https://crrev.com/c/1308912 with
seemingly no ill effects.
Bug: chromium:718157
Change-Id: Ic2516b391b76a8fb72df97f6f090af3c24f35766
Reviewed-on: https://chromium-review.googlesource.com/c/1371035
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58141}
Moving Frame-inspection functionality to Torque is a prerequisite
for porting the CSA-based arguments code, which is a great candidate
to simplify/cleanup with Torque.
Change-Id: I1f4cb94cb357aae5864c2e84f3bf5a07549b27f8
Reviewed-on: https://chromium-review.googlesource.com/c/1357050
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58106}
Intrinsic changes:
- Rename %RawCast to %RawObjectCast and add error checking so that it
only applies to subtypes of Objects.
- Add %RawPointerCast, which is similar to %RawObjectCast but must be
used for all subtypes of RawPtr.
- Add %RawConstexprCast, which allows one constexpr to be be cast to
another at compile time. It translate to an appropriate static_cast
in the generated code
- Add %FromConstexpr, which handles most of the standard cases of
generating XXXConstant CSA nodes from constexpr constants. It uses
either SmiConstant, NumberConstant, StringConstant, IntPtrConstant
or Int32Constant, depending on the cast-to type generic <To> type.
- Add support for intrinsics that return constexpr results.
Cleanup:
- Turn FromConstexpr into a generic with two generic types, a <To> and
a <From> type. Most FromConstexpr can use the new %FromConstexpr
intrinsic rather than provide an explicit implementation.
Bug: v8:7793
Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464
Reviewed-on: https://chromium-review.googlesource.com/c/1357049
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58049}
The array length is modifiable by user code that is called as a
side-effect during the sorting algorithm. We thus cannot base any
guarantees on the current length, but must reference the initially-read
array length instead.
Note that even though the algorithm may read and write from beyond
the current array length value, this adheres to the spec, which only
requires accesses to be within the original array dimensions (i.e.: 0
<= i < original array length).
Bug: chromium:901633
Change-Id: Id765e80d4231ff6f2a73e040ec94c2b07f8c5b0f
Reviewed-on: https://chromium-review.googlesource.com/c/1317814
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57279}
This is a reland of c88994f84c
Turned out to not be the issue.
Original change's description:
> Fix Array.prototype.sort speed regression
>
> CanUseSameAccessor<ElementsAccessor: type> is array-sort.tq is super
> performance-critical. Reverting the type-safe cleanup made in this
> function while landing Array.prototype.slice.
>
> Bug=chromium:852764
>
> Change-Id: I1252d2ff8e431581f916794807e59abb39248abb
> Reviewed-on: https://chromium-review.googlesource.com/c/1317815
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Daniel Clifford <danno@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57248}
TBR=danno@chromium.org
Change-Id: I627a131a8525ae4e131c6467561cab9832f3792f
Reviewed-on: https://chromium-review.googlesource.com/c/1319581
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57270}
