[llvm-dev] GSoC2019 - DebugInfo should not effect codegen

[Davide Italiano via llvm-dev]

On Wed, Mar 6, 2019 at 2:43 AM preejackie via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hi all,
>
> I'm interested in participating this GSoC with llvm. I would like to contribute on the project idea "DebugInfo should not effect codegen". Over the past few days, I have gone through some bugs reported at bugzilla that cause different codegen behavior of same program.
>
> Bugs I have been looking at are:
>
>     1. [fuzzDI] -O1 + `-g` cause the generated code to change.
>
>     2. Make llvm passes debug info invariant
>
>     3. LoopVectorize: different IR generation when debug info is present
>
>     4. InstCombine: test/Transforms/InstCombine/call-guard.ll looks different with debug info present
>
> I'm currently working on finding the root cause of these issues. I have some questions regarding the scope of the project.
>
>    1) Whether the scope is finding as many issue as possible and fix it or whether I can design some protocol like stuff which impose constrains on optimization passes to interact with debug
>       info metadata, by this way we can far more generalize this idea and make a clear distinction between opt passes which operate on llvm ir & debug metadata.
>
>

I don't want to discourage you from trying but, having spent a fair
amount of time looking at these issues and reporting bugs I would like
to point out that:
1) There's probably enough work for a summer (or a year, or more) just
fixing the existing issues. You don't need to have anything extremely
sophisticated. After you're done with the bugs reported you can use
`-debugify` as Vedant did in some PRs he reported. Or, in alternative,
you can just run `csmith` or any C/C++ code generator out there and
compare the output with and without `-g`. Mind you, the number of
reports might be a overwhelming :)
2) "designing a protocol like stuff to impose constraints on
optimizations" is definitely a laudable goal, but it's really hard to
achieve in practice. We have a verifier to make sure debug
informations don't mess with debug informations, but making sure that
DI is correct is a much harder problem to solve. Also, if we decide to
go that route, it might end up requiring substantial surgery at the IR
level, which might not be feasible in a single summer.

Best,

-- 
Davide

"A mathematical theory is not to be considered complete until you have
made it so clear that you can explain it to the first man whom you
meet on the street." (D. Hilbert)