similar to: Variable tracking in debug info

The debug information does try to track what happens to parameters and local variables. In the IR this is done with llvm.dbg.value intrinsic functions, and in Machine IR this is done with DBG_VALUE instructions. These have operands that point to the metadata describing the variable, and the location or value of the variable. Ideally each optimization would preserve this information, unless the

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.

> On Apr 1, 2018, at 9:12 AM, Hsiangkai Wang <hsiangkai at gmail.com> wrote: > > Hi all, > > I am sorry that I didn’t carefully think about how to handle labels in > inlined function. There is no need to apologize! Thank you very much for engaging in the discussion and for contributing you patches. > > Today, I did some simple experiments and found that some basic

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 ? > >

Hi, You should add this option to the first command *"-disable-O0-optnone"* so *clang -Xclang -disable-O0-optnone -emit-llvm -S -o without_dce.ll test.c* then *opt -dce -S < without_dce.ll > with_dce.ll* HTH, Son Tuan Vu On Fri, Mar 16, 2018 at 2:15 PM, HwJ via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hello, > > I'd like to measure the impact of

Hello all, I am interested in this work, and have tested it a bit so far. In the latest revision, it seems to me that we do not have support in Clang (so it doesn't generate llvm.dbg.label intrinsic) and in Dwarf debug emission (so the backend doesn't generate the DW_TAG_label DIE from the DBG_LABEL Machine Instruction) yet. I attempted to implement these features, do you want me to

Dear All, I am performing some analysis on a traditional IR Module Pass in LLVM, with that analysis I want to tag the places I will need to extract file offsets from as custom symbols. Ideally I would want to attach some metadata to a IR instruction, and have it be accessible when I perform a backend MF pass. Essentially I want to pass the information I collected and generated in the IR pass,

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, I'd like to measure the impact of optimizations. Trying this (for DCE): * clang -S -emit-llvm test.c * opt -S test.ll > without_dce.ll * opt -S -dce test.ll > with_dce.ll gives without_dce.ll and with_dce.ll having the same content. How can you apply certain optimizations in a specified order? Best, HwJ --- $ cat test.c > int dce(int n) { > if ((n < 0) || (n

Hi Vedant, Thanks for your reply. More comments inline. Son Tuan Vu On Fri, Apr 20, 2018 at 10: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

Hello, Has anyone taken a look at this bug? I really want to fix this, but as Paul pointed out, this requires a lot of care... Thank you for your help Son Tuan Vu On Fri, Apr 27, 2018 at 7:29 PM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > Thank you all for taking a look at this. I pasted the C source then > deleted it because I was afraid that it was too long to read...

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

+ 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 > > 2018-04-18 13:40 GMT+02:00

Ok, now I think I've found a bug: Consider this C code: void bar(int b) { int a[10]; memset(a, b, 10); } which generates this IR code: define dso_local void @bar(i32 %b) #0 { entry: %b.addr = alloca i32, align 4 %a = alloca [10 x i32], align 16 store i32 %b, i32* %b.addr, align 4 %arraydecay = getelementptr inbounds [10 x i32], [10 x i32]* %a, i64 0, i64 0 %0 = bitcast i32*

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

> On Apr 20, 2018, at 1:46 PM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hi Vedant, > > Thanks for your reply. More comments inline. > > Son Tuan Vu > > On Fri, Apr 20, 2018 at 10:19 PM, Vedant Kumar <vsk at apple.com <mailto:vsk at apple.com>> wrote: > Hi, > > + Chandler, who has a lot more experience with our pass managers.

Hello all, Does anyone know how to define a pure intrinsic in LLVM IR? I have tried almost every intrinsic property from llvm/include/llvm/IR/Intrinsics.td but haven't found anything. Or maybe this is not supported in the IR yet? Thank you for your help, Best, Son Tuan Vu -------------- next part -------------- An HTML attachment was scrubbed... URL:

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);

Hello, Does anyone know if it is possible to RAUW the Metadata? I took a look at the source for it and IIUC, it is not possible. What should I do to implement the RAUW for DINode (more precisely DILocation)? Thank you for your help, Son Tuan Vu -------------- next part -------------- An HTML attachment was scrubbed... URL: