- 18 Oct, 2017 1 commit
-
-
Mike Stanton authored
Support inlining of Array.prototype.filter in TurboFan. (relanding with fix for chromium:766635, visible in the diff between patchsets 2 and 3) Bug: v8:1956,chromium:766635 Change-Id: Ia50be6770602513e3d91d17e2b2ca9d3b0e8b42a Reviewed-on: https://chromium-review.googlesource.com/721119 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48697}
-
- 17 Oct, 2017 1 commit
-
-
Benedikt Meurer authored
So far the inlining of Function#bind into TurboFan optimized code was limited to cases where TurboFan could infer the constant JSFunction that was bound. However we can easily extend that to cover JSBoundFunction as well, and obviously also take the LOAD_IC feedback if we don't have a known JSFunction or JSBoundFunction. This adds a new operator JSCreateBoundFunction that contains the logic for the creation of the bound function object and the arguments. On the micro-benchmarks we go from functionBindParameter0: 1239 ms. functionBindConstant0: 478 ms. functionBindBoundConstant0: 1256 ms. functionBindParameter1: 1278 ms. functionBindConstant1: 475 ms. functionBindBoundConstant1: 1253 ms. functionBindParameter2: 1431 ms. functionBindConstant2: 616 ms. functionBindBoundConstant2: 1437 ms. to functionBindParameter0: 462 ms. functionBindConstant0: 485 ms. functionBindBoundConstant0: 474 ms. functionBindParameter1: 478 ms. functionBindConstant1: 474 ms. functionBindBoundConstant1: 474 ms. functionBindParameter2: 617 ms. functionBindConstant2: 614 ms. functionBindBoundConstant2: 616 ms. which is a ~2.5x improvement. On the jshint benchmark in the web-tooling-benchmark we observe a 2-3% improvement, which corresponds to the time we had seen it running in the generic version. Bug: v8:6936, v8:6946 Change-Id: I940d13220ff35ae602dbaa33349ba4bbe0c9a9d3 Reviewed-on: https://chromium-review.googlesource.com/723080Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48639}
-
- 16 Oct, 2017 1 commit
-
-
Benedikt Meurer authored
Port the baseline version of Reflect.has to the CodeStubAssembler and reuse the existing logic for HasProperty (i.e. the HasProperty builtin). Also inline the Reflect.has builtin into TurboFan, by adding a check on the target in front of a use of the JSHasProperty operator. Technically this additional check is not necessary, because the JSHasProperty operator already throws if the target is not a JSReceiver, but the exception message is confusing then. This improves the performance of the micro-benchmark from reflectHasPresent: 337 ms. reflectHasAbsent: 472 ms. to reflectHasPresent: 121 ms. reflectHasAbsent: 216 ms. which is a nice 2.8x improvement in the best case. It also improves the chai test on the web-tooling-benchmark by around 1-2%, which is roughly the expected win (since Reflect.has overall accounts for around 3-4%). Bug: v8:5996, v8:6936, v8:6937 Change-Id: I856183229677a71c19936f06f2a4fc7a794a9a4a Reviewed-on: https://chromium-review.googlesource.com/720959 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48608}
-
- 13 Oct, 2017 1 commit
-
-
Michael Starzinger authored
This adds and explicit check for the constructability of the new.target value in the lowering of {JSCall} nodes known to call Reflect.construct. The {JSConstruct} operator does not perform this check and relies on the implicit validity of new.target in all other use cases. R=jarin@chromium.org TEST=mjsunit/regress/regress-crbug-768080 BUG=chromium:768080 Change-Id: I7c1921e787bae64ba83de3eb08aa00fc5523e251 Reviewed-on: https://chromium-review.googlesource.com/718100Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48543}
-
- 12 Oct, 2017 1 commit
-
-
Leszek Swirski authored
CheckIf is lowered to DeoptimizeIfNot, but there is no deoptimization reason given in the deopt if that check fails (the reason is hardcoded to "no reason"). These deopts are annoying to track down. This patch makes CheckIf an operator with a DeoptimizeReason parameter, which is passed through to the DeoptimizeIfNot when lowered. A couple of checks are converted to give good deoptimize reasons (some new reasons are introduced), and the others are defaulted to kNoReason until someone else finds a use for them. Change-Id: I7e910cc9579ccf978dfe9d270ba7b98c8f6c2492 Reviewed-on: https://chromium-review.googlesource.com/716479Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#48506}
-
- 10 Oct, 2017 1 commit
-
-
Mike Stanton authored
Bug: v8:6896 Change-Id: I4c54cc114fd2304de121586f6bcbf19957ae55b8 Reviewed-on: https://chromium-review.googlesource.com/708262 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48431}
-
- 09 Oct, 2017 4 commits
-
-
Benedikt Meurer authored
The contract in TurboFan is that "the hole" is never passed to "user JavaScript", which we unfortunately still don't check strictly. Now the inlined code for Array#forEach properly checks for "the hole", but the type of the element Node passed to the callback function doesn't reflect that. So introduce a proper TypeGuard here to reflect this check. This will also improve code generation for iteration of HOLEY arrays better and might improve performance a bit. Bug: v8:1956 Change-Id: Ib6b3c444b16fcf44551bda1b39f976d66b9362ab Reviewed-on: https://chromium-review.googlesource.com/705954Reviewed-by:
Daniel Clifford <danno@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48400}
-
Mike Stanton authored
In call reductions for Array.prototype.map and forEach, loads weren't wired appropriately into the effect chain, hampering the efficacy of load elimination. Bug: Change-Id: If5a386b66669d7173d5cadc6d8d3ff023daed810 Reviewed-on: https://chromium-review.googlesource.com/707073Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#48376}
-
Michael Starzinger authored
R=mvstanton@chromium.org BUG=chromium:770581 TEST=mjsunit/regress/regress-crbug-770581 Change-Id: I3a5854b6534e67da3e28d9c713830808013675b5 Reviewed-on: https://chromium-review.googlesource.com/702378Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48375}
-
Mike Stanton authored
We can use the known ElementsKind to improve typing on the receiver element load. We can allow multiple maps, as long as they have the same ElementsKind. Bug: v8:6896 Change-Id: Ida7df943f7d315454b58bcf4e0bbd2346406c488 Reviewed-on: https://chromium-review.googlesource.com/704921 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48367}
-
- 04 Oct, 2017 1 commit
-
-
Daniel Clifford authored
In the process, also enable support for PACKED_DOUBLE_ELEMENTS arrays. Change-Id: I16dd79276f1023e30b072d45216396533077f53c Reviewed-on: https://chromium-review.googlesource.com/571006 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48289}
-
- 19 Sep, 2017 1 commit
-
-
Jaroslav Sevcik authored
This reverts commit 37aa13fe. Reason for revert: Suspected to break 63.0.3219 Canary Original change's description: > [Turbofan] Array.prototype.filter inlining. > > Support inlining of Array.prototype.filter in TurboFan. > > Bug: v8:1956 > Change-Id: Iba4d683aaa86c6104e8a1cf4d0f549a0c516576a > Reviewed-on: https://chromium-review.googlesource.com/657021 > Commit-Queue: Michael Stanton <mvstanton@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48040} TBR=mvstanton@chromium.org,mstarzinger@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:1956 Change-Id: I125a8caf128890d788e040adfe2fc76bd8d1fbea Reviewed-on: https://chromium-review.googlesource.com/672783Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#48083}
-
- 15 Sep, 2017 1 commit
-
-
Mike Stanton authored
Support inlining of Array.prototype.filter in TurboFan. Bug: v8:1956 Change-Id: Iba4d683aaa86c6104e8a1cf4d0f549a0c516576a Reviewed-on: https://chromium-review.googlesource.com/657021 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48040}
-
- 11 Sep, 2017 1 commit
-
-
Michael Starzinger authored
R=clemensh@chromium.org Change-Id: If0554f01068fb76228e85cfe120630eda86de41d Reviewed-on: https://chromium-review.googlesource.com/659997Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47945}
-
- 08 Sep, 2017 1 commit
-
-
Benedikt Meurer authored
Add support to the JSCallReducer to recognize JSConstruct nodes where the target is the Object constructor, and reduce them to JSCreate nodes if either (a) no value is passed to the Object constructor, or (b) the target and new.target are definitely not identical, by checking whether both target and new.target are different HeapConstants (if they are not, then the JSCreateLowering will not be able to do a lot with the JSCreate anyways). This should cover the relevant cases for subclassing appropriately. It fixes the 3-4x slowdown on the micro-benchmark mentioned in the linked bug, baseNoExtends: 752 ms. baseExtendsObject: 752 ms. baseExtendsViaFactory: 751 ms. and thus removes the performance cliff. R=jarin@chromium.org Bug: v8:6801 Change-Id: Id265fd1399302a67b5790a6d0156679920c58bdd Reviewed-on: https://chromium-review.googlesource.com/657019Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47913}
-
- 07 Sep, 2017 2 commits
-
-
Benedikt Meurer authored
Bug: v8:6772 Tbr: jarin@chromium.org Change-Id: I48b21fbdec42d4b1c10800913f7fa222a5509a8d Reviewed-on: https://chromium-review.googlesource.com/654873Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47897}
-
Benedikt Meurer authored
Introduce NodeProperties::NoObservableSideEffectBetween to check if there's any observable side effect between two nodes in the effect chain. Use this to guard the insertion of potentially redundant map checks in the lowering of Object.prototype.hasOwnProperty and keyed accesses within a for..in loop. This gives another boost on the for..in performance front. Bug: v8:6702 Change-Id: I68133f14ad388a1a7422714319c9b323d5cf8bc4 Reviewed-on: https://chromium-review.googlesource.com/654640Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#47869}
-
- 01 Sep, 2017 1 commit
-
-
Benedikt Meurer authored
This CL adds support to optimize for..in in fast enum-cache mode to the same degree that it was optimized in Crankshaft, without adding the same deoptimization loop that Crankshaft had with missing enum cache indices. That means code like for (var k in o) { var v = o[k]; // ... } and code like for (var k in o) { if (Object.prototype.hasOwnProperty.call(o, k)) { var v = o[k]; // ... } } which follows the https://eslint.org/docs/rules/guard-for-in linter rule, can now utilize the enum cache indices if o has only fast properties on the receiver, which speeds up the access o[k] significantly and reduces the pollution of the global megamorphic stub cache. For example the micro-benchmark in the tracking bug v8:6702 now runs faster than ever before: forIn: 1516 ms. forInHasOwnProperty: 1674 ms. forInHasOwnPropertySafe: 1595 ms. forInSum: 2051 ms. forInSumSafe: 2215 ms. Compared to numbers from V8 5.8 which is the last version running with Crankshaft forIn: 1641 ms. forInHasOwnProperty: 1719 ms. forInHasOwnPropertySafe: 1802 ms. forInSum: 2226 ms. forInSumSafe: 2409 ms. and V8 6.0 which is the current stable version with TurboFan: forIn: 1713 ms. forInHasOwnProperty: 5417 ms. forInHasOwnPropertySafe: 5324 ms. forInSum: 7556 ms. forInSumSafe: 11067 ms. It also improves the throughput on the string-fasta benchmark by around 7-10%, and there seems to be a ~5% improvement on the Speedometer/React benchmark locally. For this to work, the ForInPrepare bytecode was split into ForInEnumerate and ForInPrepare, which is very similar to how it was handled in Fullcodegen initially. In TurboFan we introduce a new operator LoadFieldByIndex that does the dynamic property load. This also removes the CheckMapValue operator again in favor of just using LoadField, ReferenceEqual and CheckIf, which work automatically with the EscapeAnalysis and the BranchConditionElimination. Bug: v8:6702 Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a Reviewed-on: https://chromium-review.googlesource.com/645949 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47768}
-
- 31 Aug, 2017 1 commit
-
-
Benedikt Meurer authored
When calling Object(value) where the value is known to be a JSReceiver, we can just replace it with value, as the Object constructor call is a no-op in that case. Otherwise when value is known to be not null or undefined then we can replace the Object constructor call with an invocation of ToObject. This covers the common pattern found in bundles generated by Webpack, where the Object constructor is used to call imported functions, i.e. Object(module.foo)(1, 2, 3) There's a lot of detail in https://github.com/webpack/webpack/issues/5600 on this matter and why this pattern was chosen. Bug: v8:6772 Change-Id: I2b4f0b4542b68b97b337ce571d6d79946c73d8bb Reviewed-on: https://chromium-review.googlesource.com/643868Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47728}
-
- 28 Aug, 2017 1 commit
-
-
Benedikt Meurer authored
Optimize the common pattern for (var i in o) { if (Object.prototype.hasOwnProperty.call(o, i)) { // do something } } which is part of the guard-for-in style in ESLint (see the documentation at https://eslint.org/docs/rules/guard-for-in for details). This pattern also shows up in React and Ember applications quite a lot (and is tested by the appropriate Speedometer benchmarks, although not dominating those benchmarks, since they spent a lot of time in non-TurboFan'ed code). This improves the forInHasOwnProperty and forInHasOwnPropertySafe micro- benchmarks in v8:6702, which look like this function forInHasOwnProperty(o) { var result = 0; for (var i in o) { if (o.hasOwnProperty(i)) { result += 1; } } return result; } function forInHasOwnPropertySafe(o) { var result = 0; for (var i in o) { if (Object.prototype.hasOwnProperty.call(o, i)) { result += 1; } } return result; } by around 4x and allows for additional optimizations in the future, by also elimiating the megamorphic load when accessing the enumerated properties. This changes the interpreter ForInNext bytecode to collect more precise feedback about the for-in state, which now consists of three individual states: UNINITIALIZED, MEGAMORPHIC and GENERIC. The MEGAMORPHIC state means that the ForInNext has only seen objects with a usable enum cache thus far, whereas GENERIC means that we have seen some slow-mode for..in objects as well. R=jarin@chromium.org Bug: v8:6702 Change-Id: Ibcd75ea9b58c3b4f9219f11bc37eb04a2b985604 Reviewed-on: https://chromium-review.googlesource.com/636964 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47632}
-
- 24 Aug, 2017 1 commit
-
-
Yuki Shiino authored
In case of LAP(lazy accessor pair), the function's creation context must be equal to the accessor holder's creation context, so this CL changes the current context to the accessor holder's creation context. Note that this is the second attempt after https://crrev.com/2770003002 The change from the previous attempt is to skip looking for the object's constructor if the object itself is a function. Also some of Blink's LAP-context-sensitive tests got updated at https://crrev.com/c/597990 and the rest of the tests will get temporarily disabled at https://crrev.com/c/605408 . TBR=verwaest@chromium.org Bug: v8:6156 Change-Id: I09709a90995d82a03996d0347e5a1d8425b5db9c Reviewed-on: https://chromium-review.googlesource.com/563152 Commit-Queue: Yuki Shiino <yukishiino@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#47572}
-
- 09 Aug, 2017 1 commit
-
-
Benedikt Meurer authored
Don't return NoChange when the new_target input to a JSConstruct node is already a HeapConstant, but rather use that constant in the interesting lowering below. This was introduced accidentally by https://chromium-review.googlesource.com/604790 earlier. Also don't use ShouldUseCallICFeedback predicate here, as that doesn't really make sense for JSConstruct, but is mostly interesting for JSCall (hence the name). Bug: v8:5517, v8:6399, v8:6679 Change-Id: I96201281cf1a10f2bfd2dc3859455161eb310ccf Reviewed-on: https://chromium-review.googlesource.com/607887Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47237}
-
- 08 Aug, 2017 1 commit
-
-
Benedikt Meurer authored
Change the CALL_IC machinery inside of Ignition to collect new.target feedback for Construct and ConstructWithSpread bytecodes instead of collecting feedback about the target, and adapt TurboFan's JSCallReducer to consume feedback for new.target instead of target on JSConstruct nodes. This enables TurboFan to inline JSCreate - and thus the actual instance allocation - into derived leaf constructors even if the leaf constructor itself is not inlined, and thereby removes this weird performance cliff. The feedback for target in case of class constructors is provided by the function context specialization, and in case of `new A`, we can just use the feedback for new.target, as both target and new.target are A in that case. Bug: v8:5517, v8:6399, v8:6679 Change-Id: I0475e2500e787fd672ed037ac0faed78a8fa5dc0 Reviewed-on: https://chromium-review.googlesource.com/604790Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47210}
-
- 07 Aug, 2017 4 commits
-
-
Benedikt Meurer authored
Drop the deprecated CallConstructStub and remove the use of CallICStub from fullcodegen, since that feedback is unused completely every since Crankshaft got removed, thus we can safely unlink all the CallIC stuff from fullcodegen nowadays, and completely nuke the CallICStub and the CallICTrampolineStub now (we can also transitively nuke the unused CreateAllocationSiteStub and CreateWeakCellStub). Instead the CallIC logic is integrated into Ignition now, and part of the bytecode handlers for [[Call]] and [[Construct]]. There's still some follow-up cleanup with the way the Array constructor feedback is integrated, but that's way easier now. Bug: v8:5517, v8:6399, v8:6409, v8:6679 Change-Id: I0a6c6046faceca9b1606577bc9e63d9295e44619 Reviewed-on: https://chromium-review.googlesource.com/603609 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47196}
-
Benedikt Meurer authored
As of https://chromium-review.googlesource.com/600968 the CallIC no longer supports AllocationSite feedback for [[Call]], so we can drop the TurboFan bits that deal with AllocationSites for JSCall nodes as well. This further simplifies the handling of the Array constructor. Drive-by-fix: Rename Builtins::kArrayCode to Builtins::kArrayConstructor for sake of consistency. Bug: v8:6399 Change-Id: I9e6a684fc00dd72e25f925db5f407c3f3f715873 Reviewed-on: https://chromium-review.googlesource.com/602354 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47194}
-
Michael Achenbach authored
This reverts commit 6c541561. Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap/builds/17240 Original change's description: > [ic] Properly integrate the CallIC into Ignition. > > Drop the deprecated CallConstructStub and remove the use of CallICStub > from fullcodegen, since that feedback is unused completely every since > Crankshaft got removed, thus we can safely unlink all the CallIC stuff > from fullcodegen nowadays, and completely nuke the CallICStub and the > CallICTrampolineStub now (we can also transitively nuke the unused > CreateAllocationSiteStub and CreateWeakCellStub). > > Instead the CallIC logic is integrated into Ignition now, and part of > the bytecode handlers for [[Call]] and [[Construct]]. There's still some > follow-up cleanup with the way the Array constructor feedback is > integrated, but that's way easier now. > > Bug: v8:5517, v8:6399, v8:6409, v8:6679 > Change-Id: Ia0efc6145ee64633757a6c3fd1879d4906ea2835 > Reviewed-on: https://chromium-review.googlesource.com/602134 > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47192} TBR=rmcilroy@chromium.org,yangguo@chromium.org,bmeurer@chromium.org Change-Id: I416ce6646f62ceb4127b3acee43912ee0d701c23 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:5517, v8:6399, v8:6409, v8:6679 Reviewed-on: https://chromium-review.googlesource.com/603647Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#47193}
-
Benedikt Meurer authored
Drop the deprecated CallConstructStub and remove the use of CallICStub from fullcodegen, since that feedback is unused completely every since Crankshaft got removed, thus we can safely unlink all the CallIC stuff from fullcodegen nowadays, and completely nuke the CallICStub and the CallICTrampolineStub now (we can also transitively nuke the unused CreateAllocationSiteStub and CreateWeakCellStub). Instead the CallIC logic is integrated into Ignition now, and part of the bytecode handlers for [[Call]] and [[Construct]]. There's still some follow-up cleanup with the way the Array constructor feedback is integrated, but that's way easier now. Bug: v8:5517, v8:6399, v8:6409, v8:6679 Change-Id: Ia0efc6145ee64633757a6c3fd1879d4906ea2835 Reviewed-on: https://chromium-review.googlesource.com/602134 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47192}
-
- 27 Jul, 2017 1 commit
-
-
Michael Starzinger authored
This fixes the second-order Array.prototype function {forEach} and {map} to now perform a callability check of the given callback function. For empty arrays it is observable whether such a check outside the loop has been elided or not. R=mvstanton@chromium.org TEST=mjsunit/regress/regress-crbug-747062 BUG=chromium:747062 Change-Id: I1bbe7f44b3b3d18e9b41ad0436975434adf84321 Reviewed-on: https://chromium-review.googlesource.com/588893Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#46942}
-
- 24 Jul, 2017 2 commits
-
-
Michael Starzinger authored
This adds handling for exceptional control projections when lowering calls to {Array.prototype.forEach} in the call reducer. R=jarin@chromium.org TEST=mjsunit/optimized-foreach BUG=v8:1956 Change-Id: I282048b203814cbc1c90df983879578b210f92fb Reviewed-on: https://chromium-review.googlesource.com/574542 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#46834}
-
Benedikt Meurer authored
Properly hook up the (existing) IC slots for the CallWithSpread and ConstructWithSpread bytecodes, and change the interpreter to collect feedback (call counts and regular target function feedback) for those. There's no integration with the Array constructor yet, since that requires some yak shaving to thread through the AllocationSite to the Array constructor stub. Once we have a solution for that, we can also remove the current code duplication in the Call/Construct IC logic. Also properly hook up the newly available feedback in TurboFan. This will fix not only the missing target feedback, but more importantly the tear-up decisions for optimization are correct now in the presence of spread calls, and even more importantly the inlining heurstic has proper call frequencies for those. Some follow-up changes will be necessary to make sure we use the feedback even for corner cases that aren't handled properly yet. Also we should consider collecting feedback about the map of the spread at some point to be able to always inline the spread calls. Bug: v8:6399, v8:6527, v8:6630 Change-Id: I818dbcb411fd3951d8e9d31f5d7e794f8d60fa00 Reviewed-on: https://chromium-review.googlesource.com/582647Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#46832}
-
- 20 Jul, 2017 1 commit
-
-
Camillo Bruni authored
- add some more const to Context getters Change-Id: Ia7560b33cae71a6015515e4337b464648e03a6f2 Reviewed-on: https://chromium-review.googlesource.com/575993Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#46799}
-
- 19 Jul, 2017 2 commits
-
-
Ross McIlroy authored
There remained a few of regressions and we didn't see any significant improvement in the real world with this turned on. This CL reverts all the StringConcat bytecode work which landed. BUG=v8:6243 Change-Id: I832eb72e880ad41411dbec8fe29f71ef0f2025c8 Reviewed-on: https://chromium-review.googlesource.com/575130 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46769}
-
Michael Starzinger authored
This adds handling for exceptional control projections when lowering calls to {Array.prototype.map} in the call reducer. R=mvstanton@chromium.org TEST=mjsunit/optimized-map BUG=v8:1956 Change-Id: If39ee836bbc3406a7fca4bad0d2c9321130cae2a Reviewed-on: https://chromium-review.googlesource.com/575928 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#46755}
-
- 17 Jul, 2017 1 commit
-
-
Daniel Clifford authored
Bug=chromium:740784 LOG=N Change-Id: I61fe1b07426d0b1e5131687c9ce99a8dbfa09781 Reviewed-on: https://chromium-review.googlesource.com/574175 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#46706}
-
- 14 Jul, 2017 1 commit
-
-
Benedikt Meurer authored
This CL inlines the following builtins into TurboFan - %MapIteratorPrototype%.next - %SetIteratorPrototype%.next following the design that we are using for Array iteration already (different instance types for the different kinds of iterators). Details can be found in the relevant design document at: https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8 The key to great performance here is to ensure that the inlined code allows escape analysis and scalar replacement of aggregates to remove the allocations for the iterator itself as well as the iterator results and potential key/value arrays in the simple case of a for-of loop (and by extension also in other constructs that reduce to for-of loops internally), i.e.: const s = new Set; // ... do something with s for (const x of s) { // ... } Here the for-of loop shouldn't perform any allocations of helper objects. Drive-by-fix: Replace the ExistsJSMapWithness in JSBuiltinReducer with a more general HasInstanceTypeWitness, similar to what's in JSCallReducer. Also migrate the {Map,Set}.prototype.size getter inlining to the JSBuiltinReducer, so that everything is in a single place. R=jgruber@chromium.org Bug: v8:6344, v8:6571, chromium:740122 Change-Id: I09cb506fe26ed3e10d7dcb2f95ec4415e639582d Reviewed-on: https://chromium-review.googlesource.com/570159Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#46655}
-
- 13 Jul, 2017 2 commits
-
-
Adam Klein authored
The tail call implementation is hidden behind the --harmony-tailcalls flag, which is off-by-default (and has been unstaged since February). It is known to be broken in a variety of cases, including clusterfuzz security issues (see sample Chromium issues below). To avoid letting the implementation bitrot further on trunk, this patch removes it. Bug: v8:4698, chromium:636914, chromium:724746 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I9cb547101456a582374fdf7b1a3f044a9ef33e5c Reviewed-on: https://chromium-review.googlesource.com/569069 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46651}
-
Mike Stanton authored
Bug: v8:1956 Change-Id: I41af0cf5eb2fbb9f1d9d4172f3f546bcc2a715dc Reviewed-on: https://chromium-review.googlesource.com/548639 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#46618}
-
- 11 Jul, 2017 2 commits
-
-
Michael Starzinger authored
This fixes the lowering of Reflect.getPrototypeOf and friends to not perform a [[ToObject]] coercion, but bailout instead. We ensure to exclude primitive values from the lowering. This makes the lowering uniform between "Reflect.getPrototypeOf" and "Object.getPrototypeOf". R=bmeurer@chromium.org TEST=mjsunit/regress/regress-crbug-740116 BUG=chromium:740116 Change-Id: If986ee2a3ae4e8f1fd227bdeb4668f523b0dea84 Reviewed-on: https://chromium-review.googlesource.com/565295Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#46556}
-
Benedikt Meurer authored
Add support for fast - get Map.prototype.size - get Set.prototype.size by porting both the baseline implementation to the CodeStubAssembler and inlining a fast-path into TurboFan (when the compiler can infer the fact that the receiver is a proper JSCollection from the surrounding graph, i.e. from feedback gathered by a dominating LOAD_IC). R=yangguo@chromium.org Bug: v8:5269, v8:5717 Change-Id: Ie003fd2551462591273bcb8487b80808dcc6cd82 Reviewed-on: https://chromium-review.googlesource.com/566438 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#46555}
-
- 10 Jul, 2017 1 commit
-
-
Daniel Clifford authored
BUG=v8:1956 LOG=N R=bmeurer@chromium.org Change-Id: I190002227d3321df0f68e77f3b7b0a468446c493 Reviewed-on: https://chromium-review.googlesource.com/561011 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#46513}
-