- 26 Jun, 2019 1 commit
-
-
Nico Hartmann authored
This is a reland of 5ff38bae Original change's description: > [TurboFan] Fast path for JSAdd with BigInt feedback > > This CL introduces the necessary infrastructure to generate speculative > BigInt operations in case of BigInt feedback. In particular, the JSAdd > operator is lowered to a speculative call to the BigIntAdd builtin, > with a deopt bailout in case of exceptions or violated assumptions. > > Bug: v8:9213 > Change-Id: I05796336eef9a4389fc31d59cad2d69f75512647 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657916 > Commit-Queue: Nico Hartmann <nicohartmann@google.com> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62362} Bug: v8:9213 Change-Id: Ic0caf7aab2103b8f5e22a504427e8604cc894d75 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1677209Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@google.com> Cr-Commit-Position: refs/heads/master@{#62381}
-
- 25 Jun, 2019 2 commits
-
-
Francis McCabe authored
This reverts commit 5ff38bae. Reason for revert: flaky test that is not normally flaky failed. See: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20nosnap%20-%20debug/24531 Original change's description: > [TurboFan] Fast path for JSAdd with BigInt feedback > > This CL introduces the necessary infrastructure to generate speculative > BigInt operations in case of BigInt feedback. In particular, the JSAdd > operator is lowered to a speculative call to the BigIntAdd builtin, > with a deopt bailout in case of exceptions or violated assumptions. > > Bug: v8:9213 > Change-Id: I05796336eef9a4389fc31d59cad2d69f75512647 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657916 > Commit-Queue: Nico Hartmann <nicohartmann@google.com> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62362} TBR=jarin@chromium.org,neis@chromium.org,sigurds@chromium.org,nicohartmann@google.com Change-Id: I5ae63a0183283894b6d1130792ab37a95b014550 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9213 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1676607Reviewed-by: Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#62364}
-
Nico Hartmann authored
This CL introduces the necessary infrastructure to generate speculative BigInt operations in case of BigInt feedback. In particular, the JSAdd operator is lowered to a speculative call to the BigIntAdd builtin, with a deopt bailout in case of exceptions or violated assumptions. Bug: v8:9213 Change-Id: I05796336eef9a4389fc31d59cad2d69f75512647 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657916 Commit-Queue: Nico Hartmann <nicohartmann@google.com> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62362}
-
- 24 May, 2019 1 commit
-
-
Yang Guo authored
TBR=mvstanton@chromium.org,neis@chromium.org,ahaas@chromium.org Bug: v8:9247 Change-Id: I5433c863a54f3412d73df0d38aba3fdbcfac7ebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627973 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61830}
-
- 20 May, 2019 3 commits
-
-
Yang Guo authored
This reverts commit a7695520. Reason for revert: Was not the culprit. Original change's description: > Revert "Move deoptimizer files" > > This reverts commit 61523c45. > > Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20debug/20396 > > Original change's description: > > Move deoptimizer files > > > > Bug: v8:9247 > > Change-Id: I6287907edb8a36225bfa9fe864305ea59c20dd8b > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617667 > > Commit-Queue: Yang Guo <yangguo@chromium.org> > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#61648} > > TBR=yangguo@chromium.org,mstarzinger@chromium.org,jarin@chromium.org,bmeurer@chromium.org > > Change-Id: Icf258f7bc409ef0c360cfa82029bfc45a41dc75f > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: v8:9247 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619749 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61650} TBR=yangguo@chromium.org,mstarzinger@chromium.org,jarin@chromium.org,bmeurer@chromium.org Change-Id: Ic2aa07ccd08b6070222ec7a65b92b7afb9db484c No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9247 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619753Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61652}
-
Yang Guo authored
This reverts commit 61523c45. Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20debug/20396 Original change's description: > Move deoptimizer files > > Bug: v8:9247 > Change-Id: I6287907edb8a36225bfa9fe864305ea59c20dd8b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617667 > Commit-Queue: Yang Guo <yangguo@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61648} TBR=yangguo@chromium.org,mstarzinger@chromium.org,jarin@chromium.org,bmeurer@chromium.org Change-Id: Icf258f7bc409ef0c360cfa82029bfc45a41dc75f No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9247 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619749Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61650}
-
Yang Guo authored
Bug: v8:9247 Change-Id: I6287907edb8a36225bfa9fe864305ea59c20dd8b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617667 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#61648}
-
- 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}
-
- 04 Apr, 2019 1 commit
-
-
Sigurd Schneider authored
Bug: v8:9020 Change-Id: Ie624a02598f5c3a43e40e03d0337c17ca5cc3769 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1541052 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#60628}
-
- 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}
-
- 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}
-