- 21 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 TBR=bmeurer@chromium.org,neis@chromium.org NOPRESUBMIT=true Change-Id: Ia1e49d1aac09c4ff9e05d58fab9d08dd71198878 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621931Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61682}
-
- 22 Jan, 2019 1 commit
-
-
Mike Stanton authored
Now, the CodeAssembler can annotate Nodes with SourcePositions. SourcePositions themselves get a new mode "external," in which they get a file_id, line and column. The file_id is currently maintained in the isolate, mapping to strings for filenames. Additionally, inlining information is ignored at this point, but in the long run I'd like to recognize calls to different CSA functions as manual inlinings. At this point, if you want to see the results in tools like GDB, you'll need to build without clang, and use the GCC toolchain. GN flag is_clang=false will do the trick. Bug: v8:8418 Change-Id: I123cdc041612285fa7d0ba532a625bceeda5d338 Reviewed-on: https://chromium-review.googlesource.com/c/1322954 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#59009}
-
- 04 Jan, 2019 1 commit
-
-
Peter Marshall authored
Currently in both kCallerLineNumbers and kLeafNodeLineNumbers modes, we correctly capture inline stacks. In leaf number mode, this is simple as we simply add the path onto the existing tree. For caller line numbers mode this is more complex, because each path through various inlined function should be represented in the tree, even when there are multiple callsites to the same function inlined. Currently we don't correctly show line numbers for inlined functions. We do actually have this information though, which is generated by turbofan and stored in the source_position_table data structure on the code object. This also changes the behavior of the SourcePositionTable class. A problem we uncovered is that the PC that the sampler provides for every frame except the leaf is the return address of the calling frame. This address is *after* the call has already happened. It can be attributed to the next line of the function, rather than the calling line, which is wrong. We fix that here by using lower_bound in GetSourceLineNumber. The same problem happens in GetInlineStack - the PC of the caller is actually the instruction after the call. The information turbofan generates assumes that the instruction after the call is not part of the call (fair enough). To fix this we do the same thing as above - use lower_bound and then iterate back by one. TBR=alph@chromium.org Bug: v8:8575, v8:8606 Change-Id: Idc4bd4bdc8fb70b70ecc1a77a1e3744a86f83483 Reviewed-on: https://chromium-review.googlesource.com/c/1374290 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#58545}
-
- 28 Nov, 2018 1 commit
-
-
Jakob Kummerow authored
Bug: v8:3770 Change-Id: If405611d359d29ae1958beebd9202e068434a621 Reviewed-on: https://chromium-review.googlesource.com/c/1350286 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57918}
-
- 12 Nov, 2018 1 commit
-
-
Jakob Kummerow authored
Bug: v8:3770 Change-Id: I413ce57f7fa91cef2445995ca22650477f92b0df Reviewed-on: https://chromium-review.googlesource.com/c/1321892Reviewed-by: Dan Elphick <delphick@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#57445}
-
- 16 May, 2018 1 commit
-
-
Sigurd Schneider authored
Bug: v8:7327 Change-Id: Ic00291784e982632b15cd83059397b6e9e4c4f79 Reviewed-on: https://chromium-review.googlesource.com/1057487 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53211}
-
- 09 May, 2018 2 commits
-
-
Clemens Hammacher authored
This is a reland of e084eea6. Undefined behavious was fixed in https://crrev.com/c/1051235. Original change's description: > Fix SourcePositionInfo for wasm > > In wasm we often don't have a SharedFunctionInfo associated with a > compilation job, so we can't get a Script. Just print "unknown" in > these cases (instead of crashing). > > R=titzer@chromium.org > CC=herhut@chromium.org > > Bug: chromium:840757, v8:7738 > Change-Id: I850c6adfd9e07c9a0f6dd018f1a9314feb89d887 > Reviewed-on: https://chromium-review.googlesource.com/1049632 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Ben Titzer <titzer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#53080} TBR=titzer@chromium.org Bug: chromium:840757, v8:7738 Change-Id: If04040a33766955cfed78e7c27226dd04c3f9b9f Reviewed-on: https://chromium-review.googlesource.com/1051266Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53111}
-
Michael Achenbach authored
This reverts commit e084eea6. Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20UBSanVptr/builds/3163 Original change's description: > Fix SourcePositionInfo for wasm > > In wasm we often don't have a SharedFunctionInfo associated with a > compilation job, so we can't get a Script. Just print "unknown" in > these cases (instead of crashing). > > R=titzer@chromium.org > CC=herhut@chromium.org > > Bug: chromium:840757, v8:7738 > Change-Id: I850c6adfd9e07c9a0f6dd018f1a9314feb89d887 > Reviewed-on: https://chromium-review.googlesource.com/1049632 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Ben Titzer <titzer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#53080} TBR=titzer@chromium.org,clemensh@chromium.org Change-Id: Ib2020ea3f2b778df9fe50ccbe803938f2f4fd709 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:840757, v8:7738 Reviewed-on: https://chromium-review.googlesource.com/1051265Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#53082}
-
- 08 May, 2018 1 commit
-
-
Clemens Hammacher authored
In wasm we often don't have a SharedFunctionInfo associated with a compilation job, so we can't get a Script. Just print "unknown" in these cases (instead of crashing). R=titzer@chromium.org CC=herhut@chromium.org Bug: chromium:840757, v8:7738 Change-Id: I850c6adfd9e07c9a0f6dd018f1a9314feb89d887 Reviewed-on: https://chromium-review.googlesource.com/1049632 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53080}
-
- 04 Apr, 2018 1 commit
-
-
Ross McIlroy authored
With the Ignition + Turbofan pipeline there is very little overlap between the data needed for unoptimized compilation and optimized compilation. As a result, it is cleaner to split up the CompilationInfo into UnoptimizedCompilationInfo and OptimizedCompilationInfo. Doing so also necessitate splitting up CompilationJob into UnoptimizedCompilationJob and OptimizedCompilationJob - again there is not much overlap so this seems cleaner. Change-Id: I1056ad520937b7f8582e4fc3ca8f4910742de30a Reviewed-on: https://chromium-review.googlesource.com/995895 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52369}
-
- 18 Oct, 2017 2 commits
-
-
Michael Starzinger authored
Now that {DeoptimizationOutputData} does not exists anymore we can rename {DeoptimizationInputData} to just {DeoptimizationData}. R=jarin@chromium.org Change-Id: Ib67967539d33714cc15e5d5b6dde522a9ede64b2 Reviewed-on: https://chromium-review.googlesource.com/725349Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48684}
-
Clemens Hammacher authored
This CL fixes all occurences that don't require special OWNER reviews, or can be reviewed by Michi. After this one, we should be able to reenable the readability/check cpplint check. R=mstarzinger@chromium.org Bug: v8:6837, v8:6921 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Ic81d68d5534eaa795b7197fed5c41ed158361d62 Reviewed-on: https://chromium-review.googlesource.com/721120 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48670}
-
- 14 Dec, 2016 1 commit
-
-
tebbi authored
R=danno@chromium.org BUG= Review-Url: https://codereview.chromium.org/2568303008 Cr-Commit-Position: refs/heads/master@{#41693}
-
- 22 Nov, 2016 1 commit
-
-
tebbi authored
The new SourcePosition class allows for precise tracking of source positions including the stack of inlinings. This CL makes the cpu profiler use this new information. Before, the cpu profiler used the deoptimization data to reconstruct the inlining stack. However, optimizing compilers (especially Turbofan) can hoist out checks such that the inlining stack of the deopt reason and the inlining stack of the position the deoptimizer jumps to can be different (the old cpu profiler tests and the ones introduced in this cl produce such situations for turbofan). In this case, relying on the deoptimization info produces paradoxical results, where the reported position is before the function responsible is called. Even worse, https://codereview.chromium.org/2451853002/ combines the precise position with the wrong inlining stack from the deopt info, leading to completely wrong results. Other changes in this CL: - DeoptInlinedFrame is no longer needed, because we can compute the correct inlining stack up front. - I changed the cpu profiler tests back to test situations where deopt checks are hoisted out in Turbofan and made them robust enough to handle the differences between Crankshaft and Turbofan. - I reversed the order of SourcePosition::InliningStack to make it match the cpu profiler convention. - I removed CodeDeoptEvent::position, as it is no longer used. R=alph@chromium.org BUG=v8:5432 Review-Url: https://codereview.chromium.org/2503393002 Cr-Commit-Position: refs/heads/master@{#41168}
-
- 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}
-
- 30 Jun, 2016 1 commit
-
-
yangguo authored
R=mstarzinger@chromium.org BUG=v8:5117 Review-Url: https://codereview.chromium.org/2109773004 Cr-Commit-Position: refs/heads/master@{#37426}
-
- 15 Jan, 2016 1 commit
-
-
mstarzinger authored
This splits out the SourcePosition class into a separate header file. Reason for this refactoring is that said class is mostly used by the Crankshaft compiler and not needed for all compilers. Also having the assembler depend on the class creates a dependency cycle. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1581083009 Cr-Commit-Position: refs/heads/master@{#33325}
-