<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hey Djordje,<div class=""><br class=""></div><div class="">It looks like a lot of the new infrastructure introduced <a href="https://github.com/djolertrk/llvm-di-checker/commit/9d26ac2557c584f6cf82ac5535fc47f8bd267a27" class="">here</a> 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.</div><div class=""><br class=""></div><div class="">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 <a href="https://reviews.llvm.org/D81939" class="">https://reviews.llvm.org/D81939</a> 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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 17, 2020, at 2:10 AM, Djordje <<a href="mailto:djordje.todorovic@syrmia.com" class="">djordje.todorovic@syrmia.com</a>> wrote:</div><div class=""><div class=""><br class="">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.<br class=""><br class="">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.<br class=""></div></div></blockquote><div><br class=""></div><div>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: <a href="https://llvm.org/devmtg/2018-10/slides/Prantl-Kumar-debug-info-bof-2018.pdf" class="">https://llvm.org/devmtg/2018-10/slides/Prantl-Kumar-debug-info-bof-2018.pdf</a></div><div><br class=""></div><div>best</div><div>vedant</div></div></div></body></html>