Allow Wasm to generate calls directly to Fast API C functions.
This massively reduces the overhead of these calls (~300%).
Currently options parameter is not supported.
This is a reland of
https://chromium-review.googlesource.com/c/v8/v8/+/3364356
with a fix to a data race.
Bug: chromium:1052746
Change-Id: I8c1c255419496d03a94ec2b443329842469586d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3398394
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#78714}
This reverts commit bd72152e7d.
Reason for revert: TSAN reports a data race, please see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/18124/overview
Original change's description:
> [fastcall] Add Wasm entry for Fast API calls
>
> Allow Wasm to generate calls directly to Fast API C functions.
> This massively reduces the overhead of these calls (~300%).
> Currently options parameter is not supported.
>
> This is a rebase of the work originally done by devsnek in:
> https://chromium-review.googlesource.com/c/v8/v8/+/2718666.
>
> Bug: chromium:1052746
> Change-Id: I1bb1de68b440044cc8a4e528adf9d8e0e6692a07
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364356
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#78664}
Bug: chromium:1052746
Change-Id: I957708cf1cff6ee8f90678ee48428f5c12f75a53
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3398121
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Owners-Override: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#78665}
Allow Wasm to generate calls directly to Fast API C functions.
This massively reduces the overhead of these calls (~300%).
Currently options parameter is not supported.
This is a rebase of the work originally done by devsnek in:
https://chromium-review.googlesource.com/c/v8/v8/+/2718666.
Bug: chromium:1052746
Change-Id: I1bb1de68b440044cc8a4e528adf9d8e0e6692a07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364356
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#78664}
Now that concurrent inlining is shipping on stable, remove support
--no-concurrent-inlining.
Note that it's still possible to run Turbofan exclusively on the
main thread by passing --no-concurrent-recompilation.
Bug: v8:7790, v8:12142, chromium:1240585
Change-Id: I1943bbbcad7dea7e3a3c337c239f14f7d96c23cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3308798
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78644}
Private method loads are compiled to a named load of a private brand,
which always loads a BlockContext. This BlockContext holds the private
methods common to all instances of a class. TurboFan currently considers
JSLoadNamed to be of Type::NonInternal(). Private methods break this
assumption, since BlockContext is of Type::OtherInternal().
This CL changes the typing of JSLoadNamed of private brands to be
Type::OtherInternal().
Bug: v8:12500
Change-Id: I91f39747bf9422bd419d299f44152f567d8be8db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3351167
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78431}
This is a reland of 863bc2b88a
Diff to original:
- Don't eliminate GC observable stores that were temporarily
unobservable during traversal.
- Skip the previously added test for single-generation
- Add new test
Original change's description:
> [turbofan] Improve StoreStoreElimination
>
> Previously, StoreStoreElimination handled allocations as
> "can observe anything". This is pretty conservative and prohibits
> elimination of repeated double stores to the same field.
> With this CL allocations are changed to "observes initializing or
> transitioning stores".
> This way it is guaranteed that initializing stores to a freshly created
> object or stores that are part of a map transition are not eliminated
> before allocations (that can trigger GC), but allows elimination of
> non-initializing, non-transitioning, unobservable stores in the
> presence of allocations.
>
> Bug: v8:12200
> Change-Id: Ie1419696b9c8cb7c39aecf38d9f08102177b2c0f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295449
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78230}
Bug: v8:12200, chromium:1276923, v8:12477
Change-Id: Ied45ee28ac12b370f7b232d2d338f93e10fea6b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320460
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78349}
This reverts commit 863bc2b88a.
Reason for revert: https://crbug.com/1276923
Original change's description:
> [turbofan] Improve StoreStoreElimination
>
> Previously, StoreStoreElimination handled allocations as
> "can observe anything". This is pretty conservative and prohibits
> elimination of repeated double stores to the same field.
> With this CL allocations are changed to "observes initializing or
> transitioning stores".
> This way it is guaranteed that initializing stores to a freshly created
> object or stores that are part of a map transition are not eliminated
> before allocations (that can trigger GC), but allows elimination of
> non-initializing, non-transitioning, unobservable stores in the
> presence of allocations.
>
> Bug: v8:12200
> Change-Id: Ie1419696b9c8cb7c39aecf38d9f08102177b2c0f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295449
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78230}
Bug: chromium:1276923
Change-Id: I43dc3572ce1ef1fda42b7551ce8210d9f03e36ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318666
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78277}
This CL adds the following specific cases, to make sure they are
correctly handled by the slow path:
- the backing store of a TypedArray gets detached after optimisation
- passing null instead of a TA doesn't lead to a deopt
Bug: v8:11739, chromium:1052746
Change-Id: I7dfd3da9f535831901998ca6fad854af6e93e9f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320425
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78274}
Previously, StoreStoreElimination handled allocations as
"can observe anything". This is pretty conservative and prohibits
elimination of repeated double stores to the same field.
With this CL allocations are changed to "observes initializing or
transitioning stores".
This way it is guaranteed that initializing stores to a freshly created
object or stores that are part of a map transition are not eliminated
before allocations (that can trigger GC), but allows elimination of
non-initializing, non-transitioning, unobservable stores in the
presence of allocations.
Bug: v8:12200
Change-Id: Ie1419696b9c8cb7c39aecf38d9f08102177b2c0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295449
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78230}
In stress runs a GC may kick in before assertOptimized() is called
on the optimized function, causing it to deoptimize and the test
would fail even if the function is optimized as expected.
Adding --no-stress-flush-code --no-flush-bytecode fixes the timing
issue.
Bug: v8:12332
Change-Id: If43c2a06e84c0e3b5e21f7bde160340a0fc742f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3237326
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#77645}
This is a reland of 45227ffdb4
Differences:
- Handle one more flags conflict in variants.py.
- Disallow %VerifyType without --concurrent-recompilation.
Original change's description:
> [turbofan] extend type asserts to cover all JS types
>
> Extend type assertions to all types covering JavaScript values.
> This is achieved by allocating type representations on the heap using
> newly defined HeapObject subclasses. To allocate these in the compiler,
> we disable concurrent compilation for the --assert-types flag for now.
>
> Fix two type errors that came up with the existing tests:
> 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
> OtherObject.
> 2. OperationTyper::NumberToString(Type) can type the result as the
> HeapConstant Factory::zero_string(). However, NumberToString does
> not always produce this string. To avoid regressions, the CL keeps
> the HeapConstant type and changes the runtime and builtin code to
> always produce the canonical "0" string.
>
> A few tests were failing because they check for truncations to work
> and prevent deoptimization. However, AssertType nodes destroy all
> truncations (which is by design), so these tests are incompatible
> and now disabled for the assert_types variant.
>
> Drive-by fix: a few minor Torque issues that came up.
>
> Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77565}
Change-Id: I5b3c6745c6ad349ff8c2b199d9afdf0a9b5a7392
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247035
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77596}
This reverts commit 45227ffdb4.
Reason for revert: Breaks on gc_stress mode, see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/35988/overview
Original change's description:
> [turbofan] extend type asserts to cover all JS types
>
> Extend type assertions to all types covering JavaScript values.
> This is achieved by allocating type representations on the heap using
> newly defined HeapObject subclasses. To allocate these in the compiler,
> we disable concurrent compilation for the --assert-types flag for now.
>
> Fix two type errors that came up with the existing tests:
> 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
> OtherObject.
> 2. OperationTyper::NumberToString(Type) can type the result as the
> HeapConstant Factory::zero_string(). However, NumberToString does
> not always produce this string. To avoid regressions, the CL keeps
> the HeapConstant type and changes the runtime and builtin code to
> always produce the canonical "0" string.
>
> A few tests were failing because they check for truncations to work
> and prevent deoptimization. However, AssertType nodes destroy all
> truncations (which is by design), so these tests are incompatible
> and now disabled for the assert_types variant.
>
> Drive-by fix: a few minor Torque issues that came up.
>
> Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77565}
Change-Id: Ia779a11fc811846194c7a8d1e40b372b265e7ea4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247034
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Owners-Override: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#77566}
Extend type assertions to all types covering JavaScript values.
This is achieved by allocating type representations on the heap using
newly defined HeapObject subclasses. To allocate these in the compiler,
we disable concurrent compilation for the --assert-types flag for now.
Fix two type errors that came up with the existing tests:
1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of
OtherObject.
2. OperationTyper::NumberToString(Type) can type the result as the
HeapConstant Factory::zero_string(). However, NumberToString does
not always produce this string. To avoid regressions, the CL keeps
the HeapConstant type and changes the runtime and builtin code to
always produce the canonical "0" string.
A few tests were failing because they check for truncations to work
and prevent deoptimization. However, AssertType nodes destroy all
truncations (which is by design), so these tests are incompatible
and now disabled for the assert_types variant.
Drive-by fix: a few minor Torque issues that came up.
Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77565}
This CL fixes an issue in EffectControlLinearizer, where the primitive
type of the argument of a fast C call was used to compute its
MachineType even when the argument was actually a TypedArray, which
should always be treated as a Tagged type. This resulted in Float32/64
typed arrays being passed in FP registers, leading to a crash in the
register allocator.
Drive-by fix: Fixed output from --trace-turbo-alloc so that all of its
sub-parts are printed with PrintF, avoiding interleaved log lines.
Bug: chromium:1260954
Change-Id: I249c8629daae3af437fb52f53f45211f3a214222
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3231341
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77521}
To get more details about the failure when it flakes.
Bug: v8:12332
Change-Id: I1bf5188efe13a75e34dd9832e6275fd985ee8dbd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3233974
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77498}
--no-stress-flush-bytecode doesn't exist and should be
--no-stress-flush-code. Not supressing it means a tester could pass
--stress-flush-code and --no-flush-bytecode, which are contradictory and
will assert.
Bug: v8:12331
Cq-Include-Trybots: luci.v8.try:v8_numfuzz_dbg_ng,v8_numfuzz_ng
Change-Id: I6490271bcb11f5ea925eb8b65fbe0455c2dafeaf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3233952
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77483}
This CL adds support for BigInt.asIntN, the necessary operations and
extensions of the compiler's type system to allow lowering of BigInts
to word64 representations that are interpreted as signed 64 bit BigInts.
Bug: v8:9407
Change-Id: Id4f1f45437c1caf94e01c7b4e063c2ae2386c88a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3198070
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77458}
Introduces several new runtime mechanics for defining private fields,
including:
- Bytecode StaKeyedPropertyAsDefine
- Builtins StoreOwnIC{Trampoline|Baseline|_NoFeedback}
- Builtins KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic}
- TurboFan IR opcode JSDefineProperty
These new operations can reduce a runtime call per class field into a
more traditional Store equivalent. In the microbenchmarks, this
results in a substantial win over the status quo (~8x benchmark score
for single fields with the changes, ~20x with multiple fields).
The TurboFan JSDefineProperty op is lowered in
JSNativeContextSpecialization, however this required some hacks.
Because private fields are defined as DONT_ENUM when added to the
object, we can't find a suitable transition using the typical data
property (NONE) flags. I've added a mechanism to specify the required
PropertyAttributes for the transition we want to look up.
Details:
New bytecodes:
- StaKeyedPropertyAsDefine, which is essentially StaKeyedProperty
but with a different IC builtin (KeyedDefineOwnIC). This is a
bytecode rather than a flag for the existing StaKeyedProperty in
order to avoid impacting typical keyed stores in any way due to
additional branching and testing.
New builtins:
- StoreOwnIC{TTrampoline|Baseline|_NoFeedback} is now used for
StaNamedOwnProperty. Unlike the regular StoreIC, this variant will
no longer look up the property name in the prototype.
In adddition, this CL changes an assumption that
StoreNamedOwnProperty can't result in a map transition, as we
can't rely on the property already being present in the Map due
to an object literal boilerplate.
In the context of class features, this replaces the runtime
function %CreateDataProperty().
- KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic} is used by the
new StaKeyedPropertyAsDefine bytecode. This is similar to an
ordinary KeyedStoreIC, but will not check the prototype for
setters, and for private fields, will take the slow path if the
field already exists.
In the context of class features, this replaces the runtime
function %AddPrivateField().
TurboFan IR:
- JSDefineProperty is introduced to represent a situation where we
need to use "Define" semantics, in particular, it codifies that we
do not consult the prototype chain, and the semantics relating to
private fields are implied as well.
R=leszeks@chromium.org, syg@chromium.org, rmcilroy@chromium.org
Bug: v8:9888
Change-Id: Idcc947585c0e612f9e8533aa4e2e0f8f0df8875d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2795831
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#77377}
This is a reland of 5dde281c87,
after also fixing the ic-migrated-... test, in which an object died
too early.
Original change's description:
> [compiler] Fix a few test flakes and reenable the tests
>
> Bug: v8:12173
> Change-Id: I2983be9133f8ff4d1740e8eba05a3c29d603dfc3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3168270
> Auto-Submit: Georg Neis <neis@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76939}
Bug: v8:12173
Change-Id: If385e5c826b8470ef67f12705c5171f330f6cd57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3171353
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76946}
... by adding atomic (relaxed) accessor's for a map's
constructor_or_backpointer field, and using them in the two functions.
Bug: chromium:1250216, v8:7790
Change-Id: I3416799cca73792ff5f8963685274ad9afdc6229
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162129
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76876}
This CL introduces a d8-only flag --expose-fast-api which enables the
test FastCAPI object if the --turbo-fast-api-calls flag is enabled. It
also disables --stress-snapshot, which is incompatible with fast calls.
Bug: v8:12137
Change-Id: I01e8321726b78be660fd6554225999bfc94006c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3117485
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76505}
The fast_call_count getter in d8 was not properly initialised as
throwing when called as a constructor. As a result, it was possible
to pass a new object as its `this` and then attempt to "unwrap" it,
resulting in reading OOB in the new object. This CL also strenghtens
slow_call_count and reset_counts and adds a regression test.
Bug: chromium:1241464
Change-Id: I9b6e9a4e38a974dc111a53b911c73514c30de9df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3110369
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76426}
Don't create DataField and FastDataConstant access infos with a kNone
field representation. Instead return Invalid.
Bug: chromium:1239601
Change-Id: I4df7aa298974f9dcd650ead50aaa349c84feb487
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097463
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76343}
The validation was too strong in the case where the incrementation
produces type None.
Bug: chromium:1236716
Change-Id: I948b370594fa7dad1ba6e5b951f473855bf1346b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097865
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76338}
- Remove flag --block-concurrent-recompilation and its implementation,
including %UnblockConcurrentCompilation.
- Rewrite tests that used it in terms of the primitives introduced in
my previous CL:
https://chromium-review.googlesource.com/c/v8/v8/+/3071400/
- Remove "sync"/"no sync" arguments from %GetOptimizationStatus,
assertOptimized, etc. These are now always "no sync": they don't
do any magic.
- Remove "if %IsConcurrentRecompilationSupported then quit" from some
tests in favor of --concurrent-recompilation in their Flags line.
Bug: v8:12041, v8:7790
Change-Id: I966aae4fec85e6f9e7aeed2ba2c12e9198a3991f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3077149
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76298}
This CL adds back the 8-byte element types and extends the fast API
by hiding the unaligned memory reads performed for them.
Bug: chromium:1052746
Change-Id: Ide49ce6bd2c77b9d2d544ca2df47b5f95c93eaa9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056988
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76207}
Some tests want to invalidate part of the VM state after an optimization
has consumed the old state but before the code is installed.
The existing mechanism for this is --block-concurrent-recompilation
and %UnblockConcurrentRecompilation(). The former suspends optimization
right after PrepareJob, before the background ExecuteJob phase. The
intrinsic can then be used to unblock it again.
This was good enough so far because the main "consume" work used to
happen on the main thread. With concurrent inlining this is no longer
true and we need something else.
This CL introduces three intrinsics:
%DisableOptimizationFinalization turns off automatic finalization of
background optimizations.
%FinalizeOptimization() can then be called at an appropriate time to
manually finalize (and thus install) the code and reenable automatic
finalization.
In case one wants to perform some action on the main thread after the
concurrent optimization has finished but before it is finalized, one can
do so with the help of %WaitForBackgroundOptimization() (see tests).
In a followup CL I'm removing the old mechanism since it now seems
redundant.
Bug: v8:12041, v8:7790
Change-Id: Ib7195789105922eb7e4bff86dc5bc11e96a4f97b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071400
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76190}
Add support to flush only baseline code. FLAG_flush_baseline_code
controls if baseline code is flushed or not and FLAG_flush_bytecode
controls if bytecode is flushed or not. With this CL it is possible
to control if we want to flush only bytecode / only baseline code / both.
This also lets us have different heuristics for bytecode and baseline
code flushing.
Bug: v8:11947
Change-Id: Ibdfb9d8be7e7d54196db7890541fa0b5d84f037e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060481
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76075}
Based on a CL by mvstanton@.
Bug: v8:7790,v8:12030,v8:12031,v8:12041
Change-Id: I58b75bd96c724a99133bec7d3bd6cf4e0c9be6d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059683
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76055}
stress_flush_bytecode controls stress flushing of both bytecode and
baseline code. So rename the flag to better reflect its functionality
Bug: v8:11947
Change-Id: Ie6c124a476c3a7c6eabd1d75de030ee15fe78e32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3062567
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76043}
Change-Id: I0ba9c4bf13ff13e69d960fba44f93124be5a31a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3063499
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76029}
Rename CopyAndConvertArrayToCppBuffer as
TryCopyAndConvertArrayToCppBuffer and implement type specialization for
int32_t and double in order to speed up V8 bindings with sequences.
This API is used by Blink code, for example see
https://chromium-review.googlesource.com/c/chromium/src/+/3027405.
Bug: v8:11739
Change-Id: I026a7f5e7833fb1afcc2ea9c296b66c7f733cbb1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3036407
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76016}
In inlined-call-polymorphic we need value numbering phase to
deduce that TurbofanStaticAssert is always true. Turboprop doesn't
enable this phase. So use %OptimizeFunctionTopTier so this function
always tiers up to TurboFan.
Bug: v8:12013
Change-Id: I803bddaca8cb0ba0ad56cbd9874d90b118698e3f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3053579
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75913}
Enabling --turbo-optimize-apply breaks tests because we are
passing the wrong receiver;
in JSCallReducer::ReduceCallOrConstructWithArrayLikeOrSpread
we create a Call node with the wrong ConvertReceiverMode, we
pass kNullOrUndefined while it should be kAny. This may break
calls to API or in general calls to functions that use the
receiver.
Bug: chromium:1231108, v8:9974
Change-Id: Ib35a1bf8746ad254b6d63274f3ae11b12aa83de8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3043690
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75886}
This is a reland of 84d5b027a7
It removes support for 8-byte types which were causing
unaligned reads.
Original change's description:
> [fastcall] Implement support for TypedArray arguments
>
> This CL adds TypedArrays as supported arguments for fast API calls.
> It implements "exact type" matching, i.e. if Float32Array is expected
> and e.g. Int32Array is passed instead, the generated code bails to the
> slow callback.
>
> Bug: chromium:1052746, chromium:1018624
> Change-Id: I01d4e681d2b367cbb57b06effcb591c090a23295
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999094
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75756}
Bug: chromium:1052746, chromium:1018624
Change-Id: I872716d95bde8c340cf04990a3e4ae8ec8cd74a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035090
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75877}
And use it to remove the set of TurboProp test skips.
BUG=v8:9684,v8:12013
Change-Id: I878e2b9c595449c954735290959d3b38eead5a5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3043963
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75865}
This CL fixes a previous change in String.prototype.startsWith which
didn't throw an exception (in the optimized version) when `undefined`
was passed as a receiver and the search string was the empty string.
Bug: chromium:1230260
Change-Id: I835bd409b09b78bf7235c77596f62b588c95611d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040841
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75818}
This CL fixes the behaviour of String.prototype.startsWith when
undefined is passed as the search term. It also implements a small
shorthand when the search term is empty (according to the spec).
Bug: v8:11977
Change-Id: Iec2aa5f4301fcf444f20d5c1a80d3f634624d6f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035089
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75763}
