similar to: [DebugInfo] RFC: Introduce LLVM DI Checker utility

Hi Vedant, Thanks a lot for your comments! >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

Hi David, Thanks for your comments! I just want to add that I think it would neat if the entry values could map into multi-location dbg.values and DBG_VALUEs that are being proposed on this list. For example, if we have: int local = param1 + param2 + 123; I think it would be good if we would be able to to represent the four different permutations of the values of the parameters being

Hi all, The debug entry values feature introduces new DWARF symbols (tags, attributes, operations) on caller (call site) as well as on callee side; and the intention is to improve debugging user experience by using the functionality (especially in “optimized” code by turning “<optimized_out>” values into real values). The call site information includes info about call itself (described with

Hi Djordje, On Wed, Sep 9, 2020 at 7:52 AM Djordje Todorovic <Djordje.Todorovic at syrmia.com> wrote: > Using entry-values ('callee' side of the feature) is not enough in any case. It is always connected to the call-site-param (function arguments but we call it call-site-params; 'caller' side of the feature) debug info. I believe that there are call-site-params that could

Hi Djordje, [Late reply as I was away, alas], For the example in https://reviews.llvm.org/D85012 , I'm not sure that just using an entry value is correct. The reason why the dbg.values for arguments are set to undef is not because the value can't be described, it's because deadargelim changes all the call sites to pass in 'undef', which I believe makes the value unrecoverable

Hi, I've prototyped a pair of passes which 1) add synthetic debug info to a Module and 2) determine how much of that info is lost. The idea is to make it easier to write targeted test cases for debug info preservation. For example, here is a quick way to test that Mem2Reg doesn't drop debug info from one test input: > ; RUN: opt < %s -debugify -mem2reg -check-debugify -S

Hello all, I came across the code of Verifier, and see that it doesn't modify the IR at all. Why it is not considered as an analysis pass? Actually, this will have impact on debugify-each and print-before/after-all: we are not supposed to print/debugify Verifier pass, but since Verifier is declared as a transformation (well, a non-analysis) pass, we actually do print/debugify it. Thanks for

Thanks for the suggestions Vedant. Synthetic debug info is an interesting idea that sounds worthwhile. Could this be implemented as a “wrapper” pass that automatically decorates debug info before and after a specific pass run in opt (or pipeline of passes)? It might be useful to be able to easily enable this for a wide range of tests without having to manually modify each run line, perhaps as an

Hi, I'm not sure which passes exactly drop debug info, but it's likely that most of them do. If you're interested in working on this problem, I suggest experimenting with the debugify utility in opt. This tool can be used to identify passes which drop debug info and to generate targeted/reduced test cases for specific problems. To use it, you can add the '-enable-debugify'

My experience is that just running mem2reg (while disabling virtually all other passes ) in O1 will substantially improve debuggability while giving acceptable performance. On Mon, Jan 29, 2018 at 11:39 AM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > (Remembering to +llvm-dev this time…) > > > > There has been some progress in the direction of improving debuggability

> On Nov 13, 2017, at 11:53 AM, Vedant Kumar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Amara, > >> On Nov 10, 2017, at 9:12 AM, Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi everyone, >> >> This RFC concerns the design and architecture of a generic machine

Hello Paul, François and Vedant, Thank you all for your answers. And sorry for this late reply. I wanted to dig more into the LLVM source code to get a better understanding of the debug part of it before replying/asking more questions. I have came across this https://llvm.org/docs/SourceLevelDebugging.html#debugging-optimized-code which stated that "*Basically, the debug information allows

Hello Djordje, Vedant, Thanks a lot for sharing information. I have a doubt, please consider the following simple test case- #include <iostream> int func(int* ptr){ std::cout << *ptr; return *ptr + 5; } int main(int argc, char** argv){ int a = 4; int* ptr_a = &a; int b = func(ptr_a); return 0; } commandline used -- bash$ clang++

Currently there is a series of patches undergoing review[0] that seek to enable the use of multiple IR/MIR values when describing a source variable's location. The current plan for the MIR is to add a new instruction, DBG_VALUE_LIST, that supports this functionality by having a variable number of operands. It may be better however to simply replace the existing DBG_VALUE behaviour entirely

Hi Vedant, Thank you for your reply. I think I can make this debugify-each mode, but I guess this is reserved for your GSoC project ? However, if I understand correctly, we do not want to take the output of the first check-debugify (I mean the .ll file with potentially all the WARNINGs and ERRORs after the first pass) as input for the second debugify. What we need is to take the fresh output of

> On Mar 16, 2018, at 2:30 PM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hi Vedant, > > Thank you for your reply. I think I can make this debugify-each mode, but I guess this is reserved for your GSoC project ? No, there's no reserved work. If you'd like to work on this I encourage you to do so. There's plenty of other work slated for the GSoC project.

Mhm I see now, thanks for your explanation! Son Tuan Vu On Fri, Mar 16, 2018 at 10:58 PM, Vedant Kumar <vsk at apple.com> wrote: > > On Mar 16, 2018, at 2:30 PM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hi Vedant, > > Thank you for your reply. I think I can make this debugify-each mode, but > I guess this is reserved for your GSoC project ? > >

At least one proprietary linker put a lot of effort into deduplicating and rewriting debug information. This took up the majority of the link time despite serious engineering time on performance optimisation. For example, some sections were written from scratch by the linker because that proved faster than parsing the input. Teaching LLD to dedup DWARF should be expected to dramatically slow it

Hi Vedant, hi all, My goal is to measure debug info loss of *each* optimization pass in LLVM. I am trying to create a debugify-each mode in opt, inspired by verify-each mode which is supposed to already work. However, if I understand correctly, the verify-each mode (triggered by -verify-each option in opt) only works when we provide a pass list or a pass pipeline. Is this intended? I mean, why

Hello, > On Apr 26, 2018, at 6:44 AM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hi Vedant, > > I have tried to implement the fix you proposed, but it didn't work as expected. I created a new Module Pass Manager (not Function Pass Manager) and override the add() method like this: > > class DebugifyEachPassManager : public legacy::PassManager { >