[llvm-dev] [DebugInfo] RFC: Introduce LLVM DI Checker utility

[Vedant Kumar via llvm-dev]

Hey Djordje,

It looks like a lot of the new infrastructure introduced here <https://github.com/djolertrk/llvm-di-checker/commit/9d26ac2557c584f6cf82ac5535fc47f8bd267a27> consists of logic copied from the debugify implementation. Why is introducing a new pair of passes better than extending the ones we have? The core infrastructure needed to track location loss for real (non-synthetic) source variables is is in place already.

Stepping back a bit, I’m also surprised by the decision to move away from synthetic testing when there’s still so much low-hanging fruit to pick using that technique. The example from https://reviews.llvm.org/D81939 <https://reviews.llvm.org/D81939> illustrates this perfectly: in this case it’s not necessary to invent a new testing technique to uncover the bug, because simply running `./bin/llvm-lit -Dopt="opt -debugify-each" test/Transforms/DeadArgElim` finds the same issue.

In D81939, you discuss finding the new tool useful when responding to bug reports about optimized-out variables or missing locations. We sorely do need something better than -opt-bisect-limit, but why not start with something simple? -check-debugify already knows how to report when & where a location is dropped, it would be simple to teach it to emit a report when a variable is fully optimized-out.


> On Jun 17, 2020, at 2:10 AM, Djordje <djordje.todorovic at syrmia.com> wrote:
> 
> I am sharing the proposal [0] which gives a brief introduction for the implementation of the LLVM DI Checker utility. On a very high level, it is a pair of LLVM (IR) Passes that check the preservation of the original debug info in the optimizations. There are options controlling the passes, that could be invoked from ``clang`` as well as from ``opt`` level.
> 
> By testing the utility on the GDB 7.11 project (using it as a testbed), it has found a certain number of potential issues regarding the DILocations (using it on LLVM project build itself, it has found one bug regarding DISubprogram metadata). Please take a look into the final report (on the GDB 7.11 testbed) generated from the script that collects the data at [1]. By looking at these data, it looks that the utility like this could be useful when trying to detect the real issues related to debug info production by the compiler.

Thanks for sharing these results. The data here is older (from the 2018 debug info BoF) and from a different project (sqlite3), but we saw some similar patterns: https://llvm.org/devmtg/2018-10/slides/Prantl-Kumar-debug-info-bof-2018.pdf <https://llvm.org/devmtg/2018-10/slides/Prantl-Kumar-debug-info-bof-2018.pdf>

best
vedant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200617/e2e15fbf/attachment.html>