<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 5, 2018, at 2:39 AM, Son Tuan VU <<a href="mailto:sontuan.vu119@gmail.com" class="">sontuan.vu119@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hello Paul, François and Vedant,<div class=""><br class=""></div><div class="">Thank you all for your answers. And sorry for this late reply. I wanted to dig more into the LLVM source code to get a better understanding of the debug part of it before replying/asking more questions.</div><div class=""><br class=""></div><div class="">I have came across this <a href="https://llvm.org/docs/SourceLevelDebugging.html#debugging-optimized-code" class="">https://llvm.org/docs/SourceLevelDebugging.html#debugging-optimized-code</a> which stated that </div><div class="">"<i class="">Basically, the debug information allows you to compile a program with <b class="">“-O0 -g”</b> and get full debug information, allowing you to arbitrarily modify the program as it executes from a debugger. Compiling a program with <b class="">“-O3 -g”</b> gives you full debug information that is always available and accurate for reading (e.g., you get accurate stack traces despite tail call elimination and inlining), but you might lose the ability to modify the program and call functions which were optimized out of the program, or inlined away completely.</i>"</div><div class=""><br class=""></div><div class="">Does it really mean that I can find out the location expressions of *every* variable / function in the source program (of course if it is not removed by the compiler), even at "<b class="">-O3 -g</b>"?</div></div></div></blockquote><div><blockquote type="cite" class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">@Vedant: I have tried your debugify utility, thanks for the great tool! However, currently, debugify assumes the not-so-exact line number for the debugging entities (code statements, variables, functions). Is it expected?</div></div></div></blockquote><div><br class=""></div><div>Debugify numbers each instruction in a Module from 1..N in the order they are visited. The idea is that when a location is dropped, it's simple to find the hole in the range. Could you clarify what you meant by non-so-exact line numbers?</div><div><br class=""></div><div>best,</div><div>vedant</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">@Paul: Thanks a lot for your very informative summary. I wonder how I can help with the project though, do you have any concrete task that needs to be implemented, or do you mean a GSoC project?</div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div></div><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class="">Son Tuan Vu</div></div></div>
<br class=""><div class="gmail_quote">On Mon, Jan 29, 2018 at 11:08 PM, Vedant Kumar <span dir="ltr" class=""><<a href="mailto:vsk@apple.com" target="_blank" class="">vsk@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br class="">
<br class="">
I'm not sure which passes exactly drop debug info, but it's likely that most of them do. If you're interested in working on this problem, I suggest experimenting with the debugify utility in opt. This tool can be used to identify passes which drop debug info and to generate targeted/reduced test cases for specific problems. To use it, you can add the '-enable-debugify' flag to opt's list of arguments. E.g:<br class="">
<br class="">
opt < ~/src/llvm/test/Transforms/<wbr class="">InstCombine/icmp-div-constant.<wbr class="">ll -instcombine -S -enable-debugify<br class="">
<br class="">
If you're interested in collecting statistics on which passes drop the most debug info, you could teach the debugify pass to log the number of dropped variables/locations per test, and run the test suite with `llvm-lit -Dopt="opt -enable-debugify"`. It would be really useful to have that information.<br class="">
<br class="">
best,<br class="">
vedant<br class="">
<div class="HOEnZb"><div class="h5"><br class="">
<br class="">
> On Jan 29, 2018, at 12:45 PM, Francois Pichet via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class="">
><br class="">
> My experience is that just running mem2reg (while disabling virtually all other passes ) in O1 will substantially improve debuggability while giving acceptable performance.<br class="">
><br class="">
> On Mon, Jan 29, 2018 at 11:39 AM, via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class="">
> (Remembering to +llvm-dev this time…)<br class="">
><br class="">
><br class="">
><br class="">
> There has been some progress in the direction of improving debuggability of optimized code, in the past year. There have been a number of patches to improve tracking of debug info in various passes, and some more general improvements such as work on the LiveDebugValues pass. I don't think anyone has done a specific analysis to identify passes that lose debug info.<br class="">
><br class="">
> However, various people/teams have an interest in making improvements here, and continue to devote some resources to the longer term project. For example there is the Extend Lifetimes work described by Wolfgang Pieb at the 2017 LLVM Developers Meeting. We have also looked into how the instruction scheduler might be interfering with the debugging experience.<br class="">
><br class="">
> Part of the problem is that the "debugging experience" is a fairly qualitative thing, but in order to attack the problem properly we need a more analytic quantitative measure of how we are doing, which will hopefully lead us to areas where things can improve. See for example the DIVA tool, described at the 2017 EuroLLVM. Sony also has some other internal tools, which I hope we can describe at future meetings and make available to the community.<br class="">
><br class="">
><br class="">
><br class="">
> In short, there is continued interest and (more importantly) effort towards both –Og in particular and improving the debugging of optimized code in general. I am hopeful that we can eventually reach a point where we can define an –Og that is as debuggable as –O0 while still having distinctly better runtime performance. Whether –Og becomes its own thing, or ends up as a redefinition of –O1, remains to be decided.<br class="">
><br class="">
><br class="">
><br class="">
> Thanks for your interest, and giving me a reason to write up this little summary. And if you are motivated to help with the project, that's great!<br class="">
><br class="">
> --paulr<br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
> From: llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" class="">llvm-dev-bounces@<wbr class="">lists.llvm.org</a>] On Behalf Of Son Tuan VU via llvm-dev<br class="">
> Sent: Monday, January 29, 2018 7:35 AM<br class="">
> To: <a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">
> Subject: [llvm-dev] Debuggability of -O1 level<br class="">
><br class="">
><br class="">
><br class="">
> Hello all,<br class="">
><br class="">
><br class="">
><br class="">
> I've found an old post (November 2016) <a href="http://lists.llvm.org/pipermail/llvm-dev/2016-November/107006.html" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/<wbr class="">pipermail/llvm-dev/2016-<wbr class="">November/107006.html</a> which discussed debug information for optimized code. At the end of that discussion, Adrian broached the interest in making -O1 only enable optimizations. I see in the code (clang/lib/Frontend/<wbr class="">CompilerInvocation.cpp, in function getOptimizationLevel) that -Og option is equivalent to -O1. Does this mean any progress on making -O1 the GCC's -Og? If not, would someone kindly tell me what is holding the debuggability at -O1 back? Which optimization passes are removing our debug info at this -O1 level?<br class="">
><br class="">
><br class="">
><br class="">
> Thank you for your help,<br class="">
><br class="">
><br class="">
><br class="">
> Son Tuan Vu<br class="">
><br class="">
><br class="">
> ______________________________<wbr class="">_________________<br class="">
> LLVM Developers mailing list<br class="">
> <a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
><br class="">
><br class="">
> ______________________________<wbr class="">_________________<br class="">
> LLVM Developers mailing list<br class="">
> <a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
<br class="">
</div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>