- 18 Apr, 2019 1 commit
-
-
Georg Neis authored
We see crashes in the wild that we suspect are caused by these changes. This is a manual revert because of conflicts. Revert "[turbofan] Fix incorrect CheckNonEmptyString lowering." This reverts commit b3b70118. Revert "[turbofan] Fix incorrect lowering of CheckNonEmptyString." This reverts commit 57582090. Revert "[turbofan] Significantly improve ConsString creation performance." This reverts commit d6a60a0e. Bug: v8:9147 Change-Id: I262c21e5406a9c4c8ad0e0f995582c5802f0fa1e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571613Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#60919}
-
- 01 Apr, 2019 1 commit
-
-
Georg Neis authored
It was missing a control output. Bug: chromium:946889 Change-Id: I85f203fc6e27a60f0b86e0e2999dd798a5416dfc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1547655 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60549}
-
- 19 Mar, 2019 1 commit
-
-
Benedikt Meurer authored
This change significantly improves the performance of string concatenation in optimized code for the case where the resulting string is represented as a ConsString. On the relevant test cases we go from serializeNaive: 10762 ms. serializeClever: 7813 ms. serializeConcat: 10271 ms. to serializeNaive: 10278 ms. serializeClever: 5533 ms. serializeConcat: 10310 ms. which represents a 30% improvement on the "clever" benchmark, which tests specifically the ConsString creation performance. This was accomplished via a couple of different steps, which are briefly outlined here: 1. The empty_string gets its own map, so that we can easily recognize and handle it appropriately in the TurboFan type system. This allows us to express (and assert) that the inputs to NewConsString are non-empty strings, making sure that TurboFan no longer creates "crippled ConsStrings" with empty left or right hand sides. 2. Further split the existing String types in TurboFan to be able to distinguish between OneByte and TwoByte strings on the type system level. This allows us to avoid having to dynamically lookup the resulting ConsString map in case of ConsString creation (i.e. when we know that both input strings are OneByte strings or at least one of the input strings is TwoByte). 3. We also introduced more finegrained feedback for the Add bytecode in the interpreter, having it collect feedback about ConsStrings, specifically ConsOneByteString and ConsTwoByteString. This feedback can be used by TurboFan to only inline the relevant code for what was seen so far. This allows us to remove the Octane/Splay specific magic in JSTypedLowering to detect ConsString creation, and instead purely rely on the feedback of what was seen so far (also making it possible to change the semantics of NewConsString to be a low-level operator, which is only introduced in SimplifiedLowering by looking at the input types of StringConcat). 4. On top of the before mentioned type and interpreter changes we added new operators CheckNonEmptyString, CheckNonEmptyOneByteString, and CheckNonEmptyTwoByteString, which perform the appropriate (dynamic) checks. There are several more improvements that are possible based on this, but since the change was already quite big, we decided not to put everything into the first change, but do some follow up tweaks to the type system, and builtin optimizations later. Tbr: mstarzinger@chromium.org Bug: v8:8834, v8:8931, v8:8939, v8:8951 Change-Id: Ia24e17c6048bf2b04df966d3cd441f0edda05c93 Cq-Include-Trybots: luci.chromium.try:linux-blink-rel Doc: https://bit.ly/fast-string-concatenation-in-javascript Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1499497 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60318}
-
- 12 Mar, 2019 1 commit
-
-
Hannes Payer authored
Bug: v8:8945 Change-Id: I14ca4b29f1b12ff95e718d431f65d88ab1238c53 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1511478Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60177}
-
- 01 Mar, 2019 1 commit
-
-
Matt Gardner authored
The original was reverted for breaking webkit layout tests: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/30270 It also caused the following clusterfuzz failures: chromium:935832 This was a correctness bug due to not properly handling the case of arrays with prototypes other than Array.prototype. Accesses that were TheHole were not being handled property, both in bounds holes in holey arrays and out of bounds on either holey or packed arrays. Handling was incorrect both in access-assembler and in Turbofan. chromium:935932 This bug was that there was no handling for Has checks on the global object. Turbofan was emitting code for a store (the 'else' condition on 'access_mode == AccessMode::kLoad'). It hit a DCHECK in debug builds but in release could show up in different places. This is the bug that caused the webkit layout test failure that led to the revert. Both bugs are fixed by in CL, and tests are added for those cases. Bug: v8:8733, chromium:935932, chromium:935832 Change-Id: Iba0dfcfce6e15d2c0815a7670ece67bc13ba1925 Reviewed-on: https://chromium-review.googlesource.com/c/1493132Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Matt Gardner <magardn@microsoft.com> Cr-Commit-Position: refs/heads/master@{#59958}
-
- 26 Feb, 2019 1 commit
-
-
Sigurd Schneider authored
This reverts commit 32fc0acf. Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/30270 layout test breakage: https://test-results.appspot.com/data/layout_results/V8-Blink_Linux_64/30270/webkit_layout_tests%20%28with%20patch%29/layout-test-results/results.html There is a dead node arriving in representation selection, which might indicate that the problem is not in this CL, but that this CL stirs up the node soup in such a way that dead code elimination gets confused. Original change's description: > Optimize `in` operator > > This change implements optimizations for the `in` operator for packed array > elements and object properties. It adds a new feedback slot kind and an IC > path similar to KeyedLoadIC for handling the lookups. TurboFan uses the > feedback to optimize based on the maps and keys. > > For more details see: > https://docs.google.com/document/d/1tIfzywY8AeNVcy_sen-5Xev21MeZwjcU8QhSdzHvXig > > This can provide 10x performance improvements of on loops of the form: > > for (let i = 0; i < ary.length; ++i) { > if (i in ary) { > ... > } > } > > > Bug: v8:8733 > Change-Id: I766bf865a547a059e5bce5399bb6112e5d9a85c8 > Reviewed-on: https://chromium-review.googlesource.com/c/1432598 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Matt Gardner <magardn@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#59843} TBR=ulan@chromium.org,rmcilroy@chromium.org,jkummerow@chromium.org,jarin@chromium.org,ishell@chromium.org,bmeurer@chromium.org,verwaest@chromium.org,magardn@microsoft.com Change-Id: Ib2db974e5bed4c4a2b6b450f796bdc4b0b8fd562 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8733 Reviewed-on: https://chromium-review.googlesource.com/c/1488761Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59857}
-
- 25 Feb, 2019 1 commit
-
-
Matt Gardner authored
This change implements optimizations for the `in` operator for packed array elements and object properties. It adds a new feedback slot kind and an IC path similar to KeyedLoadIC for handling the lookups. TurboFan uses the feedback to optimize based on the maps and keys. For more details see: https://docs.google.com/document/d/1tIfzywY8AeNVcy_sen-5Xev21MeZwjcU8QhSdzHvXig This can provide 10x performance improvements of on loops of the form: for (let i = 0; i < ary.length; ++i) { if (i in ary) { ... } } Bug: v8:8733 Change-Id: I766bf865a547a059e5bce5399bb6112e5d9a85c8 Reviewed-on: https://chromium-review.googlesource.com/c/1432598Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Matt Gardner <magardn@microsoft.com> Cr-Commit-Position: refs/heads/master@{#59843}
-
- 13 Feb, 2019 1 commit
-
-
Nico Weber authored
For macros expanding to function definitions, I removed the spurious ; after macro invocations. For macros expandign to function declarations, I made the ; required and consistently inserted it. No behavior change. Bug: chromium:926235 Change-Id: Ib8085d85d913d74307e3481f7fee4b7dc78c7549 Reviewed-on: https://chromium-review.googlesource.com/c/1467545Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Nico Weber <thakis@chromium.org> Cr-Commit-Position: refs/heads/master@{#59558}
-
- 02 Jan, 2019 1 commit
-
-
Clemens Hammacher authored
Introduce a LeakyObject template and use that to implement static lazily initialized objects that never get destructed. This was done in a hand-crafted and complex way before via LazyInstance and LazyStaticInstance. R=tebbi@chromium.org Bug: v8:8600, v8:8562 Change-Id: Id160996753b2cb1baf0f4b2cec9e1727f1d01512 Reviewed-on: https://chromium-review.googlesource.com/c/1388539 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#58494}
-
- 24 Oct, 2018 2 commits
-
-
Benedikt Meurer authored
This changes the ReceiverOrOddball feedback on JSStrictEqual to ReceiverOrNullOrUndefined feedback, which can also safely be consumed by JSEqual (we cannot generally accept any oddball here since booleans trigger implicit conversions, unfortunately). Thus we replace the previously introduced CheckReceiverOrOddball with CheckReceiverOrNullOrUndefined, and drop CheckOddball, since we will no longer collect Oddball feedback separately. TurboFan will then turn a JSEqual[ReceiverOrNullOrUndefined] into a sequence like this: ``` left = CheckReceiverOrNullOrUndefined(left); right = CheckReceiverOrNullOrUndefined(right); result = if ObjectIsUndetectable(left) then ObjectIsUndetectable(right) else ReferenceEqual(left, right); ``` This significantly improves the peak performance of abstract equality with Receiver, Null or Undefined inputs. On the test case outlined in http://crbug.com/v8/8356 we go from naive: 2946 ms. tenary: 2134 ms. to naive: 2230 ms. tenary: 2250 ms. which corresponds to a 25% improvement on the abstract equality case. For regular code this will probably yield more performance, since we get rid of the JSEqual operator, which might have arbitrary side effects and thus blocks all kinds of TurboFan optimizations. The JSStrictEqual case is slightly slower now, since it has to rule out booleans as well (even though that's not strictly necessary, but consistency is key here). This way developers can safely use `a == b` instead of doing a dance like `a == null ? b == null : a === b` (which is what dart2js does right now) when both `a` and `b` are known to be Receiver, Null or Undefined. The abstract equality is not only faster to parse than the tenary, but also generates a shorter bytecode sequence. In the test case referenced in http://crbug.com/v8/8356 the bytecode for `naive` is ``` StackCheck Ldar a1 TestEqual a0, [0] JumpIfFalse [5] LdaSmi [1] Return LdaSmi [2] Return ``` which is 14 bytes, whereas the `tenary` function generates ``` StackCheck Ldar a0 TestUndetectable JumpIfFalse [7] Ldar a1 TestUndetectable Jump [7] Ldar a1 TestEqualStrict a0, [0] JumpIfToBooleanFalse [5] LdaSmi [1] Return LdaSmi [2] Return ``` which is 24 bytes. So the `naive` version is 40% smaller and requires fewer bytecode dispatches. Bug: chromium:898455, v8:8356 Change-Id: If3961b2518b4438700706b3bd6071d546305e233 Reviewed-on: https://chromium-review.googlesource.com/c/1297315Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56948}
-
Benedikt Meurer authored
This CL introduces proper Oddball and ReceiverOrOddball states for the CompareOperationFeedback, and updates the StrictEqual IC to collect this feedback as well. Previously it would not collect Oddball feedback, not even in the sense of NumberOrOddball, since that's not usable for the SpeculativeNumberEqual. The new feedback is handled via newly introduced CheckReceiverOrOddball and CheckOddball operators in TurboFan, introduced by JSTypedLowering. Just like with the Receiver feedback, it's enough to check one side and do a ReferenceEqual afterwards, since strict equal can only yield true if both sides refer to the same instance. This improves the benchmark mentioned in http://crbug.com/v8/8356 from naive: 2950 ms. tenary: 2456 ms. to around naive: 2996 ms. tenary: 2192 ms. which corresponds to a roughly 10% improvement in the case for the tenary pattern, which is currently used by dart2js. In real world scenarios this will probably help even more, since TurboFan is able to optimize across the strict equality, i.e. there's no longer a stub call forcibly spilling all registers that are live across the call. This new feedback will be used as a basis for the JSEqual support for ReceiverOrOddball, which will allow dart2js switching to the shorter a==b form, at the same peak performance. Bug: v8:8356 Change-Id: Iafbf5d64fcc9312f9e575b54c32c631ce9b572b2 Reviewed-on: https://chromium-review.googlesource.com/c/1297309Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56925}
-
- 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}
-
- 10 Oct, 2018 1 commit
-
-
Benedikt Meurer authored
This change introduces new intrinsics used to desugar async functions in the Parser and the BytecodeGenerator, namely we introduce a new %_AsyncFunctionEnter intrinsic that constructs the generator object for the async function (and in the future will also create the outer promise for the async function). This generator object is internal and never escapes to user code, plus since async functions don't have a "prototype" property, we can just a single map here instead of tracking the prototype/initial_map on every async function. This saves one word per async function plus one initial_map per async function that was invoked at least once. We also introduce two new intrinsics %_AsyncFunctionReject, which rejects the outer promise with the caught exception, and another %_AsyncFunctionResolve, which resolves the outer promise with the right hand side of the `return` statement. These functions also perform the DevTools part of the job (aka popping from the promise stack and sending the debug event). This allows us to get rid of the implicit try-finally from async functions completely; because the finally block only called to the %AsyncFunctionPromiseRelease builtin, which was used to inform DevTools. In essence we now turn an async function like ```js async function f(x) { return await bar(x); } ``` into something like this (in Parser and BytecodeGenerator respectively): ``` function f(x) { .generator_object = %_AsyncFunctionEnter(.closure, this); .promise = %AsyncFunctionCreatePromise(); try { .tmp = await bar(x); return %_AsyncFunctionResolve(.promise, .tmp); } catch (e) { return %_AsyncFunctionReject(.promise, e); } } ``` Overall the bytecode for async functions gets significantly shorter already (and will get even shorter once we put the outer promise into the async function generator object). For example the bytecode for a simple async function ```js async function f(x) { return await x; } ``` goes from 175 bytes to 110 bytes (a ~38% reduction in size), which is in particular due to the simplification around the try-finally removal. Overall this seems to improve the doxbee-async-es2017-native test by around 2-3%. On the test case mentioned in v8:8276 we go from 1124ms to 441ms, which corresponds to a 60% reduction in total execution time! Tbr: marja@chromium.org Bug: v8:7253, v8:7522, v8:8276 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4 Reviewed-on: https://chromium-review.googlesource.com/c/1269041 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#56502}
-
- 27 Sep, 2018 1 commit
-
-
Vasili Skurydzin authored
Bug: v8:8193 GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61976 Change-Id: I0d4efca4da03ef82651325e15ddf2160022bc8de Reviewed-on: https://chromium-review.googlesource.com/1228633Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#56275}
-
- 26 Sep, 2018 1 commit
-
-
Jaroslav Sevcik authored
Bug: chromium:888923 Change-Id: Ifb22cd9b34f53de3cf6e47cd92f3c0abeb10ac79 Reviewed-on: https://chromium-review.googlesource.com/1245763Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#56236}
-
- 21 Sep, 2018 1 commit
-
-
Benedikt Meurer authored
The JSToInteger operator is not used anywhere in TurboFan nowadays, so no point in keeping the dead code in the tree. Bug: v8:8015 Change-Id: If03ba63c4b932ba0aac60b9bbc89fee3909a93c6 Reviewed-on: https://chromium-review.googlesource.com/1238238Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56126}
-
- 11 Sep, 2018 1 commit
-
-
Benedikt Meurer authored
We had an optimization in Crankshaft where we would call into the megamorphic handler stub directly if an inline cache was already found to be megamorphic when it hit the optimizing compiler. This way we could avoid the dispatch overhead when we know that there's no point in checking for the other states anyways. However we somehow missed to port this optimization to TurboFan. Now this change introduces support to call into LoadIC_Megamorphic and KeyedLoadIC_Megamorphic directly (plus the trampoline versions), which saves quite a lot of overhead for the cases where the map/name pair is found in the megamorphic stub cache, and it's quite a simple change. We can later extend this to also handle the StoreIC and KeyedStoreIC cases if that turns out to be beneficial. This improves the score on the Octane/TypeScript test by around ~2% and the TypeScript test in the web-tooling-benchmark by around ~4%. On the ARES-6 Air test the steady state mean improves by 2-4%, and on the ARES-6 ML test the steady state mean seems to also improve by 1-2%, but that might be within noise. On a micro-benchmark that just runs `o.x` in a hot loop on a set of 9 different objects, which all have `x` as the first property and are all in fast mode, we improve by around ~30%, and are now almost on par with JavaScriptCore. Bug: v8:6344, v8:6936 Change-Id: Iaa4c6e34c37e78da217ee75f32f6acc95a834250 Reviewed-on: https://chromium-review.googlesource.com/1215623Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#55803}
-
- 05 Sep, 2018 1 commit
-
-
Hai Dang authored
This is a reland of 1c48d52b. It turned out that IterableToList doesn't always behave according to the ES operation with the same name. Specifically, it allows holey arrays to take its fast path, which produces an output array with holes where actually "undefined" elements should appear. This CL changes the version of IterableToList that is used for spreads (IterableToListWithSymbolLookup) such that holey arrays take the slow path. It also includes tests for such situations. Original change's description: > [interpreter] Add bytecode for leading array spreads. > > This CL improves the performance of creating [...a, b] or [...a]. > If the array literal has a leading spread, this CL emits the bytecode > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable > is implemented by [IterableToListDefault] builtin to create the initial > array for the leading spread. IterableToListDefault has a fast path to > clone efficiently if the spread is an actual array. > > The bytecode generated is now shorter. Bytecode generation is refactored > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit > from this optimization also. > For now, turbofan also lowers the bytecode to the builtin. > > The idiomatic use of [...a] to clone the array a now performs better > than a simple for-loop, but still does not match the performance of slice. > > Bug: v8:7980 > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 > Reviewed-on: https://chromium-review.googlesource.com/1181024 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#55520} Bug: v8:7980 Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1201882 Commit-Queue: Hai Dang <dhai@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#55639}
-
- 31 Aug, 2018 1 commit
-
-
Georg Neis authored
This reverts commit 1c48d52b. Reason for revert: Clusterfuzz found something. Original change's description: > [interpreter] Add bytecode for leading array spreads. > > This CL improves the performance of creating [...a, b] or [...a]. > If the array literal has a leading spread, this CL emits the bytecode > [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable > is implemented by [IterableToListDefault] builtin to create the initial > array for the leading spread. IterableToListDefault has a fast path to > clone efficiently if the spread is an actual array. > > The bytecode generated is now shorter. Bytecode generation is refactored > into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit > from this optimization also. > For now, turbofan also lowers the bytecode to the builtin. > > The idiomatic use of [...a] to clone the array a now performs better > than a simple for-loop, but still does not match the performance of slice. > > Bug: v8:7980 > > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng > Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 > Reviewed-on: https://chromium-review.googlesource.com/1181024 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Commit-Queue: Hai Dang <dhai@google.com> > Cr-Commit-Position: refs/heads/master@{#55520} TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7980 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Reviewed-on: https://chromium-review.googlesource.com/1199303Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#55544}
-
- 30 Aug, 2018 1 commit
-
-
Hai Dang authored
This CL improves the performance of creating [...a, b] or [...a]. If the array literal has a leading spread, this CL emits the bytecode [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable is implemented by [IterableToListDefault] builtin to create the initial array for the leading spread. IterableToListDefault has a fast path to clone efficiently if the spread is an actual array. The bytecode generated is now shorter. Bytecode generation is refactored into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit from this optimization also. For now, turbofan also lowers the bytecode to the builtin. The idiomatic use of [...a] to clone the array a now performs better than a simple for-loop, but still does not match the performance of slice. Bug: v8:7980 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35 Reviewed-on: https://chromium-review.googlesource.com/1181024Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Commit-Queue: Hai Dang <dhai@google.com> Cr-Commit-Position: refs/heads/master@{#55520}
-
- 02 Aug, 2018 1 commit
-
-
Georg Neis authored
R=sigurds@chromium.org Change-Id: I9d07847ef92ff7a512c1624b492b37b6991e3c56 Reviewed-on: https://chromium-review.googlesource.com/1160304Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#54867}
-
- 25 Jul, 2018 1 commit
-
-
Caitlin Potter authored
Includes fixes for several ClusterFuzz regressions: 1) fix an invalid Handle-cast in ic.cc (chromium:866282) 2) fix for improper accounting of used/unused inobject fields, found by clusterfuzz (chromium:866357). 3) fix number of control outputs for the JSCloneObject operator to be used by IfSuccess and IfException nodes (chromium:866727). 4) fix property constness in out-of-object properties of fast-cloned object to be compatible with DCHECKs in StoreIC (chromium:866861). Also includes the fixups missing from the initial commit, and regression tests BUG=v8:7611, chromium:866282, chromium:866357, chromium:866727, chromium:866861 R=jkummerow@chromium.org, mvstanton@chromium.org TBR=rmcilroy@chromium.org Change-Id: I77220308482f16db2893c0dcebec36530d0f5540 Reviewed-on: https://chromium-review.googlesource.com/1146297 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#54706}
-
- 23 Jul, 2018 1 commit
-
-
Sigurd Schneider authored
This is a reland of 9eca23e9 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}
-
- 20 Jul, 2018 1 commit
-
-
Caitlin Potter authored
As discussed in https://docs.google.com/document/d/1sBdGe8RHgeYP850cKSSgGABTyfMdvaEWLy-vertuTCo/edit?ts=5b3ba5cc#, this CL introduces a new bytecode (CloneObject), and a new IC type. In this prototype implementation, the type feedback looks like the following: Uninitialized case: { uninitialized_sentinel, uninitialized_sentinel } Monomorphic case: { weak 'source' map, strong 'result' map } Polymorphic case: { WeakFixedArray with { weak 'source' map, strong 'result' map }, cleared value } Megamorphic case: { megamorphic_sentinel, cleared_Value } In the fast case, Object cloning is done by allocating an object with the saved result map, and a shallow clone of the fast properties from the source object, as well as cloned fast elements from the source object. If at any point the fast case can't be taken, the IC transitions to the slow case and remains there. This prototype CL does not include any TurboFan optimization, and the CloneObject operation is merely reduced to a stub call. It may still be possible to get some further improvements by somehow incorporating compile-time boilerplate elements into the cloned object, or simplifying how the boilerplate elements are inserted into the object. In terms of performance, we improve the ObjectSpread score in JSTests/ObjectLiteralSpread/ by about 8x, with substantial improvements over the Babel and ObjectAssign scores. R=gsathya@chromium.org, mvstanton@chromium.org, rmcilroy@chromium.org, neis@chromium.org, bmeurer@chromium.org BUG=v8:7611 Change-Id: I79e1796eb77016fb4feba0e1d3bb9abb348c183e Reviewed-on: https://chromium-review.googlesource.com/1127472 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#54595}
-
- 19 Jul, 2018 1 commit
-
-
Sigurd Schneider authored
This reverts commit 9eca23e9. Reason for revert: Clusterfuzz correctness issue 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} TBR=jarin@chromium.org,neis@chromium.org,sigurds@chromium.org,bmeurer@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7904 Change-Id: Ie5fa6c1262b8acc33edb672a0124f4458fcded86 Reviewed-on: https://chromium-review.googlesource.com/1142777Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#54544}
-
- 16 Jul, 2018 1 commit
-
-
Sigurd Schneider authored
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}
-
- 05 Jul, 2018 1 commit
-
-
Creddy authored
* Rename BoilerplateDescription to ObjectBoilerplateDescription * Add literal_type flag to ObjectBoilerplateDescription, which is stored as zeroth element of Fixed array * Create ArrayBoilerplateDescription with elements_kind and constant_elements field * Replace CompileTimeValue and ConstantElementPair with ArrayBoilerplateDescription * Kill ConstantElementPair and CompileTimeValue Change-Id: Icb42dcfd575a27e2b64ffd5e2e61f9d703d5e986 Bug: v8:7787, chromium:818642 Reviewed-on: https://chromium-review.googlesource.com/1122411 Commit-Queue: Chandan Reddy <chandanreddy@google.com> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#54272}
-
- 11 Jun, 2018 1 commit
-
-
Sigurd Schneider authored
This CL adds a TFS stub for RegExp#test and moves several checks to the JSCallReducer. In particular, the JSCallReducer checks that - property {exec} on the regexp is still the original exec - property {lastIndex} on the regexp is a non-negative smi The stub does not repeat these checks in release mode. This effectively means that if the regexp is known, we can perform these checks at compile time, and get away with a map dependency. Bug: v8:7779, v8:7200 Change-Id: I0c6d711d4f1d2f6f325a1c02855b0e1b62e014c8 Reviewed-on: https://chromium-review.googlesource.com/1074654 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#53630}
-
- 24 May, 2018 1 commit
-
-
Jaroslav Sevcik authored
Currently, we context allocate all parameters for generators. With this CL, we keep arguments on stack (unless they escape to inner closure) and copy them between the stack and the generator's register file on suspend/resume. This will save context allocation in most cases. Note: There is an asymmetry between suspend and resume. - Suspend copies arguments and registers to the generator. - Resume copies only the registers from the generator, the arguments are copied by the ResumeGenerator trampoline. Bug: v8:5164 Change-Id: I6333898c60abf461b1ab1b5c6d3dc7188fa95649 Reviewed-on: https://chromium-review.googlesource.com/1063712 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53327}
-
- 04 May, 2018 1 commit
-
-
Toon Verwaest authored
Instead rely on the scope info containing the name as well. Change-Id: Ie1f96ea023a793b11209510566f6831b1dfd40ab Reviewed-on: https://chromium-review.googlesource.com/1042567 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52983}
-
- 03 May, 2018 1 commit
-
-
Toon Verwaest authored
There are likely cleanups that can be done after this CL: - context-related functions in the interpreter and compiler take ScopeInfo as well as ScopeType and slot-count as input. The latter 2 should be directly derived from the former. We should be able to drop FunctionContextParameters. - ContextExtension is probably not needed anymore, since we now always have the correct scope_info directly in the SCOPE_INFO_INDEX slot. Bug: v8:7066 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ie1f6134c686a9f2183e54730d9cdd598a9e5ab67 Reviewed-on: https://chromium-review.googlesource.com/785151 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52952}
-
- 26 Apr, 2018 1 commit
-
-
Sigurd Schneider authored
This CL also removes the JSBuiltinReducer, which is no longer needed. Bug: v8:7340, v8:7250 Change-Id: I28896f6ce0d352047ea1cb7ea6de490818840faf Reviewed-on: https://chromium-review.googlesource.com/1027853 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#52799}
-
- 24 Apr, 2018 1 commit
-
-
Sigurd Schneider authored
This CL introduces a JSOperator for Array.isArray and moves the corresponding lowering to JSCallReducer and JSTypedLowering. Bug: v8:7340, v8:7250 Change-Id: Iaa7ced2ad34bec8cccc9da1041007261168cf4b3 Reviewed-on: https://chromium-review.googlesource.com/1025092 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#52757}
-
- 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}
-
- 15 Mar, 2018 1 commit
-
-
Benedikt Meurer authored
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}
-
- 05 Mar, 2018 3 commits
-
-
Sigurd Schneider authored
Bug: v8:7517, v8:7310 Change-Id: Ic9a1ac8f4a928e1d5d8f807a0875c7314a7777fb Reviewed-on: https://chromium-review.googlesource.com/946095 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51735}
-
Sigurd Schneider authored
Bug: v8:7517, v8:7310 Change-Id: I438bc933d51062bfbb9a419be9c5b67032707fdb Reviewed-on: https://chromium-review.googlesource.com/946090 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51726}
-
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}
-
- 02 Mar, 2018 1 commit
-
-
Georg Neis authored
... and use it in the implementation of array literal spreads, replacing calls to %AppendElement. Array spreads in destructuring will be taken care of in a separate CL. Bug: v8:5940, v8:7446 Change-Id: Idec52398902a7fd3c1244852cf73246f142404f0 Reviewed-on: https://chromium-review.googlesource.com/915364 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#51709}
-