search for: debugify

> 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. That said, let's make sure to sync up on the mailing lists to make sure wo...

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 i...

...w, 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 ? > > > 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. > That said, let's make sure to sync up on the...

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 do not let people verify eac...

...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 { > public: > void add(Pass *P) override { > PassManager::add(createDebugifyPass()); > PassManager::add(P); > PassManager::add(createCheckDebugifyPass()); > } > > bool run(Module &M) { >...

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 { public: void add(Pass *P) override { PassManager::add(createDebugifyPass()); PassManager::add(P); PassManager::add(createCheckDebugifyPass()); } bool run(Module &M) { return PassManager::run(M); } }; However, we ca...

Hello, @Anastasis: what do you think about this? Do you mind if I implement the debugify-each mode and refactor the code to have DebugifyFunctionPass and DebugifyLoopPass? I am sorry if it bothers you, I should have done this earlier, so you could focus on fixing the optimization passes. FYI, my debugify-each is quite ready, I am having Debugify and CheckDebugify before and after each...

Hi Son Tuan, Thanks for taking a look at this :). Responses inline -- > On Mar 14, 2018, at 8:11 AM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > 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. + Anastasis, who's interested in working on this as well. There's definitely enough work to go around: once we can measure debug info loss after each pass, we'll need a testing harness. > However, if...

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 location loss for real (non-synthetic) source variables is is in place already. Since it is a proposal, I thought it'd easier to understand the idea if I...

Hi, 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

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 your help! Son Tuan Vu -------------- next part -------------- An HTML attachment was...

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' flag to opt's list of arguments. E.g: opt < ~/src/llvm/test/Transforms/InstCombine/icmp-d...

...ch were optimized out of the program, or inlined away completely.*" Does it really mean that I can find out the location expressions of *every* variable / function in the source program (of course if it is not removed by the compiler), even at "*-O3 -g*"? @Vedant: I have tried your debugify utility, thanks for the great tool! However, currently, debugify assumes the not-so-exact line number for the debugging entities (code statements, variables, functions). Is it expected? @Paul: Thanks a lot for your very informative summary. I wonder how I can help with the project though, do you h...

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

...d 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 2>&1 | FileCheck %s > ; CHECK: CheckDebugify: PASS So far, I've used this utility to identify problems in LSR and instcombine (haven't gotten around to filing bugs yet). There's some more discussion about this utility on the thread "RFC: [Glob...

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.

...t; Introduction > ============ > > `SROA' is an early stage pass running at the very beginning of the > pipeline in `-O{1,2,3}'. Greg Bedwell's report from his DExTer tool > shows SROA on function as one of the major culprits of Debug Info > loss. > > With debugify-each partially done I tried testing this on the > amalgamated sqlite source. > > The steps are as follows: > ,---- > | # generate IR file without debug info and optnone > | clang -O0 -Xclang -disable-O0-optnone -S -emit-llvm sqlite3.c -o sqlite > | > | # run opt &gt...

+ Vedant: what do you think about the last point, since Debugify is also related? Son Tuan Vu On Thu, Apr 19, 2018 at 6:14 PM, Philip Pfaffe <philip.pfaffe at gmail.com> wrote: > Hi Son, > > PassManagerBuilder is used to populate legacy PassManagers. That role is > taken over by PassBuilder for new-PM passes. > > Cheers, > Philip &...

...0:19 PM, Vedant Kumar <vsk at apple.com> wrote: > Hi, > > + Chandler, who has a lot more experience with our pass managers. > > On Apr 20, 2018, at 12:56 PM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > + Vedant: what do you think about the last point, since Debugify is also > related? > > > Could you clarify the question? I'm not sure what it is you'd like me to > chime in about. > > I guess you now know what I wanted to ask? > > 2, I've asked this question once but have had no answer, so I'm gonna > revive it her...

...ve hit the ground running. I'm looking forward to working with you. > On Apr 25, 2018, at 12:56 PM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Welcome Anastasis! I'm very happy to see this work going forward. > > I see that your first task is to make "debugify" into a function pass, > so we will be able to get data on a per-pass basis. At EuroLLVM there > was a relevant lightning talk about a different tool, see: > http://llvm.org/devmtg/2018-04/talks.html#Lightning_11 > It will be extremely interesting to see how well your results line...