[llvm-dev] [GSoC 2018] Improving debugging of optimized code

Vedant Kumar via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 26 15:12:06 PST 2018


Hi Anast,


> On Feb 26, 2018, at 2:32 PM, Anast Gramm via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hello,
> 
> I'm an undergraduate student in the CS department
> of Aristotle University of Thessaloniki (AUTh).
> 
> Last year I successfully completed GSoC with Mixxx [1] and this year I
> would like to work on LLVM.
> 
> I am interested in "Improving debugging of optimized code" [2].
> 
> I have gone through the kaleidoscope tutorial and I've set up a basic
> dev environment for LLVM and clang. I've also set up a bugzilla account.
> I'd like to start working on some bugs to get acquainted with the code
> base, but bugzilla is pretty overwhelming for a newcomer like me. If you
> could suggest me some bugs (not necessarily related to the
> aforementioned project) I would appreciate it.

It's great that you've built up some familiarity with the codebase.

I think it can be useful to start out by fixing incorrect comments or code style issues. This is a nice way to learn about the coding guidelines [1][2] and the process for landing changes [3].

If you want to dig into something debug info related, consider https://bugs.llvm.org/show_bug.cgi?id=34562 <https://bugs.llvm.org/show_bug.cgi?id=34562>.


> I would also like some more information about the first goal of the
> project, like an outline of the procedure you have in mind for gathering
> debug loss metrics.

We can measure debug info loss by counting the number of line locations and debug values that are lost after each pass. I think introducing a debugify-each mode to opt would be a good way to do this. The concept is the same as the verify-each mode: we'd run debugify, run a pass, run check-debugify, store the resulting loss statistics, and then strip the debug info. This process would be repeated for each pass in the pipeline.

A debugify-each mode would be the first step towards charting the amount of debug info loss in each pass. The next step is to run opt -O{1,2,3} + debugify-each on small sample of bitcode inputs. Once we start collecting loss statistics, we can do a better job of prioritizing bug fixes. For example, if we find large amounts of debug info loss early in the pipeline, we could prioritize fixing that. Having this information will also make it easier to track progress.

Let me know if you have any questions.

best,
vedant

[1] https://llvm.org/docs/CodingStandards.html <https://llvm.org/docs/CodingStandards.html>
[2] http://www.llvm.org/docs/ProgrammersManual.html <http://www.llvm.org/docs/ProgrammersManual.html>
[3] https://llvm.org/docs/Contributing.html <https://llvm.org/docs/Contributing.html>


> I'll be in llvm's IRC with the nick "gramanas" in case you want to PM me.
> 
> Best regards,
> Anastasis
> 
> [1] https://mixxx.org/wiki/doku.php/crate_enhancements
> 
> [2] https://llvm.org/OpenProjects.html#llvm_optimized_debugging
> _______________________________________________
> 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/20180226/29748c51/attachment.html>


More information about the llvm-dev mailing list