[llvm-dev] Debuggability of -O1 level

Francois Pichet via llvm-dev llvm-dev at lists.llvm.org
Mon Jan 29 12:45:01 PST 2018


My experience is that just running mem2reg (while disabling virtually all
other passes ) in O1 will substantially improve debuggability while giving
acceptable performance.

On Mon, Jan 29, 2018 at 11:39 AM, via llvm-dev <llvm-dev at lists.llvm.org>
wrote:

> (Remembering to +llvm-dev this time…)
>
>
>
> 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.
>
> 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.
>
> 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.
>
>
>
> 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.
>
>
>
> 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!
>
> --paulr
>
>
>
>
>
>
>
> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *Son
> Tuan VU via llvm-dev
> *Sent:* Monday, January 29, 2018 7:35 AM
> *To:* llvm-dev at lists.llvm.org
> *Subject:* [llvm-dev] Debuggability of -O1 level
>
>
>
> Hello all,
>
>
>
> I've found an old post (November 2016) http://lists.llvm.org/
> pipermail/llvm-dev/2016-November/107006.html 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/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?
>
>
>
> Thank you for your help,
>
>
> Son Tuan Vu
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180129/6a0ad436/attachment.html>


More information about the llvm-dev mailing list