- 18 Oct, 2018 1 commit
-
-
Georg Neis authored
We forgot to eliminate the read accesses of these two cells. Bug: v8:7790, v8:8315 Change-Id: Id175e4d96461f88759b2d29ab1d407ba4c54e733 Reviewed-on: https://chromium-review.googlesource.com/c/1286680Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#56752}
-
- 15 Oct, 2018 1 commit
-
-
Georg Neis authored
There's no ambiguity and the shorter name makes things easier to read. Bug: v8:7790 Change-Id: Ibcf3fd7f38a91e26a83cd335fad0ec80a5fe9be1 Reviewed-on: https://chromium-review.googlesource.com/c/1278392 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#56623}
-
- 11 Oct, 2018 1 commit
-
-
Benedikt Meurer authored
This JSAsyncFunctionObject represents the implicit generator object inside of async functions, and also holds the outer promise for the async functions. This in turn allows us to get rid of the .promise in the Parser / BytecodeGenerator completely, and will make it possible to build zero-cost async stack traces independent of the concrete synchronous part of the stack frame (which currently breaks in Node.js). In the bytecode all the async function operations now take this new JSAsyncFunctionObject instead of passing both the .generator_object and the .promise, which further simplifies and shrinks the bytecode. It also reduces the size of async function frames, potentially making the suspend/resume cheaper. This also changes `await` to use intrinsics instead of calling to special JSFunctions on the native context, and thus reduces the size of the native contexts. Drive-by-fix: Introduce a dedicated JSCreateAsyncFunctionObject operator to TurboFan. Bug: v8:7253, v8:7522 Change-Id: I2305302285156aa1f71328ecac70377abdd92c80 Ref: nodejs/node#11865 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1273049 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56554}
-
- 01 Oct, 2018 1 commit
-
-
Jaroslav Sevcik authored
Currently, we call the MapRef::AsElementsKind method on an initial map multiple times (from JSCreateLowering::ReduceJSCreateArray). However, this does not does not play well with the heap copier/broker, which only expectes AsElementsKind to be called on initial maps. This CL makes sure we only call AsElementsKind once (on the initial map). Bug: chromium:890620 Change-Id: If44421d3900abb7629ea8f789a005b8d8ebaf881 Reviewed-on: https://chromium-review.googlesource.com/1253105Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#56307}
-
- 26 Sep, 2018 1 commit
-
-
Jaroslav Sevcik authored
Bug: v8:8230 Change-Id: Ibf93300cd54c6d5053ebed0cb897b4068f2bc160 Reviewed-on: https://chromium-review.googlesource.com/1245768 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#56242}
-
- 19 Sep, 2018 1 commit
-
-
Georg Neis authored
Instead, remember the canonical handle during SerializeStandardObjects. Bug: v8:7790 Change-Id: Id57d861e92088fbc64c05fbee1612376000c06c9 Reviewed-on: https://chromium-review.googlesource.com/1233494Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#56029}
-
- 17 Sep, 2018 1 commit
-
-
Florian Sattler authored
Fixing clang-tidy warning. Bug: v8:8015 Change-Id: I7d885f0e2ba3cdf97de190166dc4cdd24dc0c11e Reviewed-on: https://chromium-review.googlesource.com/1224091 Commit-Queue: Florian Sattler <sattlerf@google.com> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#55956}
-
- 08 Aug, 2018 1 commit
-
-
Jaroslav Sevcik authored
The idea is to compute the slack before compilation start. Then we check that the slack tracking decision is the same at the end of compilation. If it is, we just commit to that slack tracking (by calling function->CompleteInobjectSlackTrackingIfActive). If the slack tracking decision changed, we will retry the compilation. This has several pieces: - Expose computation of slack and instance size from the object model. - Add compilation dependency on the slack tracking result. - Change create lowering to use the dependency. - Fix array creation to use the slack tracking result's instance size. Bug: v8:7790 Change-Id: Id975300cfd6c1786733cd7cbf55cc507c05738b2 Reviewed-on: https://chromium-review.googlesource.com/1164957Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#54982}
-
- 23 Jul, 2018 1 commit
-
-
Georg Neis authored
We'll soon start collecting data from the JS heap prior to the typed lowering pass, and then refrain from reading the heap in that pass. This CL prepares the broker machinery by introducing a hash table that maps an object (handle) to the corresponding cached data. For the time being, that cached data is essentially just the handle itself. Bug: v8:7790 Change-Id: I830e9c72faafb7ae1d10e8a111636b3a3762bbc6 Reviewed-on: https://chromium-review.googlesource.com/1143405 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#54618}
-
- 18 Jul, 2018 1 commit
-
-
Maya Lekova authored
Bug: v8:7790 Change-Id: I12c159ade57a0974c6adc5b277a0b5fd74fd4dfb Reviewed-on: https://chromium-review.googlesource.com/1140313 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#54516}
-
- 06 Jul, 2018 1 commit
-
-
Georg Neis authored
- Move the CompilationDependencies member of OptimizedCompilationInfo to Turbofan's PipelineData (and thus into the compiler namespace). - Move compilation-dependencies.{cc,h} to the compiler directory. Bug: v8:7902 Change-Id: I5471d0923daf83abe975357325db5bc5ad0a8571 Reviewed-on: https://chromium-review.googlesource.com/1127793 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#54295}
-
- 02 Jul, 2018 1 commit
-
-
Jaroslav Sevcik authored
Bug: v8:7790 Change-Id: I5e12f49038f569187b751cc07a3bfad5eb904949 Reviewed-on: https://chromium-review.googlesource.com/1121460 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#54131}
-
- 27 Jun, 2018 1 commit
-
-
Jaroslav Sevcik authored
Bug: v8:7790 Change-Id: Ieeafcb7260ef577c3d64c029a50c2ed34b63fe1b Reviewed-on: https://chromium-review.googlesource.com/1116555Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#54054}
-
- 25 Jun, 2018 1 commit
-
-
Jaroslav Sevcik authored
This does not move the dependency management there, yet. Bug: v8:7790 Change-Id: Ia8b473a89c2853ffeba4adf84ac8814f403279c9 Reviewed-on: https://chromium-review.googlesource.com/1112256 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#54004}
-
- 20 Jun, 2018 1 commit
-
-
Jaroslav Sevcik authored
Bug: v8:7790 Change-Id: I6a6347d7394ddeacbb185a2e6e5187898bfca2dc Reviewed-on: https://chromium-review.googlesource.com/1106173Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#53868}
-
- 07 Jun, 2018 1 commit
-
-
Jaroslav Sevcik authored
As a first step towards moving accesses to the broker, this moves heap accesses from BitsetType::Lub to the broker. Bug: v8:7790 Change-Id: Ie240b84b979717caae42cb8aa06ee8d9877a446d Reviewed-on: https://chromium-review.googlesource.com/1088695 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53571}
-
- 19 Apr, 2018 1 commit
-
-
Sigurd Schneider authored
This also adds a javascript operator JSCreateObject and an associated TFS stub that handles Object.create in cases where only a prototype, but no additional properties are provided. Bug: v8:7250 Change-Id: Ib1fd529a10a553c3718222356319bd6ccffbdf30 Reviewed-on: https://chromium-review.googlesource.com/1013576 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#52680}
-
- 04 Apr, 2018 1 commit
-
-
Sigurd Schneider authored
Bug: v8:7340, v8:7250 Change-Id: I57f78fa5ad261f041b66986918c427821a57a6e1 Reviewed-on: https://chromium-review.googlesource.com/995472Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#52356}
-
- 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}
-
- 23 Feb, 2018 3 commits
-
-
Sigurd Schneider authored
This is a reland of 3ff4b447. Original version did not handle V8_INTL_SUPPORT. Original change's description: > [turbofan] Move String.* functions to JSCallReducer > > Bug: v8:7250, v8:7340 > Change-Id: Ibb8d5badf89c66bd9bcb6bb390256ae81d0e899c > Reviewed-on: https://chromium-review.googlesource.com/913208 > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#51505} Bug: v8:7250, v8:7340 Change-Id: Id908cbcfaa9e9cf5459d6d3289e6ec00e387d287 Reviewed-on: https://chromium-review.googlesource.com/934268Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#51514}
-
Sigurd Schneider authored
This reverts commit 3ff4b447. Reason for revert: Does not handle V8_INTL_SUPPORT correctly Original change's description: > [turbofan] Move String.* functions to JSCallReducer > > Bug: v8:7250, v8:7340 > Change-Id: Ibb8d5badf89c66bd9bcb6bb390256ae81d0e899c > Reviewed-on: https://chromium-review.googlesource.com/913208 > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#51505} TBR=sigurds@chromium.org,bmeurer@chromium.org Change-Id: I6efb3b758b0fcadc012a90c4175de3c1ebccee95 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7250, v8:7340 Reviewed-on: https://chromium-review.googlesource.com/934267Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#51507}
-
Sigurd Schneider authored
Bug: v8:7250, v8:7340 Change-Id: Ibb8d5badf89c66bd9bcb6bb390256ae81d0e899c Reviewed-on: https://chromium-review.googlesource.com/913208 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51505}
-
- 24 Jan, 2018 1 commit
-
-
Benedikt Meurer authored
This adds a new operator JSCreatePromise, which currently allocates a native JSPromise instance and initializes it to pending state. In addition to that we introduce a new PromiseHookProtector, which get's invalidated the first time someone enables the debugger or installs a PromiseHook (via async_hooks for example). As long as the protector is intact we lower AsyncFunctionPromiseCreate to JSCreatePromise and AsyncFunctionPromiseRelease to a no-op in optimized code. This yields a speedup of roughly 33% on the benchmark mentioned in the bug. Bug: v8:7271, v8:7253 Change-Id: Ib5d219f2b6e052a7cc5e6ed5aa66dd3c8885a859 Reviewed-on: https://chromium-review.googlesource.com/883124 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#50849}
-
- 17 Oct, 2017 2 commits
-
-
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}
-
Marja Hölttä authored
BUG=v8:5402,v8:6921 Change-Id: Iab2509554718a6beca73217f80cafedf650bd066 Reviewed-on: https://chromium-review.googlesource.com/718741Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#48629}
-
- 06 Oct, 2017 2 commits
-
-
Benedikt Meurer authored
Make calls like new Array(n) new A(n) (where A is a subclass of Array) inlinable into TurboFan. We do this by speculatively checking that n is an unsigned integer that is not greater than JSArray::kInitialMaxFastElementArray, and then lowering the backing store allocation to a builtin call. The speculative optimization is either protected by the AllocationSite for the Array constructor invocation (if we have one), or by a newly introduced global protector cell that is used for Array constructor invocations that don't have an AllocationSite, i.e. the ones from Array#map, Array#filter, or from subclasses of Array. Next step will be to implement the backing store allocations inline in TurboFan, but that requires Loop support in the GraphAssembler, so it's done as a separate CL. This should further boost the performance. This boosts the ARES6 ML benchmark by up to 8% on the steady state, and also improves monomorphic Array#map calls by around 20-25% on the initial setup. Bug: v8:6399 Tbr: ulan@chromium.org Change-Id: I7c8bdecf7c814ce52db6ee3051c3206a4f7d4bb6 Reviewed-on: https://chromium-review.googlesource.com/704639 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#48348}
-
Benedikt Meurer authored
Array (subclass) constructor calls with 0 parameters are now properly turned into inline allocations, also Array (subclass) constructor calls with exactly one parameter, which is either known to not be a Number or which is a known integer in the valid loop unrolling range. Also refactor the general JSCreateArray lowering logic to properly support Array subclasses, i.e. deal with inobject properties and initial maps correctly. This boosts performance of those cases significantly (and will allow us to reduce the complexity of the Array constructor significantly long-term). For example the simple case new Array("a", "b", "c", "d", "e", "f", "g") is now around 10x faster than before. Bug: v8:6399 Change-Id: I70661971398524ee0c6a349ee559b98a962a6266 Reviewed-on: https://chromium-review.googlesource.com/703134 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48325}
-
- 28 Sep, 2017 1 commit
-
-
Michael Starzinger authored
This is a reland of 9d3c4b4b Original change's description: > [turbofan] Implement lowering of {JSCreateClosure}. > > This adds support for inline allocation of {JSFunction} objects as part > of closures instantiation for {JSCreateClosure} nodes. The lowering is > limited to instantiation sites which have already seen more than one > previous instantiation, this avoids the need to increment the respective > counter. > > R=jarin@chromium.org > > Change-Id: I462c557453fe58bc5f09020a3d5ebdf11c2ea68b > Reviewed-on: https://chromium-review.googlesource.com/594287 > Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48176} Change-Id: I3ec3880bea89798a34a3878e6122b95db1014151 Reviewed-on: https://chromium-review.googlesource.com/686834Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48198}
-
- 27 Sep, 2017 2 commits
-
-
Michael Starzinger authored
This reverts commit 9d3c4b4b. Reason for revert: Breaks cctest/test-debug/NoBreakWhenBootstrapping in no-snap mode. Original change's description: > [turbofan] Implement lowering of {JSCreateClosure}. > > This adds support for inline allocation of {JSFunction} objects as part > of closures instantiation for {JSCreateClosure} nodes. The lowering is > limited to instantiation sites which have already seen more than one > previous instantiation, this avoids the need to increment the respective > counter. > > R=jarin@chromium.org > > Change-Id: I462c557453fe58bc5f09020a3d5ebdf11c2ea68b > Reviewed-on: https://chromium-review.googlesource.com/594287 > Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48176} TBR=mstarzinger@chromium.org,jarin@chromium.org Change-Id: Id52281f6a3c0b7c2603053ecf002777d5b0d6f1f No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/686534Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48178}
-
Michael Starzinger authored
This adds support for inline allocation of {JSFunction} objects as part of closures instantiation for {JSCreateClosure} nodes. The lowering is limited to instantiation sites which have already seen more than one previous instantiation, this avoids the need to increment the respective counter. R=jarin@chromium.org Change-Id: I462c557453fe58bc5f09020a3d5ebdf11c2ea68b Reviewed-on: https://chromium-review.googlesource.com/594287 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48176}
-
- 25 Sep, 2017 1 commit
-
-
Benedikt Meurer authored
When inlining based on SharedFunctionInfo rather than based on concrete JSFunction, we weren't able to properly optimize array, object and regexp literals inside the inlinee, because we didn't know the concrete FeedbackVector for the inlinee inside JSCreateLowering. This was because JSCreateLowering wasn't properly updated after the literals moved to the FeedbackVector. Now with this CL we also have the VectorSlotPair on the literal creation operators, just like we do for property accesses and calls, and are thus able to always access the appropriate FeedbackVector and optimize the literal creation. The impact is illustrated by the micro-benchmark on the tracking bug, which goes from createEmptyArrayLiteral: 1846 ms. createShallowArrayLiteral: 1868 ms. createShallowObjectLiteral: 2246 ms. to createEmptyArrayLiteral: 1175 ms. createShallowArrayLiteral: 1187 ms. createShallowObjectLiteral: 1195 ms. with this CL, so up to 2x faster now. Drive-by-fix: Also remove the unused CreateEmptyObjectLiteral builtin and cleanup the names of the other builtins to be consistent with the names of the TurboFan operators and Ignition bytecodes. Bug: v8:6856 Change-Id: I453828d019b27c9aa1344edac0dd84e91a457097 Reviewed-on: https://chromium-review.googlesource.com/680656 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#48140}
-
- 01 Sep, 2017 1 commit
-
-
Michael Starzinger authored
This adds support for lowering {JSCreateArguments} within outermost frames of type {CreateArgumentsType::kMappedArguments}. It will hence enable escape analysis to work with such objects and allow for further optimization. This also adds a new {NewMappedArgumentsElements} simplfied operator. Note that escape analysis support for this new operator will be done as a follow-up. R=tebbi@chromium.org Change-Id: I0e2fac25c654f796433f57b116964053b6b68635 Reviewed-on: https://chromium-review.googlesource.com/641454 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#47761}
-
- 28 Aug, 2017 1 commit
-
-
Camillo Bruni authored
Bug: v8:6211 Change-Id: I0f15c59b7b786ab327e4ab548523095dd85ba83e Reviewed-on: https://chromium-review.googlesource.com/637835Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#47650}
-
- 22 Aug, 2017 1 commit
-
-
Camillo Bruni authored
Since we don't create an AllocationSite for the empty object literal, the TF lowering bailed out early and used the slow runtime call as a fallback. Bug: chromium:757596, v8:6211 Change-Id: I68307ff2d0870c35f07c3aad4cd10cf08e378686 Reviewed-on: https://chromium-review.googlesource.com/625619Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#47514}
-
- 21 Aug, 2017 1 commit
-
-
Camillo Bruni authored
The quite common empty object literal doesn't need an AllocationSite since it starts off with the general ElementsKind. By using a separate bytecode we can directly instantiate the empty object without jumping to the runtime first. Note: this experimentally disables pretenuring for empty object literals. Depending on the outcome of our benchmarks pretenuring will be enabled again or fully removed for empty object literals. Bug: v8:6211 Change-Id: I2fee81cbefc70865fc436dbd3bc5fc8de04db91c Reviewed-on: https://chromium-review.googlesource.com/577555 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47467}
-
- 25 Jul, 2017 1 commit
-
-
Camillo Bruni authored
Empty Array literals are amongst the most commonly used literal types on our top25 page list. Using a custom bytecode we can drop the boilerplate for empty Array literals alltogether. However, we still need a proper AllocationSite to track ElementsKind transitions. Bug: v8:6211, chromium:746935 Change-Id: I891eaa778e4e81e138e483a65f04ae00ae30bd28 Reviewed-on: https://chromium-review.googlesource.com/580932Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#46875}
-
- 20 Jul, 2017 2 commits
-
-
Adam Klein authored
This reverts commit 4851745f. Reason for revert: Top crasher on Canary, see https://crbug.com/746935 Original change's description: > [literals] Introduce CreateEmptyArrayLiteral Bytecode > > Empty Array literals are amongst the most commonly used literal types on our > top25 page list. Using a custom bytecode we can drop the boilerplate for empty > Array literals alltogether. However, we still need a proper AllocationSite to > track ElementsKind transitions. > > Bug: v8:6211 > Change-Id: Id5dbdac0ea8e24dd474e679c902c6e4a2957af1d > Reviewed-on: https://chromium-review.googlesource.com/567079 > Commit-Queue: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#46752} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,cbruni@chromium.org,ishell@chromium.org,rmcilroy@google.com Bug: v8:6211, chromium:746935 Change-Id: Ibf19a923688c071d03bad8661a10e08f8414db56 Reviewed-on: https://chromium-review.googlesource.com/580193 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46804}
-
jgruber authored
This inlines the allocation of regexp literals when a boilerplate exists. Bug: v8:6605,v8:6556 Change-Id: If0f1b9dedf8a7de1ec51c394fe39cf21d2413ac5 Reviewed-on: https://chromium-review.googlesource.com/575240 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#46780}
-
- 19 Jul, 2017 1 commit
-
-
Camillo Bruni authored
Empty Array literals are amongst the most commonly used literal types on our top25 page list. Using a custom bytecode we can drop the boilerplate for empty Array literals alltogether. However, we still need a proper AllocationSite to track ElementsKind transitions. Bug: v8:6211 Change-Id: Id5dbdac0ea8e24dd474e679c902c6e4a2957af1d Reviewed-on: https://chromium-review.googlesource.com/567079 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#46752}
-
- 13 Jul, 2017 1 commit
-
-
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}
-