- 17 Jun, 2019 1 commit
-
-
Ross McIlroy authored
Bug: v8:8801,v8:8394,v8:9183 Change-Id: I55027b3ba0c78f40d82aaf2d160aaf957d02cab5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662292 Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#62214}
-
- 05 Mar, 2018 1 commit
-
-
Benedikt Meurer authored
This changes the JSArrayIterator to always have only a single instance type, instead of the zoo of instance types that we had before, and which became less useful with the specification update to when "next" is loaded from the iterator now. This greatly simplifies the baseline implementation of the array iterator, which now only looks at the iterated object during %ArrayIteratorPrototype%.next invocations. In TurboFan we introduce a new JSCreateArrayIterator operator, that holds the IterationKind and get's the iterated object as input. When optimizing %ArrayIteratorPrototype%.next in the JSCallReducer, we check whether the receiver is a JSCreateArrayIterator, and if so, we try to infer maps for the iterated object from there. If we find any, we speculatively assume that these won't have changed during iteration (as we did before with the previous approach), and generate fast code for both JSArray and JSTypedArray iteration. Drive-by-fix: Drop the fast_array_iteration protector, it's not necessary anymore since we have the deoptimization guard bit in the JSCallReducer now. This addresses the performance cliff noticed in webpack 4. The minimal repro on the tracking bug goes from console.timeEnd: mono, 124.773000 console.timeEnd: poly, 670.353000 to console.timeEnd: mono, 118.709000 console.timeEnd: poly, 141.393000 so that's a 4.7x improvement. Also make presubmit happy by adding the missing #undef's. Bug: v8:7510, v7:7514 Change-Id: I79a46bfa2cd0f0710e09365ef72519b1bbb667b5 Reviewed-on: https://chromium-review.googlesource.com/946098Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51725}
-
- 28 Apr, 2017 1 commit
-
-
Mythri authored
1. Replaces --crankshaft with --opt in tests. 2. Also fixes presubmit to check for --opt flag when assertOptimized is used. 3. Updates testrunner/local/variants.py and v8_foozie.py to use --opt flag. This would mean, nooptimize variant means there are no optimizations. Not even with %OptimizeFunctionOnNextCall. Bug:v8:6325 Change-Id: I638e743d0773a6729c6b9749e2ca1e2537f12ce6 Reviewed-on: https://chromium-review.googlesource.com/490206 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#44985}
-
- 26 Jan, 2017 1 commit
-
-
ishell authored
This CL adds --crankshaft and --no-always-opt flags to the tests that use assertOptimized() and assertUnoptimized() respectively. This CL also adds presubmit checks that ensure that tests have the proper flags set. BUG=v8:5890 Review-Url: https://codereview.chromium.org/2653753007 Cr-Commit-Position: refs/heads/master@{#42709}
-
- 02 Jan, 2017 1 commit
-
-
bmeurer authored
When Crankshaft compiles a keyed load to arguments, it disabled optimization unless the KEYED_LOAD_IC for the access was monomorphic. But that's too restrictive, since it will also disable optimization for this function when the access is on a path that was never executed so far. This was spotted in the Node.js core function EventEmitter.prototype.emit, which was no longer optimizable with Crankshaft using latest V8. R=jarin@chromium.org BUG=v8:5790 Review-Url: https://codereview.chromium.org/2607303002 Cr-Commit-Position: refs/heads/master@{#42005}
-