[GSoC 2018] Improving debugging of optimized code

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.

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.

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

Hi Anast,

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.

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
[2] http://www.llvm.org/docs/ProgrammersManual.html
[3] https://llvm.org/docs/Contributing.html