search for: dbginfointrinsic

Hi LLVM, If I have an llvm value "<16 x float> addrspace(1)* %in", and in the LLVM IR, there is a @llvm.dbg.value like: call void @llvm.dbg.value(metadata <16 x float> addrspace(1)* %in, i64 0, metadata !216, metadata !28), !dbg !217 How I can retrieve this @llvm.dbg.value when I have "%in"? Since Metadata is not a part of the uselist anymore, is there some way

I just updated from CVS, and after doing a clean rebuild I get this error: /Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h: In static member function 'static bool llvm::DbgInfoIntrinsic::classof (const llvm::IntrinsicInst*)': /Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h:77: error: 'dbg_declare' is not a member of 'llvm::Intrinsic' /Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h: In static member function 'static bool llvm...

...reads >      // memory (without proving that the loop doesn't write). >      if (L->hasLoopInvariantOperands(Inst) && >          !Inst->mayReadFromMemory() && !Inst->mayWriteToMemory() && >          !isa<TerminatorInst>(Inst) && !isa<DbgInfoIntrinsic>(Inst)) { >        Inst->moveBefore(LoopEntryBranch); >        continue; >      } > > The above code happily moves an alloca instruction out of the loop, to > the new loop header. Shouldn't we also check on > >   !isa<AllocaInst>(Inst) > > before allowi...

...and after doing a clean rebuild I get this error: Are you sure that no conflicts prevented updating from going smoothly? How are you building (srcdir ==/!= objdir)? -Chris > /Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h: In static > member function 'static bool llvm::DbgInfoIntrinsic::classof(const > llvm::IntrinsicInst*)': > /Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h:77: error: > 'dbg_declare' is not a member of 'llvm::Intrinsic' > /Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h: In static > member function...

...t;> IntrinsicInst. >>>> >>>> Patch attached. >>> >>> IntrinsicInst isn't necessarily safe... >> >> >> Without IntrinsicInst we break >> test/Transforms/LoopIndexSplit/SplitValue-2007-08-24-dbg.ll. > > Checking for isa<DbgInfoIntrinsic> is safe. Ah, right :) Thanks for your help. I hope that everything is OK now. New patch attached. -Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: pr4174-3.patch Type: application/octet-stream Size: 2943 bytes Desc: not available URL: <http://list...

...; this error: > > Are you sure that no conflicts prevented updating from going > smoothly? How are you building (srcdir ==/!= objdir)? > > -Chris > >> /Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h: In >> static member function 'static bool llvm::DbgInfoIntrinsic::classof >> (const llvm::IntrinsicInst*)': >> /Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h:77: >> error: 'dbg_declare' is not a member of 'llvm::Intrinsic' >> /Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h: In >>...

...;hacks" are needed: for BranchInst and for IntrinsicInst. >>> >>> Patch attached. >> >> IntrinsicInst isn't necessarily safe... > > > Without IntrinsicInst we break > test/Transforms/LoopIndexSplit/SplitValue-2007-08-24-dbg.ll. Checking for isa<DbgInfoIntrinsic> is safe. -Eli

...ion when such information interferes with > optimization.  Is this correct, Yes. > and if so, does anyone know off-hand > which optimizations do this? The optimizer does not emit any statistics here. You can search various transformation passes' code to see whether they are handling DbgInfoIntrinsics or not. Or may be I misunderstood your question ? > 2) I believe a new debug annotation design is being implemented in > mainline LLVM for the 2.7 release.  What is the current status of this > work?  Does it already yield more accurate debug information than LLVM 2.6? It is still a wor...

Dear All, 1) I recall reading somewhere that a few optimizations in LLVM 2.6 strip away debug information when such information interferes with optimization. Is this correct, and if so, does anyone know off-hand which optimizations do this? 2) I believe a new debug annotation design is being implemented in mainline LLVM for the 2.7 release. What is the current status of this work? Does

...t; >>>>> Patch attached. >>>> >>>> IntrinsicInst isn't necessarily safe... >>> >>> >>> Without IntrinsicInst we break >>> test/Transforms/LoopIndexSplit/SplitValue-2007-08-24-dbg.ll. >> >> Checking for isa<DbgInfoIntrinsic> is safe. > > Ah, right :) Thanks for your help. I hope that everything is OK now. > > New patch attached. Looks fine, I think. I should probably consider some changes to isSafeToSpeculativelyExecute, though... That said, I'm not entirely sure how this is supposed to interact...

...prevented updating from going smoothly? How > >> are you building (srcdir ==/!= objdir)? > >> > >> -Chris > >> > >>> /Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h: In static > >>> member function 'static bool llvm::DbgInfoIntrinsic::classof(const > >>> llvm::IntrinsicInst*)': > >>> /Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h:77: error: > >>> 'dbg_declare' is not a member of 'llvm::Intrinsic' > >>> /Users/bocchino/llvm-checkin/src/include/l...

...Are you sure that no conflicts prevented updating from going smoothly? How >> are you building (srcdir ==/!= objdir)? >> >> -Chris >> >>> /Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h: In static >>> member function 'static bool llvm::DbgInfoIntrinsic::classof(const >>> llvm::IntrinsicInst*)': >>> /Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h:77: error: >>> 'dbg_declare' is not a member of 'llvm::Intrinsic' >>> /Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h:...

On Aug 21, 2009, at 10:02 PM, Eli Friedman wrote: > On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at gcc.gnu.org> > wrote: >> >> On Aug 21, 2009, at 8:46 PM, Eli Friedman wrote: >> >>> On Fri, Aug 21, 2009 at 3:29 PM, Jakub Staszak<kuba at gcc.gnu.org> >>> wrote: >>>> >>>> On Aug 21, 2009, at 7:31 PM, Eli

...something that reads // memory (without proving that the loop doesn't write). if (L->hasLoopInvariantOperands(Inst) && !Inst->mayReadFromMemory() && !Inst->mayWriteToMemory() && !isa<TerminatorInst>(Inst) && !isa<DbgInfoIntrinsic>(Inst)) { Inst->moveBefore(LoopEntryBranch); continue; } The above code happily moves an alloca instruction out of the loop, to the new loop header. Shouldn't we also check on !isa<AllocaInst>(Inst) before allowing to move it? The code that breaks becau...

...ly? How >>>> are you building (srcdir ==/!= objdir)? >>>> >>>> -Chris >>>> >>>>> /Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h: >>>>> In static >>>>> member function 'static bool llvm::DbgInfoIntrinsic::classof(const >>>>> llvm::IntrinsicInst*)': >>>>> /Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h: >>>>> 77: error: >>>>> 'dbg_declare' is not a member of 'llvm::Intrinsic' >>>>> /Users/bo...

Hi, I have two problems regarding the llvm.stackrestore intrinsic. I'm running on 3.0, but a quick test on trunk also showed the same behavior. First problem: --------------- I have code like: tmp1 = call llvm.stacksave() tmp2 = alloca [do some stuff with tmp2] call llvm.stackrestore(tmp1) [some other stuff] tmp3 = call llvm.stacksave() tmp4 = alloca [do some stuff

There are a few instrinsic functions I would like to remove, is this possible? For example, the llvm.lifetime and llvm.dbg instrinsics? You can't simply iterate over the funciton and remove the call instructions, this causes issues. Is there a known structured way of doing this? -------------- next part -------------- An HTML attachment was scrubbed... URL:

...; this error: > > Are you sure that no conflicts prevented updating from going > smoothly? How are you building (srcdir ==/!= objdir)? > > -Chris > >> /Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h: In >> static member function 'static bool llvm::DbgInfoIntrinsic::classof >> (const llvm::IntrinsicInst*)': >> /Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h:77: >> error: 'dbg_declare' is not a member of 'llvm::Intrinsic' >> /Users/bocchino/llvm-checkin/src/include/llvm/IntrinsicInst.h: In >>...

...roblem is that ADCE is treating all terminator instructions as live: // Collect the set of "root" instructions that are known live. for (inst_iterator I = inst_begin(F), E = inst_end(F); I != E; ++I) if (isa<TerminatorInst>(I.getInstructionIterator()) || isa<DbgInfoIntrinsic>(I.getInstructionIterator()) || I->mayHaveSideEffects()) { alive.insert(I.getInstructionIterator()); worklist.push_back(I.getInstructionIterator()); } Is this correct? I would have thought that branch instructions should not be initially live. FYI, removing the...

For the sample profiler, I need to determine the location of the first user instruction in the function. This can be the LOC where the function header is or the LOC of the actual first instruction, it doesn't really matter. But it needs to be consistent wrt -g and -gline-tables-only. Currently, I'm scanning for the first non-zero line number from the top of the function. This skips over