This affects map, filter, every, some, indexOf and includes.
Tests for those cases and more are also added.
Bug: v8:8049
Change-Id: I196abd8e7e2419a2bb465f44caf4de52990ffced
Reviewed-on: https://chromium-review.googlesource.com/1172346
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Hai Dang <dhai@google.com>
Cr-Commit-Position: refs/heads/master@{#55103}
The DataView access methods can use the neutering protector to avoid
introducing an explicit check into the optimized code to see if the
backing store was neutered. Instead the optimized code has an implicit
dependency on the global neutering protector which gets invalidated
when the first array buffer is neutered (globally). We use the same
trick for typed arrays already.
Bug: chromium:225811
Change-Id: I9b3c95b3113b8fa00dcbba216ef29c84c0056951
Reviewed-on: https://chromium-review.googlesource.com/1172779
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55097}
This CL simplifies the implementation of inlined DataView
methods in TurboFan. It removes the explicit exception handling,
and just deopts and relies on the baseline code to handle
exceptions instead.
It also adapts the DataView test files in mjsunit/compiler/
accordingly.
Change-Id: I013c76970e1480df2b755d17d397bd0f9f26f0ec
Reviewed-on: https://chromium-review.googlesource.com/1148207
Commit-Queue: Théotime Grohens <theotime@google.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54648}
This is a reland of 9eca23e9ed
Adds a deopt continuation, which fixes JavaScript stack traces
to contain the number constructor after inlining.
Original change's description:
> [turbofan] Inline Number constructor in certain cases
>
> This CL adds inlining for the Number constructor if new.target is not
> present. The lowering is BigInt compatible, i.e. it converts BigInts to
> numbers.
>
> Bug: v8:7904
> Change-Id: If03b9f872d82e50b6ded7709069181c33dc44e82
> Reviewed-on: https://chromium-review.googlesource.com/1118557
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54454}
Bug: v8:7904
Change-Id: Ic416e5ba81fa3a0f59ae4afa80df83c46a759487
Reviewed-on: https://chromium-review.googlesource.com/1146581
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54609}
This CL completes the implementation of DataView prototype methods
in TurboFan, by implementing the Uint8, Int8, Uint16, Int16,
Uint32, Int32, Float32 and Float64 setters.
DataView performance is now ahead of the equivalent TypedArray wrapper,
and is now expected to at least match TypedArray performance in
the general case as well.
This CL also adds a test file in the compiler directory, to make
sure that the setters actually behave correctly.
Change-Id: I4ad4341c6b9b9d461348b62216f37a73abe321e8
Reviewed-on: https://chromium-review.googlesource.com/1128867
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Théotime Grohens <theotime@google.com>
Cr-Commit-Position: refs/heads/master@{#54331}
This CL implements Reduction and Lowering for the DataView Int32,
Uint32, Float32 and Float64 getters.
This makes DataView getters fully supported in TurboFan (except for
BigInts), and should bridge the performance gap with TypedArrays.
Change-Id: Ifa98df9cf13e44d6468ad9ec8a19c86b41c6d2b1
Reviewed-on: https://chromium-review.googlesource.com/1127360
Commit-Queue: Théotime Grohens <theotime@google.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54288}
This CL adds a Reduction for the DataViewGetInt16 and -Uint16 builtins,
and the corresponding handling in LoadDataViewElement node in the
effect control linearizer.
It also adds tests for the new getters.
Change-Id: I5101755e47657c25f10be1417f105e3ae72a3c39
Reviewed-on: https://chromium-review.googlesource.com/1126919
Commit-Queue: Théotime Grohens <theotime@google.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54271}
This CL adds code to inline the Int8 and Uint8 getters for DataView
objects in TurboFan in js-call-reducer.cc, as well as a new test file.
It already improves execution speed compared to the Torque baseline
implementation, and implements most of the architecture needed
for inlining the other DataView getters and setters as well.
Change-Id: I0e62b98fd6ec995f7db5ec42ea1eff1f03572f97
Reviewed-on: https://chromium-review.googlesource.com/1119909
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Théotime Grohens <theotime@google.com>
Cr-Commit-Position: refs/heads/master@{#54157}
Also add a DCHECK to a branch that can only be taken for the null
prototype.
R=sigurds@chromium.org
Change-Id: Ib94fe8f25ecfd1a4baa576915e6edfa60bcd771b
Reviewed-on: https://chromium-review.googlesource.com/1109961
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53939}
This is not web compatible, so let's delete the code.
Bug: v8:5536
Change-Id: I50506d37dcdff1f7f95577c47adcec653cc1f06e
Reviewed-on: https://chromium-review.googlesource.com/1064740
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53264}
... in order to be able to use it in other constants definitions in the header.
Bug: v8:7570
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Id5d6ae34ab401ecf063bf5897b87b6bb87c24960
Reviewed-on: https://chromium-review.googlesource.com/1032782
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53097}
This mjsunittest assumed specific internal types (i.e. Smi)
for certain fields; it generates some dozens of variants of
the test using new Function, but used the same property names
in all of them. This causes V8 to sometimes learn more general
types for fields (i.e. unboxed double), which the test did not
expect. This commit uses unique field names for each of the test
variants.
Change-Id: Ib1ecb3ae33a57c8a1293a29a2233dad4e16a39fb
Reviewed-on: https://chromium-review.googlesource.com/1004897
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52528}
This CL allows builtin continuations to handle pending exceptions.
This implements exception handling for the promise constructor in
case of deoptimization.
Bug: v8:7584
Change-Id: Ib5df5eb6606abb3f9690f294397981858dbdbf25
Reviewed-on: https://chromium-review.googlesource.com/983912
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52340}
This also introduces two new simplified operators,
NumberIsFinite and ObjectIsFiniteNumber; the latter
handles all values, and the former is a fast-path
of the fast-path that is inserted by typed optimization
if we know the input has Type::Number.
Bug: v8:7340, v8:7250
Change-Id: I1b4812c01bf470bbff40fb3da6e11da543a22cd2
Reviewed-on: https://chromium-review.googlesource.com/951244
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51980}
This introduces a new JSCreateTypedArray operator, backed by a dedicated
CreateTypedArray builtin, and adds support to lowering new TypedArray
calls to this operator. This way we avoid the overhead of going through
the generic construct stub machinery for hot code. This not only
recovers the performance regression on the typed array constructor
benchmarks, but even improves slightly beyond what we had in 6.6.
We might in the future try to fully inline the TypedArray constructor
into optimized code for certain cases.
Bug: chromium:820726, v8:7503, v8:7518
Change-Id: Ied465924d5695db576d533792f1db68456b9b5ea
Reviewed-on: https://chromium-review.googlesource.com/959010
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51973}
The analysis phase used to skip TypeGuard nodes, which are
normally re-introduced by the reduction phase. However, phi nodes
are created during the analysis phase already, and so it could happen
that a phi input skips a TypeGuard.
This CL solves the problem by not removing TypeGuard nodes in the first
place, but only forwarding the VirtualObject. This is analogous to how
we already treat FinishRegion nodes, which are similar in that they are
a renaming too.
Bug: chromium:741225
Change-Id: Icf8aa2d40a30d89788d875b37b9986111f9c966f
Reviewed-on: https://chromium-review.googlesource.com/958442
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51863}
Folding _ + NaN => NaN can widen type None to a constant type, which leads to floating DeadValue nodes. This CL fixes this by removing the optimization. Alternatively, we should consider removing all nodes of type None in simplified lowering.
Bug: chromium:817225
Change-Id: I2a126b360d70d3626f8a3c5e73ac72dc980ac8b3
Reviewed-on: https://chromium-review.googlesource.com/946129
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51699}
Turbofan can only handle 64K control inputs for merges. Such large
can only be created by functions with 64K jumps, so we limit the
bytecode size to the minimum size of bytecode arrays with 64K jumps.
Bug: chromium:815392, v8:7438
Change-Id: I674705e87e19ce451b40d5827c9fe3e6ec17293a
Reviewed-on: https://chromium-review.googlesource.com/938421
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51598}
This fixes issues where the stack track contained 'Promise' but
not 'new'.
Bug: v8:7253
Change-Id: I840fcc0a76e2376aab0b64d321f5cf8ccc672956
Reviewed-on: https://chromium-review.googlesource.com/928762
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51516}
This adds a frame state for the call to the executor in inlined promise
constructors. We provide a continuation function in case of deopts which
just returns the created promise. This is not totally correct yet: if
the executor function also throws, we need to catch it and call the
reject function instead.
We also still need to add a frame state for the isCallable check on the
executor, so that the stack is correct for the thrown TypeError.
Bug: v8:7253
Change-Id: I3ee042ec82f1a9a35d59e576f6c8efe9bc98698c
Reviewed-on: https://chromium-review.googlesource.com/926523
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51417}
Without processing the input, a phi node can be flagged as unused and
replaced with {Dead}, although it is used by a {DeadValue} node.
Bug: chromium:808472
Change-Id: I7446883535b34770e31e4e26e1c242eb05673a91
Reviewed-on: https://chromium-review.googlesource.com/919362
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51395}
This makes the inlining of the default resolve/reject closures generated
by the Promise constructor effective. To be really useful we still need
to have the Promise constructor inlined (work-in-progress) and eventually
track SharedFunctionInfo feedback in the CALL_IC.
Bug: v8:2206, v8:7253
Change-Id: I08fa8ca72754f459ae36027a55377ef57d411cdc
Reviewed-on: https://chromium-review.googlesource.com/926103
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51390}
Inline the promise constructor when we have one argument and target
matches new_target.
This is not complete, and is sitting behind an experimental flag for
now. We need to fix deoptimization by providing proper frame states.
Create a unittest class for JSCallReducer - just assert whether there
was a change or not, rather than specify the exact graph that should be
produced.
Bug: v8:7253
Change-Id: Ib6886a8feb2799f47cd647853cabcf12a189bc25
Reviewed-on: https://chromium-review.googlesource.com/919282
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51389}
This CL introduces new operators JSFulfillPromise and JSPromiseResolve,
corresponding to the specification operations with the same name, and
uses that to lower calls to Promise.resolve() builtin to JSPromiseResolve.
We also optimize JSPromiseResolve and JSResolvePromise further based on
information found about the value/resolution in the graph. This applies
to both Promise.resolve() builtin calls and implicit resolve operations
in async functions and async generators.
On a very simple microbenchmark like
console.time('resolve');
for (let i = 0; i < 1e8; ++i) Promise.resolve({i});
console.timeEnd('resolve');
this CL reduces the execution time from around 3049ms to around 947ms,
which is a pretty significant 3x improvement. On the wikipedia benchmark
we observe an improvement around 2% with this CL.
Bug: v8:7253
Change-Id: Ic69086cdc1b724f35dbe83305795539c562ab817
Reviewed-on: https://chromium-review.googlesource.com/913488
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51387}
This introduces dedicated builtins
- FulfillPromise,
- RejectPromise, and
- ResolvePromise,
which perform the corresponding operations from the language
specification, and removes the redundant entry points and the
excessive inlining of these operations into other builtins. We
also add the same logic on the C++ side, so that we don't need
to go into JavaScript land when resolving/rejecting from the
API.
The C++ side has a complete implementation, including full support
for the debugger and the current PromiseHook machinery. This is to
avoid constantly crossing the boundary for those cases, and to also
simplify the CSA side (and soon the TurboFan side), where we only
do the fast-path and bail out to the runtime for the general handling.
On top of this we introduce %_RejectPromise and %_ResolvePromise,
which are entry points used by the bytecode and parser desugarings
for async functions, and also used by the V8 Extras API. Thanks to
this we can uniformly optimize these in TurboFan, where we have
corresponding operators JSRejectPromise and JSResolvePromise, which
currently just call into the builtins, but middle-term can be further
optimized, i.e. to skip the "then" lookup for JSResolvePromise when
we know something about the resolution.
In TurboFan we can also already inline the default PromiseCapability
[[Reject]] and [[Resolve]] functions, although this is not as effective
as it can be right now, until we have inlining support for the Promise
constructor (being worked on by petermarshall@ right now) and/or SFI
based CALL_IC feedback.
Overall this change is meant as a refactoring without significant
performance impact anywhere; it seems to improve performance of
simple async functions a bit, but otherwise is neutral.
Bug: v8:7253
Change-Id: Id0b979f9b2843560e38cd8df4b02627dad4b6d8c
Reviewed-on: https://chromium-review.googlesource.com/911632
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51260}
This reverts commit 14108f4c2e.
Reason for revert: Not the culprit for Canary microtask crashes
Original change's description:
> [builtins] Mega-revert to address the Dev blocker in crbug.com/808911.
>
> - Revert "[builtins] Save one word in contexts for Promise.all."
> This reverts commit 7632da067b.
> - Revert "[builtins] Also use the Promise#then protector for Promise#finally()."
> This reverts commit d4f072ced3.
> - Revert "[builtins] Don't mess with entered context for MicrotaskCallbacks."
> This reverts commit 6703dacdd6.
> - Revert "[debugger] Properly deal with settled promises in catch prediction."
> This reverts commit 40dd065823.
> - Revert "[builtins] Widen the fast-path for Promise builtins."
> This reverts commit db0556b7e8.
> - Revert "[builtins] Unify PerformPromiseThen and optimize it with TurboFan."
> This reverts commit a582199c5e.
> - Revert "[builtins] Remove obsolete PromiseBuiltinsAssembler::AppendPromiseCallback."
> This reverts commit 6bf8885290.
> - Revert "[builtins] Turn NewPromiseCapability into a proper builtin."
> This reverts commit 313b490ddd.
> - Revert "[builtins] Inline InternalPromiseThen into it's only caller"
> This reverts commit f7bd6a2fd6.
> - Revert "[builtins] Implement Promise#catch by really calling into Promise#then."
> This reverts commit b23b098fa0.
> - Revert "[promise] Remove incorrect fast path"
> This reverts commit 0f6eafe855.
> - Revert "[builtins] Squeeze JSPromise::result and JSPromise::reactions into a single field."
> This reverts commit 8a677a2831.
> - Revert "[builtins] Refactor promises to reduce GC overhead."
> This reverts commit 8e7737cb58.
>
> Tbr: hpayer@chromium.org
> Bug: chromium:800651, chromium:808911, v8:5691, v8:7253
> Change-Id: I8c8ea5ed32ed62f6cd8b0d027a3707ddd891e5f1
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/906991
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Adam Klein <adamk@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51158}
Change-Id: I09d958cbebd635a325809072a290f2f53df8c5d4
Tbr: adamk@chromium.org,yangguo@chromium.org,bmeurer@chromium.org
Bug: chromium:800651, chromium:808911, v8:5691, v8:7253
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/908988
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51181}
- Revert "[builtins] Save one word in contexts for Promise.all."
This reverts commit 7632da067b.
- Revert "[builtins] Also use the Promise#then protector for Promise#finally()."
This reverts commit d4f072ced3.
- Revert "[builtins] Don't mess with entered context for MicrotaskCallbacks."
This reverts commit 6703dacdd6.
- Revert "[debugger] Properly deal with settled promises in catch prediction."
This reverts commit 40dd065823.
- Revert "[builtins] Widen the fast-path for Promise builtins."
This reverts commit db0556b7e8.
- Revert "[builtins] Unify PerformPromiseThen and optimize it with TurboFan."
This reverts commit a582199c5e.
- Revert "[builtins] Remove obsolete PromiseBuiltinsAssembler::AppendPromiseCallback."
This reverts commit 6bf8885290.
- Revert "[builtins] Turn NewPromiseCapability into a proper builtin."
This reverts commit 313b490ddd.
- Revert "[builtins] Inline InternalPromiseThen into it's only caller"
This reverts commit f7bd6a2fd6.
- Revert "[builtins] Implement Promise#catch by really calling into Promise#then."
This reverts commit b23b098fa0.
- Revert "[promise] Remove incorrect fast path"
This reverts commit 0f6eafe855.
- Revert "[builtins] Squeeze JSPromise::result and JSPromise::reactions into a single field."
This reverts commit 8a677a2831.
- Revert "[builtins] Refactor promises to reduce GC overhead."
This reverts commit 8e7737cb58.
Tbr: hpayer@chromium.org
Bug: chromium:800651, chromium:808911, v8:5691, v8:7253
Change-Id: I8c8ea5ed32ed62f6cd8b0d027a3707ddd891e5f1
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/906991
Commit-Queue: Yang Guo <yangguo@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51158}
Add a fast-path to Promise#finally, which skips the "then" lookup of the
Promise#then lookup chain is intact, similar to what we already do for
Promise#catch.
Drive-by-fix: Also use the @@species protector to speed up the lookup
of the SpeciesConstructor in Promise#finally.
Bug: v8:7253
Change-Id: If77e779a0188904effc4528beffc8f0bdd7c2efe
Reviewed-on: https://chromium-review.googlesource.com/902283
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51116}
This adds a new isolate wide Promise#then protector, which guards the
"then" lookup for all JSPromise instances whose [[Prototype]] is the
initial %PromisePrototype%. Thus arbitrary mutations to the
Promise.prototype (i.e. monkey-patching other methods or installing
new functions) no longer sent you down the slow-path. Use this protector
in Promise.prototype.catch and in Promise.resolve.
Drive-by-fix: Restructure the resolve logic a bit and avoid the
expensive and large SameValue check, which can be turned into a simple
reference equal, as the promise in there is known to be a JSPromise
anyways.
Bug: v8:7253
Change-Id: If68b12c6bc6ca9c4d10552ae84854ebc3b5774f9
Reviewed-on: https://chromium-review.googlesource.com/899302
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51085}
This creates a uniform PerformPromiseThen builtin, which performs the
operation with the same name from the spec, except that it expects the
handlers to be either undefined or callable already, since this is only
relevant for a single callsite (namely Promise.prototype.then).
Introduce a matching operator JSPerformPromiseThen into TurboFan, which
represents this operation and removes the additional checks in case of
Promise.prototype.then based on the information we can derived from the
receiver maps.
This yields a nice 20-25% improvement on Promise.prototype.then, as
illustrated by the following micro-benchmark
```js
const N = 1e7;
function inc(x) { return x + 1; }
function chain(promise) {
return promise.then(inc).then(value => {
if (value < N) chain(Promise.resolve(value));
});
}
console.time('total');
chain(Promise.resolve(0));
setTimeout(console.timeEnd.bind(console, 'total'));
```
which goes from around 1230ms to 930ms with this patch.
Bug: v8:7253
Change-Id: I5712a863acdbe7da3bb8e621887c7b952148c51a
Reviewed-on: https://chromium-review.googlesource.com/899064
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51071}
We still avoid the "then" lookup using the current fast-path
mega-guard in the baseline case, but in TurboFan we simply
constant-fold the "then" lookup in the JSCallReducer. So all
further optimizations on Promise#then in TurboFan will automatically
apply to Promise#catch as well.
Bug: v8:7253
Change-Id: Idf7252157375a0ae3a91c7a3b42c30c5f367c0a8
Reviewed-on: https://chromium-review.googlesource.com/895446
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51008}
This delays removing dead loop's loop exits after we iterate all uses of
the loop. That way, we avoid mutating the use collection while iterating
it.
Bug: chromium:803022
Change-Id: I17462dd82c3cb78f2f630e5db81d8ccdcc517d83
Reviewed-on: https://chromium-review.googlesource.com/878329
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50813}
This CL moves allocations in array-multiple-receiver-maps.js
to prevent gc fuzzing from cleaning out code objects, which
will mess with assertOptimized in the test.
Bug: v8:7338
Change-Id: I9ee88cf5518307ff12302df2fdaca5258c23b779
Reviewed-on: https://chromium-review.googlesource.com/880957
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50809}
DeadValue was a constant node of type None. This is unsound in the
presence of re-scheduling. This CL adds a value input to DeadValue,
which preserves the dependency on the original node of type None.
This reland addresses the bug that the EffectControlLinearizer could destroy dependencies of DeadValue by attaching DeadValue nodes to the effect chain in the EffectControlLinearizer.
Bug: chromium:796041 chromium:798938
Change-Id: If47b54a7986d257eb63b437f855769b503679ff5
Reviewed-on: https://chromium-review.googlesource.com/850392
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50360}
