- 17 Aug, 2017 3 commits
-
-
Ross McIlroy authored
This is a reland of 21da12a9 Original change's description: > [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile > > Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions > and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared) > function. The code in compiler.cc is refactored to use this function to compile > the SharedFunctionInfo when compiling a JSFunction. > > Also does some other cleanup: > - Removes CompileUnoptimizedFunction and inlines into new Compiler function > - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and > out of FinalizeUnoptimizedCompile. > > BUG=v8:6409 > > Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3 > Reviewed-on: https://chromium-review.googlesource.com/613760 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47394} TBR=yangguo@chromium.org TBR=jarin@chromium.org Bug: v8:6409 Change-Id: If2eae66a85f129e746a5ca5c04935540f3f86b04 Reviewed-on: https://chromium-review.googlesource.com/618886Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47399}
-
Ross McIlroy authored
This reverts commit 21da12a9. Reason for revert: Failing on arm64 simulator Original change's description: > [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile > > Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions > and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared) > function. The code in compiler.cc is refactored to use this function to compile > the SharedFunctionInfo when compiling a JSFunction. > > Also does some other cleanup: > - Removes CompileUnoptimizedFunction and inlines into new Compiler function > - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and > out of FinalizeUnoptimizedCompile. > > BUG=v8:6409 > > Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3 > Reviewed-on: https://chromium-review.googlesource.com/613760 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47394} TBR=rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org,leszeks@chromium.org Change-Id: I4ba63e82417a185f1528ff2633eb6c8872fbbfe5 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6409 Reviewed-on: https://chromium-review.googlesource.com/618687Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47397}
-
Ross McIlroy authored
Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared) function. The code in compiler.cc is refactored to use this function to compile the SharedFunctionInfo when compiling a JSFunction. Also does some other cleanup: - Removes CompileUnoptimizedFunction and inlines into new Compiler function - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and out of FinalizeUnoptimizedCompile. BUG=v8:6409 Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3 Reviewed-on: https://chromium-review.googlesource.com/613760 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47394}
-
- 13 Jul, 2017 1 commit
-
-
Adam Klein authored
The tail call implementation is hidden behind the --harmony-tailcalls flag, which is off-by-default (and has been unstaged since February). It is known to be broken in a variety of cases, including clusterfuzz security issues (see sample Chromium issues below). To avoid letting the implementation bitrot further on trunk, this patch removes it. Bug: v8:4698, chromium:636914, chromium:724746 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I9cb547101456a582374fdf7b1a3f044a9ef33e5c Reviewed-on: https://chromium-review.googlesource.com/569069 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46651}
-
- 11 Jul, 2017 1 commit
-
-
Alexandre Talon authored
Each reducer now has a virtual reducer_name function, returning its name (the name of the class containing this reducer). This gets displayed when using the --trace_turbo_reduction flag. Also when using this flags more messages are displayed. Actually when a node is replaced in-place (which is called an update of the node), other reducers can still update it right after the in-place replacement. When a node is really replaced (not in-place), then we stop trying to apply reducers to it before we propagate the reduction through the relevant nodes. Before a message got printed only for the last reduction it went through. So in case a node was reduced in-place several times in a row, only the last update was printed, or none at all if after being reduced in-place it got reduced by being replaced by another node: only the non-in-place replacement was showed. Now each time an in-place reduction is applied to a node, a message gets printed. Bug: Change-Id: Id0f816fecd44c01d0253966c6decc4861be0c2fa Reviewed-on: https://chromium-review.googlesource.com/563365Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Alexandre Talon <alexandret@google.com> Cr-Commit-Position: refs/heads/master@{#46552}
-
- 13 Feb, 2017 1 commit
-
-
Michael Starzinger authored
This adds support for deoptimizing into the JSConstructStub after the receiver instantiation but before the actual constructor invocation. Such a deoptimization point is needed for cases where instantiation might be observed (e.g. when new.target is a proxy) and hence might trigger a deopt. We use this new deoptimization point for the "after" frame-state the inliner attaches to {JSCreate} nodes being inserted when constructor calls are being inlined. R=jarin@chromium.org TEST=mjsunit/regress/regress-5638b BUG=v8:5638 Change-Id: I7c72c807ee8fb76d12e0e9ccab86d970ab1a0efd Reviewed-on: https://chromium-review.googlesource.com/440125Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43149}
-
- 07 Feb, 2017 1 commit
-
-
ishell@chromium.org authored
... and TypeFeedbackMetadata to FeedbackMetadata. BUG= Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c Reviewed-on: https://chromium-review.googlesource.com/439244 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#42999}
-
- 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}
-
- 14 Nov, 2016 1 commit
-
-
tebbi authored
This CL enables precise source positions for all V8 compilers. It merges compiler::SourcePosition and internal::SourcePosition to a single class used throughout the codebase. The new internal::SourcePosition instances store an id identifying an inlined function in addition to a script offset. SourcePosition::InliningId() refers to a the new table DeoptimizationInputData::InliningPositions(), which provides the following data for every inlining id: - The inlined SharedFunctionInfo as an offset into DeoptimizationInfo::LiteralArray - The SourcePosition of the inlining. Recursively, this yields the full inlining stack. Before the Code object is created, the same information can be found in CompilationInfo::inlined_functions(). If SourcePosition::InliningId() is SourcePosition::kNotInlined, it refers to the outer (non-inlined) function. So every SourcePosition has full information about its inlining stack, as long as the corresponding Code object is known. The internal represenation of a source position is a positive 64bit integer. All compilers create now appropriate source positions for inlined functions. In the case of Turbofan, this required using AstGraphBuilderWithPositions for inlined functions too. So this class is now moved to a header file. At the moment, the additional information in source positions is only used in --trace-deopt and --code-comments. The profiler needs to be updated, at the moment it gets the correct script offsets from the deopt info, but the wrong script id from the reconstructed deopt stack, which can lead to wrong outputs. This should be resolved by making the profiler use the new inlining information for deopts. I activated the inlined deoptimization tests in test-cpu-profiler.cc for Turbofan, changing them to a case where the deopt stack and the inlining position agree. It is currently still broken for other cases. The following additional changes were necessary: - The source position table (internal::SourcePositionTableBuilder etc.) supports now 64bit source positions. Encoding source positions in a single 64bit int together with the difference encoding in the source position table results in very little overhead for the inlining id, since only 12% of the source positions in Octane have a changed inlining id. - The class HPositionInfo was effectively dead code and is now removed. - SourcePosition has new printing and information facilities, including computing a full inlining stack. - I had to rename compiler/source-position.{h,cc} to compiler/compiler-source-position-table.{h,cc} to avoid clashes with the new src/source-position.cc file. - I wrote the new wrapper PodArray for ByteArray. It is a template working with any POD-type. This is used in DeoptimizationInputData::InliningPositions(). - I removed HInlinedFunctionInfo and HGraph::inlined_function_infos, because they were only used for the now obsolete Crankshaft inlining ids. - Crankshaft managed a list of inlined functions in Lithium: LChunk::inlined_functions. This is an analog structure to CompilationInfo::inlined_functions. So I removed LChunk::inlined_functions and made Crankshaft use CompilationInfo::inlined_functions instead, because this was necessary to register the offsets into the literal array in a uniform way. This is a safe change because LChunk::inlined_functions has no other uses and the functions in CompilationInfo::inlined_functions have a strictly longer lifespan, being created earlier (in Hydrogen already). BUG=v8:5432 Review-Url: https://codereview.chromium.org/2451853002 Cr-Commit-Position: refs/heads/master@{#40975}
-
- 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}
-
- 24 Aug, 2016 1 commit
-
-
bmeurer authored
Don't bother using %_IsJSReceiver, which immediately gets lowered to ObjectIsReceiver anyways (by the JSIntrinsicLowering), but requires some complicated rewiring of effect/control chains. R=mstarzinger@chromium.org BUG=chromium:640369 Review-Url: https://codereview.chromium.org/2271973003 Cr-Commit-Position: refs/heads/master@{#38864}
-
- 05 Aug, 2016 1 commit
-
-
bgeron authored
BUG= Review-Url: https://codereview.chromium.org/2211963002 Cr-Commit-Position: refs/heads/master@{#38363}
-
- 25 May, 2016 1 commit
-
-
bmeurer authored
Previously we first created a temporary graph for the inlinee and then copied over all the nodes to the actual graph. This however introduces unnecessary complexity, and we can instead just create the inlinee inside the target graph. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2006353003 Cr-Commit-Position: refs/heads/master@{#36508}
-
- 09 Mar, 2016 1 commit
-
-
ishell authored
In case when F was called with incompatible number of arguments (and therefore the arguments adator frame was created), F inlines a tail call of G which then deopts the deoptimizer should also remove the arguments adaptor frame for F. This CL adds required machinery to the deoptimizer. BUG=v8:4698 LOG=N Review URL: https://codereview.chromium.org/1768263004 Cr-Commit-Position: refs/heads/master@{#34610}
-
- 19 Nov, 2015 1 commit
-
-
mstarzinger authored
This adds an explicit parameter to the call descriptor having kind kJSCallFunction representing the new.target value. Note that for now this parameter is not yet passed in and hence cannot be used yet. Also contains some refactoring of how parameter index value are calculated, establishing Linkage as the central point for such index computations. This is a preparatory CL to allows us passing new.target in a register instead of via a side-channel through the construct stub frame. R=bmeurer@chromium.org BUG=v8:4544 LOG=n Review URL: https://codereview.chromium.org/1461973002 Cr-Commit-Position: refs/heads/master@{#32112}
-
- 12 Nov, 2015 1 commit
-
-
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}
-
- 22 Oct, 2015 1 commit
-
-
mstarzinger authored
This switches inlining back to use a temporary zone for parsing and analyzing inlinees. The inlinee graph however is still built in the same zone as the parent graph. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1422503005 Cr-Commit-Position: refs/heads/master@{#31471}
-
- 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}
-
- 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}
-
- 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}
-
- 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}
-
- 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}
-
- 21 May, 2015 1 commit
-
-
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}
-
- 20 May, 2015 1 commit
-
-
danno authored
Review URL: https://codereview.chromium.org/1140743004 Cr-Commit-Position: refs/heads/master@{#28510}
-
- 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}
-
- 20 Apr, 2015 1 commit
-
-
Ross McIlroy authored
R=jochen@chromium.org Review URL: https://codereview.chromium.org/1088993003 Cr-Commit-Position: refs/heads/master@{#27937}
-
- 09 Mar, 2015 1 commit
-
-
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}
-
- 20 Feb, 2015 3 commits
-
-
Benedikt Meurer authored
R=svenpanne@chromium.org Committed: https://crrev.com/5bbe693e4817011b6a496c638c9f09026fd3dac9 Cr-Commit-Position: refs/heads/master@{#26760} Review URL: https://codereview.chromium.org/944803002 Cr-Commit-Position: refs/heads/master@{#26767}
-
machenbach authored
Revert of [turbofan] Finally get rid of the generic algorithm. (patchset #2 id:20001 of https://codereview.chromium.org/944803002/) Reason for revert: Breaks dbg builds. Original issue's description: > [turbofan] Finally get rid of the generic algorithm. > > R=svenpanne@chromium.org > > Committed: https://crrev.com/5bbe693e4817011b6a496c638c9f09026fd3dac9 > Cr-Commit-Position: refs/heads/master@{#26760} TBR=svenpanne@chromium.org,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/941963003 Cr-Commit-Position: refs/heads/master@{#26763}
-
Benedikt Meurer authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/944803002 Cr-Commit-Position: refs/heads/master@{#26760}
-
- 17 Feb, 2015 1 commit
-
-
titzer authored
Next step: fix copying of the graph in inlining. R=bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/934723002 Cr-Commit-Position: refs/heads/master@{#26682}
-
- 09 Feb, 2015 1 commit
-
-
mstarzinger authored
R=bmeurer@chromium.org TEST=presubmit Review URL: https://codereview.chromium.org/905293002 Cr-Commit-Position: refs/heads/master@{#26525}
-
- 26 Jan, 2015 1 commit
-
-
bmeurer authored
The lowering of intrinsics is therefore now decoupled from the general inlining logic. TEST=cctest,unittests R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/872363002 Cr-Commit-Position: refs/heads/master@{#26263}
-
- 21 Oct, 2014 1 commit
-
-
dcarney@chromium.org authored
R=jarin@chromium.org, bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/663333003 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24779 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 Oct, 2014 1 commit
-
-
sigurds@chromium.org authored
This issue is for discussion on how to proceed. I think the implementation of ValueOf shows that directly creating the IR does not scale. BUG= R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/612043003 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24719 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Sep, 2014 1 commit
-
-
sigurds@chromium.org authored
Original: https://codereview.chromium.org/573703002/ Reland Fixes: - Add deopt framestate to CollectStackTrace runtime call R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/544953006 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24023 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 17 Sep, 2014 2 commits
-
-
sigurds@chromium.org authored
This reverts commit r24008. TBR=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/581673002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24010 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
sigurds@chromium.org authored
- Lazy deopt from inlined calls - Lazy deopt from inlined calls with parameter mismatch R=jarin@chromium.org, mstarzinger@chromium.org, mstarzinger@chromium Review URL: https://codereview.chromium.org/573703002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24008 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 Aug, 2014 1 commit
-
-
sigurds@chromium.org authored
Reland Fixes: * Remove usage of C++11 vector members. * Guard tests by V8_TURBO_TARGET. Changes: * Make context specialization clean up after itself. * Add UpdateToAndIncrement to Inputs::iterator. Uses:iterator already provides this member function. * Allow next node id in graph to be set. R=titzer@chromium.org, mstarzinger@chromium.org Review URL: https://codereview.chromium.org/484083003 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23231 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-