- 11 Dec, 2018 1 commit
-
-
Ben L. Titzer authored
This is purely a renaming change. The ES spec uses the term 'detach' for the process of removing the backing store of a typed array, while V8 uses the historical term 'neuter'. Update our internal implementation, including method names and flag names, to match the spec. Note that some error messages still use the term 'neuter' since error messages are asserted by some embedder tests, like layout tests. R=bmeurer@chromium.org, yangguo@chromium.org, mstarzinger@chromium.org, mlippautz@chromium.org BUG=chromium:913887 Change-Id: I62f1c3ac9ae67ba01d612a5221afa3d92deae272 Reviewed-on: https://chromium-review.googlesource.com/c/1370036 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#58149}
-
- 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}
-
- 21 Feb, 2018 1 commit
-
-
Sigurd Schneider authored
Bug: v8:7310 Change-Id: I54f16a65d478d65cb7df611626397376df22a975 Reviewed-on: https://chromium-review.googlesource.com/928702Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#51442}
-
- 22 Jan, 2018 1 commit
-
-
Sigurd Schneider authored
Array.prototype.reduce[Right] used a lazy deoptimization frame state for an eager deopt point. Bug: v8:7336, chromium:804096 Change-Id: I720f9e049bd6b396e025fa59192fdbc6b4f18647 Reviewed-on: https://chromium-review.googlesource.com/878120 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#50752}
-
- 09 Jan, 2018 1 commit
-
-
Georg Neis authored
- Remove unused deoptimization reasons. - Replace most uses of kNoReason with an actual reason (some are new). - Rename kNoReason to kUnknown. Bug: Change-Id: Ia8df54fca0f0f4885ef0c3523ce8f67b557a635d Reviewed-on: https://chromium-review.googlesource.com/839421Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#50440}
-
- 21 Nov, 2017 1 commit
-
-
Georg Neis authored
This introduces a JSNegate operator and lowers it either to a speculative multiplication with -1 (when we have Number feedback) or to a stub call. The stub is also new. R=jarin@chromium.org Bug: v8:6791 Change-Id: I8e20333fe49cc6088d2d10777be982e42eed2412 Reviewed-on: https://chromium-review.googlesource.com/774718 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#49538}
-
- 20 Oct, 2017 1 commit
-
-
Benedikt Meurer authored
In the special case of KeyedLoadIC, where the key that is passed in is a Name that is always the same we only checked for identity in both the stub and the TurboFan case, which works fine for symbols and internalized strings, but doesn't really work with non-internalized strings, where the identity check will fail, the runtime will internalize the string, and the IC will then see the original internalized string again and not progress in the feedback lattice. This leads to tricky deoptimization loops in TurboFan and constantly missing ICs. This adds fixes the stub to always try to internalize strings first when the identity check fails and then doing the check again. If the name is not found in the string table we miss, since in that case the string cannot match the previously recorded feedback name (which is always a unique name). In TurboFan we represent this checks with new CheckEqualsSymbol and CheckEqualsInternalizedString operators, which validate the previously recorded feedback, and the CheckEqualsInternalizedString operator does the attempt to internalize the input. Bug: v8:6936, v8:6948, v8:6969 Change-Id: I3f3b4a587c67f00f7c4b60d239eb98a9626fe04a Reviewed-on: https://chromium-review.googlesource.com/730224Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48784}
-
- 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}
-
- 01 Sep, 2017 1 commit
-
-
Benedikt Meurer authored
In the BytecodeGraphBuilder we insert a SOFT deopt whenever we see an IC whose state is UNINITIALIZED, i.e. a LOAD_IC or a STORE_IC. This greatly reduces the size of the generated graphs (and also helps to improve generated code quality). However for COMPARE_IC and BINARY_OP_IC we used to stick in the generic JavaScript node instead, which does generate code and might block optimizations because its sitting in the effect chain. This is changed now to always SOFT deopt for UNINITIALIZED instead, consistently with the other ICs. Bug: v8:6760 Change-Id: I2ac7469fa86512a2fd909fdde2c6425977694811 Reviewed-on: https://chromium-review.googlesource.com/645858 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47771}
-
- 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}
-
- 30 Jun, 2017 1 commit
-
-
bmeurer authored
Similar to JSCall, we can also replace uninitialized JSConstruct nodes with SOFT deopts to ensure that we don't generate unnecessary dead code. This for example shows up in the hot parts of the Node event emitter currently where the generic code for handling events with 4 or more parameters might not have been run, but we still generate most of the code because the new Array call in the beginning is not turned into a SOFT deopt immediately. Drive-by-fix: Also refactor the BytecodeGraphBuilder's handling of Construct bytecodes a bit to reduce the amount of code duplication. BUG=v8:4551, v8:5267 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2958253002 Cr-Commit-Position: refs/heads/master@{#46339}
-
- 22 May, 2017 1 commit
-
-
bmeurer authored
Introduce a new Symbol comparison feedback bit in the lattice and collect that feedback on Equal/StrictEqual in Ignition. Utilize this feedback in TurboFan by adding a dedicated CheckSymbol operator to check for symbol inputs. This way we can optimize Symbol comparison where TurboFan doesn't know anything statically about either side, or abstract equality comparisons where TurboFan doesn't statically know anything about one side. BUG=v8:6278,v8:6344,v8:6423 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2893263002 Cr-Commit-Position: refs/heads/master@{#45455}
-
- 27 Oct, 2016 1 commit
-
-
bmeurer authored
For inputs to truncating binary operations like <<, | or >>>, support all Oddballs not just undefined, true and false. This unifies treatment of these truncations in Crankshaft and TurboFan, and is very easy nowadays, since the memory layout of Oddball and HeapNumber is compatible. R=yangguo@chromium.org BUG=v8:5400 Review-Url: https://codereview.chromium.org/2452193003 Cr-Commit-Position: refs/heads/master@{#40608}
-
- 17 Oct, 2016 1 commit
-
-
jkummerow authored
RIP, handwritten KeyedLoadICStub, handwritten KeyedLoadIC_Megamorphic, and hydrogenized KeyedLoadGeneric! Review-Url: https://codereview.chromium.org/2424433002 Cr-Commit-Position: refs/heads/master@{#40354}
-
- 22 Sep, 2016 1 commit
-
-
bmeurer authored
If a JSCallFunction node doesn't have any callee information, either from feedback taken on input nodes, i.e. on property loads, or from the CallIC, we insert a soft deoptimization exit instead. R=jarin@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2361773002 Cr-Commit-Position: refs/heads/master@{#39619}
-
- 20 Sep, 2016 1 commit
-
-
klaasb authored
Refactors CodeStubAssembler::AllocateJSArray to share code. BUG=chromium:608675 Review-Url: https://codereview.chromium.org/2304573004 Cr-Commit-Position: refs/heads/master@{#39550}
-
- 28 Aug, 2016 2 commits
-
-
hablich authored
Reland of Fix compiler warnings on "make android_arm" (patchset #1 id:1 of https://codereview.chromium.org/2286163002/ ) Reason for revert: Roll was unstuck before the revert landed => reland Original issue's description: > Revert of Fix compiler warnings on "make android_arm" (patchset #1 id:1 of https://codereview.chromium.org/2264283007/ ) > > Reason for revert: > Speculative revert because of roll blocker https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/2241 > > Original issue's description: > > Fix compiler warnings on "make android_arm" > > > > Committed: https://crrev.com/3e809a6129d0097529c885579ac46e4acf4e99f6 > > Cr-Commit-Position: refs/heads/master@{#38937} > > TBR=bmeurer@chromium.org,jkummerow@chromium.org > # Not skipping CQ checks because original CL landed more than 1 days ago. > > Committed: https://crrev.com/d992c1f52f116930239ed90cc033442047e789b4 > Cr-Commit-Position: refs/heads/master@{#38961} TBR=bmeurer@chromium.org,jkummerow@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2285113002 Cr-Commit-Position: refs/heads/master@{#38962}
-
hablich authored
Revert of Fix compiler warnings on "make android_arm" (patchset #1 id:1 of https://codereview.chromium.org/2264283007/ ) Reason for revert: Speculative revert because of roll blocker https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/2241 Original issue's description: > Fix compiler warnings on "make android_arm" > > Committed: https://crrev.com/3e809a6129d0097529c885579ac46e4acf4e99f6 > Cr-Commit-Position: refs/heads/master@{#38937} TBR=bmeurer@chromium.org,jkummerow@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. Review-Url: https://codereview.chromium.org/2286163002 Cr-Commit-Position: refs/heads/master@{#38961}
-
- 26 Aug, 2016 1 commit
-
-
jkummerow authored
Review-Url: https://codereview.chromium.org/2264283007 Cr-Commit-Position: refs/heads/master@{#38937}
-
- 03 Aug, 2016 1 commit
-
-
mstarzinger authored
R=danno@chromium.org BUG=chromium:608675 Review-Url: https://codereview.chromium.org/2207553002 Cr-Commit-Position: refs/heads/master@{#38302}
-
- 18 Jul, 2016 1 commit
-
-
bmeurer authored
So far TurboFan wasn't adding the deoptimization reasons for eager/soft deoptimization exits that can be used by either the DevTools profiler or the --trace-deopt flag. This adds basic support for deopt reasons on Deoptimize, DeoptimizeIf and DeoptimizeUnless nodes and threads through the reasons to the code generation. Also moves the DeoptReason to it's own file (to resolve include cycles) and drops unused reasons. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2161543002 Cr-Commit-Position: refs/heads/master@{#37823}
-