- 11 Dec, 2017 1 commit
-
-
Georg Neis authored
Also put an UNREACHABLE into an impossible case in NumberOpFromSpeculativeNumberOp. R=jarin@chromium.org Bug: Change-Id: I681b7bc58de5038497667cb48fdcd79a73abe1c2 Reviewed-on: https://chromium-review.googlesource.com/819415Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#49998}
-
- 06 Dec, 2017 1 commit
-
-
Tobias Tebbi authored
We cannot remove a speculative operation when it's type relies on it to deopt. Fix this by only relying on the lowering to remove operations. Bug: chromium:786521 Change-Id: I2cf45e8d45b76cfeb06e6329f323cade74719124 Reviewed-on: https://chromium-review.googlesource.com/793043Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#49882}
-
- 05 Dec, 2017 3 commits
-
-
Jaroslav Sevcik authored
The proper fix would be to make TruncatingUseInfoFromRepresentation respect tagged signed use representation, but requires extra work to refine typing for all values that are stored into Smi fields. Bug: chromium:791245 Change-Id: I83965bcc18a836d2c758a6a8b1477a4aa2c6133d Reviewed-on: https://chromium-review.googlesource.com/808866Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#49870}
-
Michael Achenbach authored
This reverts commit cc07ac73. Reason for revert: Breaks benchmarks: http://shortn/_POjH6zA7tp Original change's description: > [turbofan] Make sure TruncatingUseInfoFromRepresentation respects Smi representation. > > Eventually, we want to fix this also for tagged pointers (tracking bug: https://crbug.com/v8/7162). > > Bug: chromium:791245 > Change-Id: I93d6deff36cedcc9a4665fab0abe6fffdae9b61b > Reviewed-on: https://chromium-review.googlesource.com/806457 > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49850} TBR=jarin@chromium.org,bmeurer@chromium.org Change-Id: I0ff571b161ec40ba1f32ee048f8255c42414d8d2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:791245 Reviewed-on: https://chromium-review.googlesource.com/807985Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#49853}
-
Jaroslav Sevcik authored
Eventually, we want to fix this also for tagged pointers (tracking bug: https://crbug.com/v8/7162). Bug: chromium:791245 Change-Id: I93d6deff36cedcc9a4665fab0abe6fffdae9b61b Reviewed-on: https://chromium-review.googlesource.com/806457Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#49850}
-
- 02 Dec, 2017 1 commit
-
-
Mathias Bynens authored
This patch normalizes the casing of hexadecimal digits in escape sequences of the form `\xNN` and integer literals of the form `0xNNNN`. Previously, the V8 code base used an inconsistent mixture of uppercase and lowercase. Google’s C++ style guide uses uppercase in its examples: https://google.github.io/styleguide/cppguide.html#Non-ASCII_Characters Moreover, uppercase letters more clearly stand out from the lowercase `x` (or `u`) characters at the start, as well as lowercase letters elsewhere in strings. BUG=v8:7109 TBR=marja@chromium.org,titzer@chromium.org,mtrofin@chromium.org,mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org,mlippautz@chromium.org NOPRESUBMIT=true Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I790e21c25d96ad5d95c8229724eb45d2aa9e22d6 Reviewed-on: https://chromium-review.googlesource.com/804294 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#49810}
-
- 30 Nov, 2017 2 commits
-
-
Benedikt Meurer authored
Strings are immutable in JavaScript land (contrast with the runtime, where we can truncate strings that haven't escaped to JavaScript yet), so the length of a String is immutable. Thus loading the length of a String is a pure operation and should be expressed as such (i.e. doesn't depend on control or effect). The StringLength operator does exactly this and is hooked up to the effect chain in the EffectControlLinearizer. This will eventually allow us to simplify the optimization of string concatention and other operations that are a bit cumbersome in TurboFan currently, and it will also allow us to optimize string operations across effectful operations, for example combining multiple invocations to String#slice with the same inputs. Bug: v8:5269, v8:6936, v8:7109, v8:7137 Change-Id: Iffcccbb0c7fc4cfe1281c10e7af24b40eba4c987 Reviewed-on: https://chromium-review.googlesource.com/799690Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#49731}
-
Benedikt Meurer authored
This is in preparation of adding a dedicated StringLength operator that loads the string length. This way operations on strings don't sit in the effect chain anymore until the EffectControlLinearizer, which wires them. The NewConsString semantics could still be better, i.e. it could try to figure out the proper map instead of going for the CONS_STRING_TYPE always. But this change is meant to be just about pushing the logic down to the EffectControlLinearizer, which we didn't have initially when the ConsString handling was done. This also allows us to remove the handling of CONS_STRING_TYPE from the Deoptimizer, since the escape analysis no longer sees cons strings. Bug: v8:5269, v8:6936, v8:7109, v8:7137 Change-Id: If6c4a6d7cf63a3a3f7a34a920c8e50a94dfa67fa Reviewed-on: https://chromium-review.googlesource.com/796413 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#49729}
-
- 28 Nov, 2017 1 commit
-
-
Georg Neis authored
... in the same style as the previous CLs for negation and bitwise-not. R=jarin@chromium.org Bug: v8:6791 Change-Id: I0aa96a72421e90c8c82a39dd4264fdcf00967504 Reviewed-on: https://chromium-review.googlesource.com/779141 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#49658}
-
- 21 Nov, 2017 3 commits
-
-
Georg Neis authored
This introduces a JSBitwiseNot operator and lowers it either to a speculative xor with -1 (when we have Number feedback) or to a stub call. The stub is also new. Bug: v8:6791 Change-Id: I362e52de8a741dc5db044c406543878e407eb2ed Reviewed-on: https://chromium-review.googlesource.com/778839 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#49539}
-
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}
-
Georg Neis authored
TBR: rmcilroy@chromium.org Bug: v8:6791 Change-Id: I4ac2bdce353d987a2fe45149d8556b6591569a01 Reviewed-on: https://chromium-review.googlesource.com/771191 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#49528}
-
- 16 Nov, 2017 2 commits
-
-
Tobias Tebbi authored
Reland of https://chromium-review.googlesource.com/c/v8/v8/+/727893 The crashes should be fixed by https://chromium-review.googlesource.com/c/v8/v8/+/763531 Original change's description: > Revert "Reland^5 "[turbofan] eagerly prune None types and deadness from the graph"" > > This reverts commit ac0661b3. > > Reason for revert: Clusterfuzz unhappy: chromium:783019 chromium:783035 > > Original change's description: > > Reland^5 "[turbofan] eagerly prune None types and deadness from the graph" > > > > This gives up on earlier attempts to interpret DeadValue as a signal of > > unreachable code. This does not work because free-floating dead value > > nodes, and even pure branch nodes that use them, can get scheduled so > > early that they get reachable. Instead, we now eagerly remove branches > > that use DeadValue in DeadCodeElimination and replace DeadValue inputs > > to value phi nodes with dummy values. > > > > Reland of https://chromium-review.googlesource.com/715716 > > > > Bug: chromium:741225 chromium:776256 > > Change-Id: I251efd507c967d4a8882ad8fd2fd96c4185781fe > > Reviewed-on: https://chromium-review.googlesource.com/727893 > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#49188} > > TBR=jarin@chromium.org,tebbi@chromium.org > > Bug: chromium:741225 chromium:776256 chromium:783019 chromium:783035 > Change-Id: I6a8fa3a08ce2824a858ae01817688e63ed1f442e > Reviewed-on: https://chromium-review.googlesource.com/758770 > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49262} TBR=jarin@chromium.org,tebbi@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:741225 chromium:776256 chromium:783019 chromium:783035 Change-Id: I6c02b4beb02997ec34015ed2f6791a93c70f5e36 Reviewed-on: https://chromium-review.googlesource.com/772150 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#49429}
-
Tobias Tebbi authored
Bug: Change-Id: Ibd7c17b4ace25237c3d35466280aff27c44016f0 Reviewed-on: https://chromium-review.googlesource.com/774461Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#49427}
-
- 15 Nov, 2017 1 commit
-
-
Georg Neis authored
They can no longer return nan. They basically intersect their argument type with Type::OrderedNumber before analysing it. Never call them on Type::NaN. Bug: Change-Id: I7e7b46aa9fcde4f2644b81b3a34e76b092f633a4 Reviewed-on: https://chromium-review.googlesource.com/763410 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#49375}
-
- 14 Nov, 2017 2 commits
-
-
Georg Neis authored
R=jarin@chromium.org Bug: v8:6791 Change-Id: I29249640c4612421cd3bf938c465fc823aaa916d Reviewed-on: https://chromium-review.googlesource.com/765967Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#49360}
-
Michael Stanton authored
This reverts commit f010b28f. Reason for revert: Introduces a clusterfuzz issue and CAnary crash Original change's description: > [TurboFan] Diagnostic code to track down bug in representation selection > > We need to characterize the types of dead (IrOpcode::kDead) nodes > introduced in compilation phases prior to representation selection. > Normally, a dead node isn't expected at the start of this phase. The > question is, which phase introduced the dead node and failed to > deal with it properly? > > Bug: chromium:780658 > Change-Id: Ief5b45480bb7d704a2d09dafd60b5d389e0fd42e > Reviewed-on: https://chromium-review.googlesource.com/765968 > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Commit-Queue: Michael Stanton <mvstanton@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49328} TBR=mvstanton@chromium.org,mstarzinger@chromium.org Change-Id: I5d628eb1de630ce4a353b6ef0f80fd74ad740f17 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:780658 Reviewed-on: https://chromium-review.googlesource.com/768747Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#49347}
-
- 13 Nov, 2017 1 commit
-
-
Mike Stanton authored
We need to characterize the types of dead (IrOpcode::kDead) nodes introduced in compilation phases prior to representation selection. Normally, a dead node isn't expected at the start of this phase. The question is, which phase introduced the dead node and failed to deal with it properly? Bug: chromium:780658 Change-Id: Ief5b45480bb7d704a2d09dafd60b5d389e0fd42e Reviewed-on: https://chromium-review.googlesource.com/765968Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#49328}
-
- 10 Nov, 2017 1 commit
-
-
Georg Neis authored
There were some places left where that could happen. Bug: chromium:782754 Change-Id: I1db1f5b361cdf443b730a220c0e569ad48dd298d Reviewed-on: https://chromium-review.googlesource.com/758841Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#49283}
-
- 09 Nov, 2017 1 commit
-
-
Tobias Tebbi authored
This reverts commit ac0661b3. Reason for revert: Clusterfuzz unhappy: chromium:783019 chromium:783035 Original change's description: > Reland^5 "[turbofan] eagerly prune None types and deadness from the graph" > > This gives up on earlier attempts to interpret DeadValue as a signal of > unreachable code. This does not work because free-floating dead value > nodes, and even pure branch nodes that use them, can get scheduled so > early that they get reachable. Instead, we now eagerly remove branches > that use DeadValue in DeadCodeElimination and replace DeadValue inputs > to value phi nodes with dummy values. > > Reland of https://chromium-review.googlesource.com/715716 > > Bug: chromium:741225 chromium:776256 > Change-Id: I251efd507c967d4a8882ad8fd2fd96c4185781fe > Reviewed-on: https://chromium-review.googlesource.com/727893 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49188} TBR=jarin@chromium.org,tebbi@chromium.org Bug: chromium:741225 chromium:776256 chromium:783019 chromium:783035 Change-Id: I6a8fa3a08ce2824a858ae01817688e63ed1f442e Reviewed-on: https://chromium-review.googlesource.com/758770Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#49262}
-
- 08 Nov, 2017 1 commit
-
-
Georg Neis authored
They have been meaning the same thing for a while now. R=jarin@chromium.org Bug: Change-Id: Ie5988e6429b795babfa1e1f79841a9f03b8362dc Reviewed-on: https://chromium-review.googlesource.com/758268 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#49228}
-
- 07 Nov, 2017 1 commit
-
-
Tobias Tebbi authored
This gives up on earlier attempts to interpret DeadValue as a signal of unreachable code. This does not work because free-floating dead value nodes, and even pure branch nodes that use them, can get scheduled so early that they get reachable. Instead, we now eagerly remove branches that use DeadValue in DeadCodeElimination and replace DeadValue inputs to value phi nodes with dummy values. Reland of https://chromium-review.googlesource.com/715716 Bug: chromium:741225 chromium:776256 Change-Id: I251efd507c967d4a8882ad8fd2fd96c4185781fe Reviewed-on: https://chromium-review.googlesource.com/727893 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#49188}
-
- 27 Oct, 2017 2 commits
-
-
Benedikt Meurer authored
We now represent the SameValue operation explicitly in TurboFan and the operation can thus participate in all kinds of optimizations. Especially we get rid of the JSCall node in the general case, which blocks several optimizations across the call. The general, baseline performance is now always on par with StrictEqual. Once the StrictEqual operator is also a simplified operator, we should start unifying the type based optimizations in SimplifiedLowering. In the micro-benchmark we go from testStrictEqual: 1422 ms. testObjectIs: 1520 ms. testManualSameValue: 1759 ms. to testStrictEqual: 1426 ms. testObjectIs: 1357 ms. testManualSameValue: 1766 ms. which gives the expected result. Bug: v8:7007 Change-Id: I0de3ff6ff6209ab4c3edb69de6a16e387295a9c8 Reviewed-on: https://chromium-review.googlesource.com/741228Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48994}
-
Jaroslav Sevcik authored
This enables proper wiring into ithe control flow chain. Bug: v8:7002,chromium:777574 Change-Id: Idba59944ff6ab3c10c204bb74ace61d812e6297c Reviewed-on: https://chromium-review.googlesource.com/738183Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48990}
-
- 25 Oct, 2017 3 commits
-
-
Benedikt Meurer authored
This reverts commit 877de376. Reason for revert: Looks like this doesn't really move the needle (only w/ high iteration count). So let's not do the extra complexity unless there's a good reason to do so. Original change's description: > [turbofan] Introduce FindOrderedHashMapEntryForReceiverKey operator. > > This optimizes Map#get and Map#has for the case where the key is known > to be a JSReceiver. This generalizes the existing logic for the > FindOrderedHashMapEntryForSigned32Key operator to also deal with > receivers. This gives a nice 33% boost on the map-set-lookup-es6 test > of the six-speed benchmark suite. > > Drive-by-fix: Rename the FindOrderedHashMapEntryForInt32Key operator to > FindOrderedHashMapEntryForSigned32Key to match the naming of the types. > > R=jarin@chromium.org > > Bug: v8:5267, v8:7001 > Change-Id: Ifab8414f26adee7ec833d8cb94ae0ac49f2c3d35 > Reviewed-on: https://chromium-review.googlesource.com/738180 > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48938} TBR=jarin@chromium.org,bmeurer@chromium.org Change-Id: Icaf9e22cb3412a97342c4e4cdc422d4aaa2d0ef9 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:5267, v8:7001 Reviewed-on: https://chromium-review.googlesource.com/738052Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48941}
-
Benedikt Meurer authored
This optimizes Map#get and Map#has for the case where the key is known to be a JSReceiver. This generalizes the existing logic for the FindOrderedHashMapEntryForSigned32Key operator to also deal with receivers. This gives a nice 33% boost on the map-set-lookup-es6 test of the six-speed benchmark suite. Drive-by-fix: Rename the FindOrderedHashMapEntryForInt32Key operator to FindOrderedHashMapEntryForSigned32Key to match the naming of the types. R=jarin@chromium.org Bug: v8:5267, v8:7001 Change-Id: Ifab8414f26adee7ec833d8cb94ae0ac49f2c3d35 Reviewed-on: https://chromium-review.googlesource.com/738180Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48938}
-
Benedikt Meurer authored
This optimization was disabled because 32-bit builds didn't properly find certain integer keys in maps anymore. The reason was that the runtime wasn't using ComputeIntegerHash for the full Signed32 range, but only for the SignedSmall range. This change improves the ARES-6 Basic test by around 6-7% on the steady state. Bug: chromium:77459, v8:6410, v8:6354, v8:6278, v8:6344 Change-Id: Ifae64e6b23ca8acee4c792be299f64caf951242f Reviewed-on: https://chromium-review.googlesource.com/737871Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48905}
-
- 20 Oct, 2017 2 commits
-
-
Mike Stanton authored
JSClassOf may lower to a call to a builtin, and needs to be modeled in a way that the effect chain can be maintained. Bug: v8:6929 Change-Id: Ida332e6d85e2eb8b33fcad810d195ef3e897ccb0 Reviewed-on: https://chromium-review.googlesource.com/727204Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#48786}
-
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}
-
- 19 Oct, 2017 3 commits
-
-
Tobias Tebbi authored
This revert is manual, but almost completely automatic. It was just blocked by a single-line irrelevant refactoring change. This reverts commit 1cee0e01. Reason for revert: chromium:776256 Original change's description: > Reland^4 "[turbofan] eagerly prune None types and deadness from the graph" > > This fixes https://bugs.chromium.org/p/chromium/issues/detail?id=773954. > The issue was that in the EffectControlLinearizer, the effect input of an > {Unreachable} node was not updated, leaving a {Checkpoint} behind. > > This is a reland of 4cf47645 > Original change's description: > > Reland^3 "[turbofan] eagerly prune None types and deadness from the graph" > > > > This fixes the issues > > https://bugs.chromium.org/p/chromium/issues/detail?id=772873 > > and https://bugs.chromium.org/p/chromium/issues/detail?id=772872. > > > > One problem was that mutating an effect node into Unreachable confused > > the LoadElimination sidetables, so I just always create a new node now. > > > > The other problem was that UpdateBlockControl() was executed after > > UpdateEffectPhi() in the lazy case. This reverted the update to the Merge input. > > So now I make sure that UpdateEffectPhi() is always executed last. > > > > This is a reland of 6ddb5e7d > > Original change's description: > > > Reland^2 "[turbofan] eagerly prune None types and deadness from the graph" > > > > > > Now, the EffectControlLinearizer connects all occurrences of Unreachable to the > > > graph end. This fixes issues with later phases running DeadCodeElimination and > > > introducing new DeadValue nodes when processing uses of Unreachable. > > > > > > This is a reland of 3c4bc27f > > > Original change's description: > > > > Reland "[turbofan] eagerly prune None types and deadness from the graph" > > > > > > > > This is a reland of e1cdda25 > > > > Original change's description: > > > > > [turbofan] eagerly prune None types and deadness from the graph > > > > > > > > > > In addition to using the {Dead} node to prune dead control nodes and nodes that > > > > > depend on them, we introduce a {DeadValue} node representing an impossible value > > > > > that can occur at any position in the graph. The extended {DeadCodeElimination} > > > > > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into > > > > > the effect chain when possible. The remaining uses of {DeadValue} are handled > > > > > in {EffectControlLinearizer}, where we always have access to the effect chain. > > > > > In addition to explicitly introduced {DeadValue} nodes, we consider any value use > > > > > of a node with type {None} as dead. > > > > > > > > > > Bug: chromium:741225 > > > > > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655 > > > > > Reviewed-on: https://chromium-review.googlesource.com/641250 > > > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > > > Cr-Commit-Position: refs/heads/master@{#48208} > > > > > > > > Bug: chromium:741225 > > > > Change-Id: I21316913dae02864f7a6d7c9269405a79f054138 > > > > Reviewed-on: https://chromium-review.googlesource.com/692034 > > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > > Cr-Commit-Position: refs/heads/master@{#48232} > > > > > > Bug: chromium:741225 > > > Change-Id: I5702ec34856c075717162153adc765774453c45f > > > Reviewed-on: https://chromium-review.googlesource.com/702264 > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#48366} > > > > Bug: chromium:741225 > > Change-Id: I4054a694d2521c2e1f0c4a3ad0f3cf100b5c536f > > Reviewed-on: https://chromium-review.googlesource.com/709214 > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48469} > > Bug: chromium:741225 > Change-Id: Id9d4f3a3ae36cb3e38f80edcdba88efa7922ca24 > Reviewed-on: https://chromium-review.googlesource.com/715716 > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48660} TBR=jarin@chromium.org,tebbi@chromium.org,bmeurer@chromium.org Bug: chromium:741225 chromium:776256 Change-Id: Iaf2af3cb6dea5fdece43297cb9d987e7decc726d Reviewed-on: https://chromium-review.googlesource.com/727804 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#48749}
-
Mike Stanton authored
If we have good lower bound type information in simplified lowering that the input to PlainPrimitiveToNumber is a string, then we'd like to introduce a call to the StringToNumber builtin. However, this requires more careful management of the effect chain than we had previously. To fix this, introduce a StringToNumber opcode which defers the graph alteration until effect-control-linearization, when the effect chain is available for careful wiring. Bug: v8:6929 Change-Id: I4f0e43fe474a44d0dfa095a3a01caece649d82db Reviewed-on: https://chromium-review.googlesource.com/727934Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#48741}
-
Mike Stanton authored
Because the toboolean operator may lower to a builtin call (which is effectful in turbofan parlance after effect control linearization), it really should be encoded as a simplified operator, which can be optimized with respect for the effect chain in linearization. No new functionality here, rather a furniture rearrangement in the TurboFan node structure. Bug: v8:6929 Change-Id: I371fd22941397d5c28d13bded2738161d8da8275 Reviewed-on: https://chromium-review.googlesource.com/725721Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#48727}
-
- 18 Oct, 2017 1 commit
-
-
Tobias Tebbi authored
This fixes https://bugs.chromium.org/p/chromium/issues/detail?id=773954. The issue was that in the EffectControlLinearizer, the effect input of an {Unreachable} node was not updated, leaving a {Checkpoint} behind. This is a reland of 4cf47645 Original change's description: > Reland^3 "[turbofan] eagerly prune None types and deadness from the graph" > > This fixes the issues > https://bugs.chromium.org/p/chromium/issues/detail?id=772873 > and https://bugs.chromium.org/p/chromium/issues/detail?id=772872. > > One problem was that mutating an effect node into Unreachable confused > the LoadElimination sidetables, so I just always create a new node now. > > The other problem was that UpdateBlockControl() was executed after > UpdateEffectPhi() in the lazy case. This reverted the update to the Merge input. > So now I make sure that UpdateEffectPhi() is always executed last. > > This is a reland of 6ddb5e7d > Original change's description: > > Reland^2 "[turbofan] eagerly prune None types and deadness from the graph" > > > > Now, the EffectControlLinearizer connects all occurrences of Unreachable to the > > graph end. This fixes issues with later phases running DeadCodeElimination and > > introducing new DeadValue nodes when processing uses of Unreachable. > > > > This is a reland of 3c4bc27f > > Original change's description: > > > Reland "[turbofan] eagerly prune None types and deadness from the graph" > > > > > > This is a reland of e1cdda25 > > > Original change's description: > > > > [turbofan] eagerly prune None types and deadness from the graph > > > > > > > > In addition to using the {Dead} node to prune dead control nodes and nodes that > > > > depend on them, we introduce a {DeadValue} node representing an impossible value > > > > that can occur at any position in the graph. The extended {DeadCodeElimination} > > > > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into > > > > the effect chain when possible. The remaining uses of {DeadValue} are handled > > > > in {EffectControlLinearizer}, where we always have access to the effect chain. > > > > In addition to explicitly introduced {DeadValue} nodes, we consider any value use > > > > of a node with type {None} as dead. > > > > > > > > Bug: chromium:741225 > > > > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655 > > > > Reviewed-on: https://chromium-review.googlesource.com/641250 > > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > > Cr-Commit-Position: refs/heads/master@{#48208} > > > > > > Bug: chromium:741225 > > > Change-Id: I21316913dae02864f7a6d7c9269405a79f054138 > > > Reviewed-on: https://chromium-review.googlesource.com/692034 > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#48232} > > > > Bug: chromium:741225 > > Change-Id: I5702ec34856c075717162153adc765774453c45f > > Reviewed-on: https://chromium-review.googlesource.com/702264 > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48366} > > Bug: chromium:741225 > Change-Id: I4054a694d2521c2e1f0c4a3ad0f3cf100b5c536f > Reviewed-on: https://chromium-review.googlesource.com/709214 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48469} Bug: chromium:741225 Change-Id: Id9d4f3a3ae36cb3e38f80edcdba88efa7922ca24 Reviewed-on: https://chromium-review.googlesource.com/715716Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#48660}
-
- 16 Oct, 2017 2 commits
-
-
Mike Stanton authored
Because the typeof operator may lower to a builtin call (which is effectful in turbofan parlance after effect control linearization), it really should be encoded as a simplified operator, which can be optimized with respect for the effect chain in linearization. No new functionality here, rather a furniture rearrangement in the TurboFan node structure. BUG=v8:6929 Change-Id: I38593e10956ebd57cecdd606c35f3f73efb1327e Reviewed-on: https://chromium-review.googlesource.com/718745Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#48613}
-
Mike Stanton authored
In Array.prototype.map, we have to store the map result in an output array. If we know we are storing objects, or special objects like boolean, rather than a number, then we can reduce the amount of checks we have to do to transition the output array to the appropriate ElementsKind. Likewise, if we know we've got floating point values, we can specialize appropriately to a double array. Bug: v8:6896 Change-Id: I375daf604562b53638ea749945c1a4c907e33547 Reviewed-on: https://chromium-review.googlesource.com/711845 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48579}
-
- 13 Oct, 2017 2 commits
-
-
Jakob Kummerow authored
As a simple and backmergeable fix for crbug.com/774459. Bug: chromium:774459 Tbr: bmeurer@chromium.org Change-Id: Ibe55ad13fe6be63a76dc3079a0288356ce35de9f Reviewed-on: https://chromium-review.googlesource.com/719461 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48561}
-
Michael Starzinger authored
This adds and explicit check for the constructability of the new.target value in the lowering of {JSCall} nodes known to call Reflect.construct. The {JSConstruct} operator does not perform this check and relies on the implicit validity of new.target in all other use cases. R=jarin@chromium.org TEST=mjsunit/regress/regress-crbug-768080 BUG=chromium:768080 Change-Id: I7c1921e787bae64ba83de3eb08aa00fc5523e251 Reviewed-on: https://chromium-review.googlesource.com/718100Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48543}
-
- 12 Oct, 2017 1 commit
-
-
Benedikt Meurer authored
This reverts commit 4cf47645. Reason for revert: Broken effect chains detected by Clusterfuzz. Playing it safe for the 63 branch. Original change's description: > Reland^3 "[turbofan] eagerly prune None types and deadness from the graph" > > This fixes the issues > https://bugs.chromium.org/p/chromium/issues/detail?id=772873 > and https://bugs.chromium.org/p/chromium/issues/detail?id=772872. > > One problem was that mutating an effect node into Unreachable confused > the LoadElimination sidetables, so I just always create a new node now. > > The other problem was that UpdateBlockControl() was executed after > UpdateEffectPhi() in the lazy case. This reverted the update to the Merge input. > So now I make sure that UpdateEffectPhi() is always executed last. > > This is a reland of 6ddb5e7d > Original change's description: > > Reland^2 "[turbofan] eagerly prune None types and deadness from the graph" > > > > Now, the EffectControlLinearizer connects all occurrences of Unreachable to the > > graph end. This fixes issues with later phases running DeadCodeElimination and > > introducing new DeadValue nodes when processing uses of Unreachable. > > > > This is a reland of 3c4bc27f > > Original change's description: > > > Reland "[turbofan] eagerly prune None types and deadness from the graph" > > > > > > This is a reland of e1cdda25 > > > Original change's description: > > > > [turbofan] eagerly prune None types and deadness from the graph > > > > > > > > In addition to using the {Dead} node to prune dead control nodes and nodes that > > > > depend on them, we introduce a {DeadValue} node representing an impossible value > > > > that can occur at any position in the graph. The extended {DeadCodeElimination} > > > > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into > > > > the effect chain when possible. The remaining uses of {DeadValue} are handled > > > > in {EffectControlLinearizer}, where we always have access to the effect chain. > > > > In addition to explicitly introduced {DeadValue} nodes, we consider any value use > > > > of a node with type {None} as dead. > > > > > > > > Bug: chromium:741225 > > > > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655 > > > > Reviewed-on: https://chromium-review.googlesource.com/641250 > > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > > Cr-Commit-Position: refs/heads/master@{#48208} > > > > > > Bug: chromium:741225 > > > Change-Id: I21316913dae02864f7a6d7c9269405a79f054138 > > > Reviewed-on: https://chromium-review.googlesource.com/692034 > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#48232} > > > > Bug: chromium:741225 > > Change-Id: I5702ec34856c075717162153adc765774453c45f > > Reviewed-on: https://chromium-review.googlesource.com/702264 > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48366} > > Bug: chromium:741225 > Change-Id: I4054a694d2521c2e1f0c4a3ad0f3cf100b5c536f > Reviewed-on: https://chromium-review.googlesource.com/709214 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48469} TBR=jarin@chromium.org,tebbi@chromium.org Change-Id: Icf6a6af4feaafd4bde28cb7b996735ff91bb3810 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:741225 Reviewed-on: https://chromium-review.googlesource.com/715096Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48482}
-
- 11 Oct, 2017 1 commit
-
-
Tobias Tebbi authored
This fixes the issues https://bugs.chromium.org/p/chromium/issues/detail?id=772873 and https://bugs.chromium.org/p/chromium/issues/detail?id=772872. One problem was that mutating an effect node into Unreachable confused the LoadElimination sidetables, so I just always create a new node now. The other problem was that UpdateBlockControl() was executed after UpdateEffectPhi() in the lazy case. This reverted the update to the Merge input. So now I make sure that UpdateEffectPhi() is always executed last. This is a reland of 6ddb5e7d Original change's description: > Reland^2 "[turbofan] eagerly prune None types and deadness from the graph" > > Now, the EffectControlLinearizer connects all occurrences of Unreachable to the > graph end. This fixes issues with later phases running DeadCodeElimination and > introducing new DeadValue nodes when processing uses of Unreachable. > > This is a reland of 3c4bc27f > Original change's description: > > Reland "[turbofan] eagerly prune None types and deadness from the graph" > > > > This is a reland of e1cdda25 > > Original change's description: > > > [turbofan] eagerly prune None types and deadness from the graph > > > > > > In addition to using the {Dead} node to prune dead control nodes and nodes that > > > depend on them, we introduce a {DeadValue} node representing an impossible value > > > that can occur at any position in the graph. The extended {DeadCodeElimination} > > > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into > > > the effect chain when possible. The remaining uses of {DeadValue} are handled > > > in {EffectControlLinearizer}, where we always have access to the effect chain. > > > In addition to explicitly introduced {DeadValue} nodes, we consider any value use > > > of a node with type {None} as dead. > > > > > > Bug: chromium:741225 > > > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655 > > > Reviewed-on: https://chromium-review.googlesource.com/641250 > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#48208} > > > > Bug: chromium:741225 > > Change-Id: I21316913dae02864f7a6d7c9269405a79f054138 > > Reviewed-on: https://chromium-review.googlesource.com/692034 > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48232} > > Bug: chromium:741225 > Change-Id: I5702ec34856c075717162153adc765774453c45f > Reviewed-on: https://chromium-review.googlesource.com/702264 > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48366} Bug: chromium:741225 Change-Id: I4054a694d2521c2e1f0c4a3ad0f3cf100b5c536f Reviewed-on: https://chromium-review.googlesource.com/709214 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48469}
-
- 09 Oct, 2017 1 commit
-
-
Tobias Tebbi authored
This reverts commit 6ddb5e7d. Reason for revert: chromium:772873 chromium:772872 Original change's description: > Reland^2 "[turbofan] eagerly prune None types and deadness from the graph" > > Now, the EffectControlLinearizer connects all occurrences of Unreachable to the > graph end. This fixes issues with later phases running DeadCodeElimination and > introducing new DeadValue nodes when processing uses of Unreachable. > > This is a reland of 3c4bc27f > Original change's description: > > Reland "[turbofan] eagerly prune None types and deadness from the graph" > > > > This is a reland of e1cdda25 > > Original change's description: > > > [turbofan] eagerly prune None types and deadness from the graph > > > > > > In addition to using the {Dead} node to prune dead control nodes and nodes that > > > depend on them, we introduce a {DeadValue} node representing an impossible value > > > that can occur at any position in the graph. The extended {DeadCodeElimination} > > > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into > > > the effect chain when possible. The remaining uses of {DeadValue} are handled > > > in {EffectControlLinearizer}, where we always have access to the effect chain. > > > In addition to explicitly introduced {DeadValue} nodes, we consider any value use > > > of a node with type {None} as dead. > > > > > > Bug: chromium:741225 > > > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655 > > > Reviewed-on: https://chromium-review.googlesource.com/641250 > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#48208} > > > > Bug: chromium:741225 > > Change-Id: I21316913dae02864f7a6d7c9269405a79f054138 > > Reviewed-on: https://chromium-review.googlesource.com/692034 > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#48232} > > Bug: chromium:741225 > Change-Id: I5702ec34856c075717162153adc765774453c45f > Reviewed-on: https://chromium-review.googlesource.com/702264 > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48366} TBR=jarin@chromium.org,tebbi@chromium.org Change-Id: Ib0f59b8463681abf6a9158112515aefae3c76b5f No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:741225 Reviewed-on: https://chromium-review.googlesource.com/707275Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#48407}
-