- 15 Mar, 2017 1 commit
-
-
Michael Starzinger authored
This changes the IR to no longer require single {IfSuccess} projection nodes unless there is a corresponding {IfException} node that links the potentially throwing call to an exception handler. This reduces graph size as well as compilation time when exception handlers aren't present. The new invariant for potentially throwing nodes is: Nodes that can potentially throw either have both IfSuccess/IfException projections as the only control uses and no direct control uses, or no projections at all and solely direct control uses. R=jarin@chromium.org Change-Id: I3d9cd816d74ad5af13e0673da7ec7a98f1ecdc7e Reviewed-on: https://chromium-review.googlesource.com/449715 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#43814}
-
- 03 Mar, 2017 1 commit
-
-
mvstanton authored
Also prevent division by zero. R=tebbi@chromium.org BUG= Review-Url: https://codereview.chromium.org/2731723002 Cr-Commit-Position: refs/heads/master@{#43590}
-
- 06 Feb, 2017 1 commit
-
-
mstarzinger authored
This adapts the inlining logic to allow for inlining based solely on a statically known underlying SharedFunctionInfo instead of a concrete closure of the call target. In cases where the closure is known, its bound context is constant promoted just as before. In the new cases where only the SFI for an entire class of closures is known, we use the dynamic SSA-value of the bound context. R=bmeurer@chromium.org BUG=v8:2206 Review-Url: https://codereview.chromium.org/2626783003 Cr-Commit-Position: refs/heads/master@{#42968}
-
- 01 Feb, 2017 2 commits
-
-
petermarshall authored
Review-Url: https://codereview.chromium.org/2666783007 Cr-Commit-Position: refs/heads/master@{#42847}
-
petermarshall authored
Review-Url: https://codereview.chromium.org/2662263002 Cr-Commit-Position: refs/heads/master@{#42836}
-
- 17 Nov, 2016 1 commit
-
-
yangguo authored
This method is a slight misnomer. What we actually want to know is whether the function was defined in a user-provided script. Also remove redundant Script::hide_source flag. R=bmeurer@chromium.org, ulan@chromium.org Review-Url: https://codereview.chromium.org/2505853003 Cr-Commit-Position: refs/heads/master@{#41065}
-
- 16 Nov, 2016 2 commits
-
-
machenbach authored
Revert of Refactor SharedFunctionInfo::IsBuiltin. (patchset #1 id:1 of https://codereview.chromium.org/2505853003/ ) Reason for revert: Breaks layout tests: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/11394 Original issue's description: > Refactor SharedFunctionInfo::IsBuiltin. > > This method is a slight misnomer. What we actually want to know is > whether the function was defined in a user-provided script. > > Also remove redundant Script::hide_source flag. > > R=bmeurer@chromium.org, ulan@chromium.org TBR=bmeurer@chromium.org,ulan@chromium.org,yangguo@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/2512463002 Cr-Commit-Position: refs/heads/master@{#41050}
-
yangguo authored
This method is a slight misnomer. What we actually want to know is whether the function was defined in a user-provided script. Also remove redundant Script::hide_source flag. R=bmeurer@chromium.org, ulan@chromium.org Review-Url: https://codereview.chromium.org/2505853003 Cr-Commit-Position: refs/heads/master@{#41036}
-
- 11 Nov, 2016 1 commit
-
-
ulan authored
BUG=v8:5614 Review-Url: https://codereview.chromium.org/2493173002 Cr-Commit-Position: refs/heads/master@{#40916}
-
- 23 Sep, 2016 3 commits
-
-
bmeurer authored
The source size is not a real indicator for whether or not to inline a certain function. R=ishell@chromium.org, jarin@chromium.org BUG=v8:3354,v8:5267 Committed: https://chromium.googlesource.com/v8/v8/+/1b33028607637ba8cb2d60433811f825b00a0cc1 Review-Url: https://codereview.chromium.org/2361813002 Cr-Commit-Position: refs/heads/master@{#39681}
-
machenbach authored
Revert of [turbofan] Don't take into account source size for inlining heuristics. (patchset #4 id:60001 of https://codereview.chromium.org/2361813002/ ) Reason for revert: timeouts on windows: https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/12504 Original issue's description: > [turbofan] Don't take into account source size for inlining heuristics. > > The source size is not a real indicator for whether or not to inline a > certain function. > > R=ishell@chromium.org, jarin@chromium.org > BUG=v8:3354,v8:5267 > > Committed: https://chromium.googlesource.com/v8/v8/+/1b33028607637ba8cb2d60433811f825b00a0cc1 TBR=ishell@chromium.org,jarin@chromium.org,bmeurer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:3354,v8:5267 Review-Url: https://codereview.chromium.org/2362853003 Cr-Commit-Position: refs/heads/master@{#39661}
-
Benedikt Meurer authored
The source size is not a real indicator for whether or not to inline a certain function. R=ishell@chromium.org, jarin@chromium.org BUG=v8:3354,v8:5267 Review URL: https://codereview.chromium.org/2361813002 . Cr-Commit-Position: refs/heads/master@{#39659}
-
- 14 Sep, 2016 2 commits
-
-
bmeurer authored
Extract the call counts from the type feedback vector during graph building (either via the AstGraphBuilder or the BytecodeGraphBuilder), and put them onto the JSCallFunction and JSCallConstruct operators, so that they work even across inlinine through .apply and .call (which was previously hacked by creating a temporary type feedback vector for those). The next logic step will be to make those call counts into real relative call frequencies (also during graph building), so that we can make inlining decisions that make sense for the function being optimized (where absolute values are misleading). R=jarin@chromium.org BUG=v8:5267,v8:5372 Review-Url: https://codereview.chromium.org/2330883002 Cr-Commit-Position: refs/heads/master@{#39400}
-
mvstanton authored
BUG= Review-Url: https://codereview.chromium.org/2333243004 Cr-Commit-Position: refs/heads/master@{#39398}
-
- 13 Sep, 2016 2 commits
-
-
bmeurer authored
Don't sort inline candidates by comparing Node pointers, where the order depends on the allocation order and the concrete Zone memory layout at runtime. Instead sort based on NodeId, which is deterministic. R=mvstanton@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2336113002 Cr-Commit-Position: refs/heads/master@{#39371}
-
bmeurer authored
Cleanup fix addressing the comment on crrev.com/2325943002. TBR=jarin@chromium.org,brucedawson@chromium.org Review-Url: https://codereview.chromium.org/2335083002 Cr-Commit-Position: refs/heads/master@{#39364}
-
- 12 Sep, 2016 1 commit
-
-
bmeurer authored
The logic to test whether we already reached --max_inlining_levels when inlining into some optimized function only checked specifically for FrameStateType::kJavaScriptFunction, and thereby didn't properly account for FrameStateType::kInterpretedFunction, which is what we see when we come in via the bytecode pipeline. Review-Url: https://codereview.chromium.org/2329923002 Cr-Commit-Position: refs/heads/master@{#39328}
-
- 09 Sep, 2016 1 commit
-
-
bmeurer authored
For call sites where the target is not a known constant, but potentially a list of known constants (i.e. a Phi with all HeapConstant inputs), we still record the call site as a potential candidate for inlining. In case the heuristic picks that candidate for inlining, we expand the call site to a dispatched call site and invoke the actual inlining logic for all the nested call sites. Like Crankshaft, we currently allow up to 4 targets for polymorphic inlining, although we might want to refine that later. This approach is different from what Crankshaft does in that we don't duplicate the evaluation of the parameters per polymorphic case. Instead we first perform the load of the target (which usually dispatches based on the receiver map), then we evaluate all the parameters, and then we dispatch again based on the known targets. This might generate better or worse code compared to what Crankshaft does, and for the cases where we generate worse code (i.e. because we have only trivial parameters or no parameters at all), we might want to investigate optimizing away the double dispatch in the future. R=mvstanton@chromium.org BUG=v8:5267,v8:5365 Review-Url: https://codereview.chromium.org/2325943002 Cr-Commit-Position: refs/heads/master@{#39302}
-
- 31 Aug, 2016 1 commit
-
-
marja authored
This way, many files which only need CompilationInfo but not compiler.h and its dependencies can include just compilation-info.h. BUG= Review-Url: https://codereview.chromium.org/2284313003 Cr-Commit-Position: refs/heads/master@{#39038}
-
- 29 Aug, 2016 1 commit
-
-
bgeron authored
This removes test/webkit/fast/js/stack-overflow-arrity-catch.js, which tests that the stack overflows in a very particular way. It doesn't seem to test anything important, and only used to work because we didn't inline into try-blocks. BUG= R=jarin Review-Url: https://codereview.chromium.org/2216353002 Cr-Commit-Position: refs/heads/master@{#38976}
-
- 03 Aug, 2016 1 commit
-
-
mstarzinger authored
This completely removes the ability from nodes to point directly to the frame state representing their eager bailout point. All nodes now either have zero or one frame state inputs. These frame states can by now be found via checkpoints in the graph. R=bmeurer@chromium.org BUG=v8:5021 Review-Url: https://codereview.chromium.org/2020323004 Cr-Commit-Position: refs/heads/master@{#38282}
-
- 30 May, 2016 1 commit
-
-
bmeurer authored
Utilize the previously introduced construct call counts in the JSInliningHeuristic to also handle constructor calls properly. R=mvstanton@chromium.org Review-Url: https://codereview.chromium.org/2026513003 Cr-Commit-Position: refs/heads/master@{#36585}
-
- 21 Mar, 2016 1 commit
-
-
ulan authored
STL requires comparison to be a strict weak ordering. In particular the predicate should be antisymmetric: f(x, y) implies !f(y, x). BUG=v8:4848 LOG=NO Review URL: https://codereview.chromium.org/1818043004 Cr-Commit-Position: refs/heads/master@{#34960}
-
- 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}
-