- 09 Sep, 2015 1 commit
-
-
mstarzinger authored
R=bmeurer@chromium.org BUG=chromium:527364 LOG=n Review URL: https://codereview.chromium.org/1322203005 Cr-Commit-Position: refs/heads/master@{#30651}
-
- 01 Sep, 2015 1 commit
-
-
mstarzinger authored
Now that it is no longer needed, this also removes the invalid inclusion of "object-inl.h" within the "unique.h" header file. Note that this change still leaves 2 violations of that rule in the code, checked with the "tools/check-inline-includes.sh" tool. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1321223002 Cr-Commit-Position: refs/heads/master@{#30503}
-
- 31 Aug, 2015 1 commit
-
-
mstarzinger authored
The usage of Unique<T> throughout the TurboFan IR does not have any advantage. There is no single point in time when they are initialized and most use-sites looked through to the underlying Handle<T> anyways. Also there already was a mixture of Handle<T> versus Unique<T> in the graph and this unifies the situation to use Handle<T> everywhere. R=bmeurer@chromium.org,titzer@chromium.org Review URL: https://codereview.chromium.org/1314473007 Cr-Commit-Position: refs/heads/master@{#30458}
-
- 24 Jul, 2015 1 commit
-
-
yangguo authored
R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/1248443003 Cr-Commit-Position: refs/heads/master@{#29840}
-
- 20 Jul, 2015 2 commits
-
-
danno authored
In many cases, the context that TurboFan's ASTGraphBuilder or subsequent reduction operations attaches to nodes does not need to be that exact context, but rather only needs to be one with the same native context, because it is used internally only to fetch the native context, e.g. for creating and throwing exceptions. This reducer recognizes common cases where the context that is specified for a node can be relaxed to a canonical, less specific one. This relaxed context can either be the enclosing function's context or a specific Module or Script context that is explicitly created within the function. This optimization is especially important for TurboFan-generated code stubs which use context specialization and inlining to generate optimal code. Without context relaxation, many extraneous moves are generated to pass exactly the right context to internal functions like ToNumber and AllocateHeapNumber, which only need the native context. By turning context relaxation on, these moves disappear because all these common internal context uses are unified to the context passed into the stub function, which is typically already in the correct context register and remains there for short stubs. It also eliminates the explicit use of a specialized context constant in the code stub in these cases, which could cause memory leaks. Review URL: https://codereview.chromium.org/1244583003 Cr-Commit-Position: refs/heads/master@{#29763}
-
yangguo authored
Prior to this patch, we enter a global debug mode whenever a break point is set. By entering this mode, all code is deoptimized and activated frames are recompiled and redirected to newly compiled debug code. After this patch, we only deoptimize/redirect for functions we want to debug. Trigger for this is Debug::EnsureDebugInfo, and having DebugInfo object attached to the SFI prevents optimization/inlining. The result is that we can have optimized code for functions without break points alongside functions that do have break points, which are not optimized. R=mstarzinger@chromium.org, ulan@chromium.org BUG=v8:4132 LOG=Y Review URL: https://codereview.chromium.org/1233073005 Cr-Commit-Position: refs/heads/master@{#29758}
-
- 06 Jul, 2015 1 commit
-
-
bmeurer authored
Remove the context specialization hack from the AstGraphBuilder, and properly specialize to the function context in the context specialization. And replace the correct context in the JSInliner. R=mstarzinger@chromium.org BUG=v8:4273 LOG=n Review URL: https://codereview.chromium.org/1218873005 Cr-Commit-Position: refs/heads/master@{#29493}
-
- 30 Jun, 2015 3 commits
-
-
bmeurer authored
R=jarin@chromium.org Review URL: https://codereview.chromium.org/1213383002 Cr-Commit-Position: refs/heads/master@{#29376}
-
bmeurer authored
The deoptimizer (and probably various other places) cannot deal properly with recursive function inlining, so we disallow it in TurboFan as well. We might want to reconsider that decision at some point in the future. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1211243007 Cr-Commit-Position: refs/heads/master@{#29374}
-
bmeurer authored
Ideally inliner itself should not deal with context specialization at all, since this is all handled in the pipeline instead (actually inlining already runs together with context specialization), and the inlining logic should not care about the specialization mode. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1217973003 Cr-Commit-Position: refs/heads/master@{#29366}
-
- 23 Jun, 2015 1 commit
-
-
jarin authored
This also threads through the parameter count and local count to the instruction selector. This will be later used to allow merging of various StateValues vector (and prepare for differential encoding which will not distinguish between parameters, locals and expression stack). BUG= Review URL: https://codereview.chromium.org/1191243003 Cr-Commit-Position: refs/heads/master@{#29214}
-
- 19 Jun, 2015 2 commits
-
-
bmeurer authored
BUG=v8:3809 LOG=n R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/1196623002 Cr-Commit-Position: refs/heads/master@{#29147}
-
bmeurer authored
The three different concerns that the ControlReducer used to deal with are now properly separated into a.) DeadCodeElimination, which is a regular AdvancedReducer, that propagates Dead via control edges, b.) CommonOperatorReducer, which does strength reduction on common operators (i.e. Branch, Phi, and friends), and c.) GraphTrimming, which removes dead->live edges from the graph. This will make it possible to run the DeadCodeElimination together with other passes that actually introduce Dead nodes, i.e. typed lowering; and it opens the door for general inlining without two stage fix point iteration. To make the DeadCodeElimination easier and more uniform, we basically reverted the introduction of DeadValue and DeadEffect, and changed the Dead operator to produce control, value and effect. Note however that this is not a requirement, but merely a way to make dead propagation easier and more uniform. We could always go back and decide to have different Dead operators if some other change requires that. Note that there are several additional opportunities for cleanup now, i.e. OSR deconstruction could be a regular reducer now, and we don't need to use TheHole as dead value marker in the GraphReducer. And we can actually run the dead code elimination together with the other passes instead of using separate passes over the graph. We will do this in follow up CLs. R=jarin@chromium.org, mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1193833002 Cr-Commit-Position: refs/heads/master@{#29146}
-
- 18 Jun, 2015 1 commit
-
-
mstarzinger authored
R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1186033006 Cr-Commit-Position: refs/heads/master@{#29104}
-
- 11 Jun, 2015 3 commits
-
-
bmeurer authored
Previously we only recorded the SharedFunctionInfo of inlined functions that had at least one (lazy) deopt point left at code generation time. R=mstarzinger@chromium.org Committed: https://chromium.googlesource.com/v8/v8/+/ffa0b4007cd7de0cfd6d37079ef360e3beeb5686 Review URL: https://codereview.chromium.org/1175953002 Cr-Commit-Position: refs/heads/master@{#28922}
-
bmeurer authored
Revert of [turbofan] Record the SharedFunctionInfo of ALL inlined functions. (patchset #2 id:20001 of https://codereview.chromium.org/1175953002/) Reason for revert: Breaks Windows debug. Original issue's description: > [turbofan] Record the SharedFunctionInfo of ALL inlined functions. > > Previously we only recorded the SharedFunctionInfo of inlined functions > that had at least one (lazy) deopt point left at code generation time. > > R=mstarzinger@chromium.org > > Committed: https://chromium.googlesource.com/v8/v8/+/ffa0b4007cd7de0cfd6d37079ef360e3beeb5686 TBR=mstarzinger@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1178683004 Cr-Commit-Position: refs/heads/master@{#28920}
-
Benedikt Meurer authored
Previously we only recorded the SharedFunctionInfo of inlined functions that had at least one (lazy) deopt point left at code generation time. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1175953002. Cr-Commit-Position: refs/heads/master@{#28919}
-
- 10 Jun, 2015 1 commit
-
-
bmeurer authored
Up until now we can only inline based on JSFunction, because of the way the deoptimization works. With this change we will be able to inline based on the SharedFunctionInfo and materialize the JSFunction from a literal or a stack slot when necessary. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1169103004 Cr-Commit-Position: refs/heads/master@{#28906}
-
- 08 Jun, 2015 1 commit
-
-
mstarzinger authored
This in turn allows usage of AdvancedReducer::ReplaceWithValue which has access to the underlying graph reducer. R=titzer@chromium.org Review URL: https://codereview.chromium.org/1162903006 Cr-Commit-Position: refs/heads/master@{#28838}
-
- 05 Jun, 2015 1 commit
-
-
mstarzinger authored
This allows any AdvancedReducer to remove exception projections from graphs. This is the common case when JS-operators are being replaced with pure values. The old NodeProperties::ReplaceWithValue is being deprecated in favor of AdvancedReducer::ReplaceWithValue. R=titzer@chromium.org TEST=unittests/AdvancedReducerTest Review URL: https://codereview.chromium.org/1168693002 Cr-Commit-Position: refs/heads/master@{#28810}
-
- 27 May, 2015 1 commit
-
-
bmeurer authored
This simplifies inlining, in that we only need to update uses of Start and inputs of End instead of walking the whole inlinee to update all outer frame states. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1146403008 Cr-Commit-Position: refs/heads/master@{#28649}
-
- 26 May, 2015 2 commits
-
-
bmeurer authored
This way we don't need to connect (potentially) non-terminating loops later during control reduction, which saves one forward pass over the control graph. Long term we will move the trimming functionality of the control reducer to the GraphReducer, and get rid of the Finish method again. As a bonus, this change also properly rewires Terminate, Throw and Deoptimize during inlining. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1155683004 Cr-Commit-Position: refs/heads/master@{#28625}
-
bmeurer authored
This simplifies the handling of the End node. Based on this CL we will finally fix terminating every loop from the beginning (via Terminate nodes) and fix inlining of Throw, Deoptimize and Terminate. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1157023002 Cr-Commit-Position: refs/heads/master@{#28620}
-
- 21 May, 2015 2 commits
-
-
bmeurer authored
The inliner previously assumed that there will only be returns reaching the end node, but that's not true. This refactoring will make it possible to also hook up Deoptimize, Throw and Terminate nodes reaching end properly. R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1146393002 Cr-Commit-Position: refs/heads/master@{#28550}
-
bmeurer authored
Replace the --turbo-deoptimization flag with --turbo-asm-deoptimization and enable deoptimization for non-asm.js TurboFan code unconditionally. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1153483002 Cr-Commit-Position: refs/heads/master@{#28543}
-
- 20 May, 2015 1 commit
-
-
danno authored
Review URL: https://codereview.chromium.org/1140743004 Cr-Commit-Position: refs/heads/master@{#28510}
-
- 19 May, 2015 1 commit
-
-
bmeurer authored
During inlining we should pay attention to only rewire the outer frame states of the inlinee, but leave any inner frame states of the inlinee untouched. Otherwise we might run into trouble once we start caching graphs, or do getter/setter inlining. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1134973006 Cr-Commit-Position: refs/heads/master@{#28466}
-
- 15 May, 2015 1 commit
-
-
bmeurer authored
First step towards support for inlining based on SharedFunctionInfo instead of JSFunction. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1134713004 Cr-Commit-Position: refs/heads/master@{#28419}
-
- 12 May, 2015 1 commit
-
-
titzer authored
[turbofan] Add AdvancedReducer::ReplaceWithValue() method and convert JSInlining to an AdvancedReducer. Note that this is just a duplication for now. We'll want to get rid of the NodeProperties::ReplaceWithValue() method in the long run. R=bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/1135483004 Cr-Commit-Position: refs/heads/master@{#28363}
-
- 11 May, 2015 1 commit
-
-
arv authored
In strong mode it is an error to call a function with too few arguments. This is enforced inside the ArgumentsAdaptorTrampoline. This does not yet handle rest parameters BUG=v8:3956 LOG=N R=rossberg@chromium.org, dslomov@chromium.org Review URL: https://codereview.chromium.org/1115263004 Cr-Commit-Position: refs/heads/master@{#28346}
-
- 23 Apr, 2015 1 commit
-
-
bmeurer authored
Now all nodes that care about deoptimization always take frame state inputs no matter whether deoptimization is enabled for a particular function. In case that deoptimization is off, the AstGraphBuilder just inserts the empty frame state. This greatly simplifies the logic in various places and makes testing easier as well, and is probably the first step towards enabling --turbo-deoptimization by default. There seems to be no noticable performance impact on asm.js programs. Also fix the graph replay in order to regenerate the scheduler unittests. Review URL: https://codereview.chromium.org/1106613003 Cr-Commit-Position: refs/heads/master@{#28026}
-
- 22 Apr, 2015 1 commit
-
-
titzer authored
R=bmeurer@chromium.org, mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1090303004 Cr-Commit-Position: refs/heads/master@{#28002}
-
- 24 Mar, 2015 2 commits
-
-
mstarzinger authored
This removes the CompilationInfoWithZone class from the header file because it is more than a pure convenience class and shouldn't be used outside of the compiler at all. R=titzer@chromium.org Review URL: https://codereview.chromium.org/1000353004 Cr-Commit-Position: refs/heads/master@{#27411}
-
titzer authored
R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1032553006 Cr-Commit-Position: refs/heads/master@{#27401}
-
- 17 Mar, 2015 1 commit
-
-
titzer authored
R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1014853002 Cr-Commit-Position: refs/heads/master@{#27248}
-
- 10 Mar, 2015 1 commit
-
-
bmeurer authored
Context specialization enables inlining (at least currently it is the only enabler for inlining), but inlining enables more possibilities for context specialization. So we really need to run them together. This is especially important with the "module based builtins" that we're working towards. BUG=v8:3952 LOG=n Review URL: https://codereview.chromium.org/988423004 Cr-Commit-Position: refs/heads/master@{#27085}
-
- 09 Mar, 2015 4 commits
-
-
titzer authored
Rationale: separate the inputs and outputs of parsing + analysis from the business of compiling (i.e. generating machine code). BUG= Review URL: https://codereview.chromium.org/974213002 Cr-Commit-Position: refs/heads/master@{#27078}
-
Benedikt Meurer authored
The JSInliner used to load the context from the JSFunction node at runtime, which introduced a HeapConstant (because we had to materialize the JSFunction after context specialization) and a LoadField operation, independent whether the inlinee actually uses the context. This is rather cumbersome currently, and therefore this is now changed to just embed the context constant instead. Once we do inlining based on SharedFunctionInfo rather than JSFunction, we should reconsider this decision and come up with a proper heuristic. BUG=v8:3952 LOG=n R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/994523002 Cr-Commit-Position: refs/heads/master@{#27069}
-
Jaroslav Sevcik authored
BUG= R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/983153002 Cr-Commit-Position: refs/heads/master@{#27060}
-
Benedikt Meurer authored
We mark certain builtins for inlining, and those should always be inlined into optimized code (CrankShaft already handles it this way), so we should support that in TurboFan as well. Currently this mainly affects a certain set of Math functions, but once have the basics in place we can extend this to any kind of builtin/code stub/accessor. This adds a new flag --turbo_builtin_inlining (enabled by default), that forces the inliner to always inline builtins marked for inlining, but does not affect inlining of other functions (this is still controlled by the --turbo-inlining flag). BUG=v8:3952 LOG=n R=jarin@chromium.org Review URL: https://codereview.chromium.org/993473002 Cr-Commit-Position: refs/heads/master@{#27059}
-