- 07 Dec, 2015 1 commit
-
-
bmeurer authored
The JSInliningHeuristic keeps a list of nodes, which might have been killed by other reducers before the JSInliningHeuristic looks at it again, so it has to check whether nodes are dead before trying to expand them later (this is similar to what the ValueNumberingReducer needs to do with its internal table). R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1508643002 Cr-Commit-Position: refs/heads/master@{#32652}
-
- 04 Dec, 2015 1 commit
-
-
bmeurer authored
Revert of Provide call counts for constructor calls, surface them as a vector IC. (patchset #4 id:60001 of https://codereview.chromium.org/1476413003/ ) Reason for revert: Seems to be (mostly) responsible for the most recent Speedometer regression, not 100% sure. Let's see what the bots have to say. Original issue's description: > Provide call counts for constructor calls, surface them as a vector IC. > > CallIC and CallConstructStub look so alike, at least in the feedback they gather even if the implementation differs...and CallIC has such a nice way of surfacing the feedback (CallICNexus), that there is a request to make CallConstructStub look analogous. Enter ConstructICStub. > > BUG= > > Committed: https://crrev.com/66d5a9df62da458a51e8c7ed1811dc9660f4f418 > Cr-Commit-Position: refs/heads/master@{#32452} TBR=mvstanton@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1489413006 Cr-Commit-Position: refs/heads/master@{#32599}
-
- 01 Dec, 2015 1 commit
-
-
mvstanton authored
CallIC and CallConstructStub look so alike, at least in the feedback they gather even if the implementation differs...and CallIC has such a nice way of surfacing the feedback (CallICNexus), that there is a request to make CallConstructStub look analogous. Enter ConstructICStub. BUG= Review URL: https://codereview.chromium.org/1476413003 Cr-Commit-Position: refs/heads/master@{#32452}
-
- 13 Nov, 2015 1 commit
-
-
bmeurer authored
Continue with the other candidates in case of a failed attempt to inline a certain candidate. TBR=mstarzinger@chromium.org BUG=v8:4493 LOG=n Review URL: https://codereview.chromium.org/1435373002 Cr-Commit-Position: refs/heads/master@{#31975}
-
- 12 Nov, 2015 2 commits
-
-
bmeurer authored
Only inline one candidate per iteration to make sure we really inline the stuff that is called most often. R=mstarzinger@chromium.org BUG=v8:4493, v8:4544 LOG=n Review URL: https://codereview.chromium.org/1439773003 Cr-Commit-Position: refs/heads/master@{#31958}
-
mstarzinger authored
This implements a first version of support for constructor call inlining in the inlining machinery. For now we can only inline calls where the actual constructor and the original constructor coincide (i.e. no super constructor calls). Note that the target of a super constructor call is loaded with a runtime call, so there is no way for it to be constant promoted at the moment. R=bmeurer@chromium.org BUG=v8:4544 LOG=n Review URL: https://codereview.chromium.org/1435873002 Cr-Commit-Position: refs/heads/master@{#31954}
-
- 11 Nov, 2015 1 commit
-
-
bmeurer authored
R=mstarzinger@chromium.org BUG=v8:4493 LOG=n Review URL: https://codereview.chromium.org/1432223002 Cr-Commit-Position: refs/heads/master@{#31944}
-
- 09 Nov, 2015 2 commits
-
-
mstarzinger authored
This redcues the noise created by --trace-turbo-inlining when there actually are no candidates being processed. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1410723004 Cr-Commit-Position: refs/heads/master@{#31885}
-
bmeurer authored
Introduce Reducer::Finalize, which get's called by the GraphReducer once all reductions are done, and use this to implement full inlining as part of the regular reducer fixpoint. R=jarin@chromium.org BUG=v8:4493 LOG=n Review URL: https://codereview.chromium.org/1419373012 Cr-Commit-Position: refs/heads/master@{#31875}
-
- 03 Nov, 2015 1 commit
-
-
mstarzinger authored
This changes the inlining candidates to be stored in a sorted set of unique entries instead of a vector. We can avoid the final sorting operation by amortizing the cost across insertions and also duplicate entries are not created in the first place. Duplicate entries cause crashes when candidates are processed. R=bmeurer@chromium.org BUG=chromium:549113 LOG=n Review URL: https://codereview.chromium.org/1430553003 Cr-Commit-Position: refs/heads/master@{#31742}
-
- 29 Oct, 2015 1 commit
-
-
mstarzinger authored
This adapts the general purpose inlining heuristic to not inline within or across the boundary of asm.js code. Note that this only affects the heuristics, from a functional point of view it is still supported. R=bmeurer@chromium.org BUG=chromium:549000 LOG=n Review URL: https://codereview.chromium.org/1418823005 Cr-Commit-Position: refs/heads/master@{#31654}
-
- 15 Oct, 2015 1 commit
-
-
mstarzinger authored
This is in preparation to enabling --turbo-inlining by default, fixing various issues when general purpose inlining is running against our entire test suite. R=bmeurer@chromium.org BUG=v8:4493 LOG=n Review URL: https://codereview.chromium.org/1407533004 Cr-Commit-Position: refs/heads/master@{#31294}
-
- 14 Oct, 2015 1 commit
-
-
mstarzinger authored
This is a first prototype for a rudimentary inlining heuristic allowing enabling of general inlining based existing budget flags. Also note that this approach does not yet work for multi-level inlining, for now the list of candidates is processed exactly once. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1406543002 Cr-Commit-Position: refs/heads/master@{#31249}
-
- 07 Oct, 2015 1 commit
-
-
mstarzinger authored
This separates the core machinery and the heuristics involved with inlining functions calls. So far the heuristic only respects our %SetForceInlineFlag hint, but it will the place where general inlining heuristics can live without impeding clarity of the core machinery. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1391903002 Cr-Commit-Position: refs/heads/master@{#31150}
-