similar to: [LLVMdev] Pulling line number/file/path information from DbgStopPointInst instructions

On Wed, Apr 29, 2009 at 6:04 PM, Sarah Thompson <sarah at findatlantis.com> wrote: > Hi folks, > > I had some code that used to work fine in earlier versions of LLVM, > but is now failing. I have some code that expands DbgStopPointInst > instructions to my own entry points in an opt pass, but it's currently > failing to get the file name and path back, though it is

Hmm... if I do a print() on the result of getFileName(), I get i8 * getelementptr ([9 x i8]* @.str, i32 0, i32 0) back, but if I try to dyn_cast this to GetElementPtrInst it fails (returning null), so presumably I'm seeing a GetElementPtrConstantExpr... so how can I get at that constant i8 array without casting to a GetElementPtrInst, and with GetElementPtrConstantExpr being

>From DwarfDebug.cpp: >/// GetOrCreateSourceID - Look up the source id with the given directory and >/// source file names. If none currently exists, create a new id and insert it >/// in the SourceIds map. This can update DirectoryNames and SourceFileNames >/// maps as well. >unsigned DwarfDebug::GetOrCreateSourceID(StringRef FileName, >

On Sat, 8 Apr 2006, Jim Laskey wrote: > If you look at the stoppoint calls you'll see that you can find the line > number and if you follow the compile unit argument on the call you will find > the file. The byte codes that follow the call would have been generated by > the code on that source line. I'd suggest an approach like this: Given an instruction in the a basic

Josh Matthews wrote: >> From DwarfDebug.cpp: > >> /// GetOrCreateSourceID - Look up the source id with the given directory and >> /// source file names. If none currently exists, create a new id and insert it >> /// in the SourceIds map. This can update DirectoryNames and SourceFileNames >> /// maps as well. >> unsigned

I get it now, I can't believe I didn't understand that before. Thank you all for your help! - John On 4/8/06, Chris Lattner <sabre at nondot.org> wrote: > > On Sat, 8 Apr 2006, Jim Laskey wrote: > > If you look at the stoppoint calls you'll see that you can find the line > > number and if you follow the compile unit argument on the call you will > find >

Dear All, To add to this, what you want to do is find the appropriate debug stop point intrinsic and then use it to look up the information for that instruction. Here is some sample code from SAFECode that finds the debug information associated with a CallInst (LLVM call instruction) held in the variable CI. It uses the findStopPoint() function in llvm/Analyis/DebugInfo.h: // // Get the

Dear All, To add to this, what you want to do is find the appropriate debug stop point intrinsic and then use it to look up the information for that instruction. Here is some sample code from SAFECode that finds the debug information associated with a CallInst (LLVM call instruction) held in the variable CI. It uses the findStopPoint() function in llvm/Analyis/DebugInfo.h: // // Get the

Hi, just a quick question about the intent of the ApproximateLoopSize() function in LoopUnroll.cpp: If a loop contains debug stoppoint intrinsics, does it make sense to count them? My understanding is that they are removed when not running under llvm-db anyway, so we probably shouldn't make size judgements based on them. Is that right, or am I missing something? Anyway, if I'm right,

John, If you look at the stoppoint calls you'll see that you can find the line number and if you follow the compile unit argument on the call you will find the file. The byte codes that follow the call would have been generated by the code on that source line. -- Jim On Apr 8, 2006, at 5:33 AM, John Trimble wrote: > Thanks for your help. I took a look at http://llvm.org/docs/

Thanks for your help. I took a look at http://llvm.org/docs/SourceLevelDebugging.html and it seems like this doesn't give you much in the way of line number information. If you know what source line you are interested in then you can set a breakpoint, but suppose you want to know the line number in the source code for some arbitrary bytecode instruction. In my particular case, I have a pass

On 2009-07-09 11:17, Aaron Gray wrote: >>> -----Original Message----- >>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >>> >> On >> >>> Behalf Of Saman Aliari Zonouz >>> Sent: Thursday, July 09, 2009 11:44 AM >>> To: llvmdev at cs.uiuc.edu >>> Subject: [LLVMdev] Source file

>> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On >> Behalf Of Saman Aliari Zonouz >> Sent: Thursday, July 09, 2009 11:44 AM >> To: llvmdev at cs.uiuc.edu >> Subject: [LLVMdev] Source file information. >> >> Hi, >> >> I am new to LLVM, and need to find the line number

Hi, I would like to know how much effect these stoppoint calls have on the optimization of the bytecode? DOes insertion of debugging info cause opportunities for optimization (especially interprocedural dead code elimination and interprocedural constant propogation) to be reduced? The -g code is not very readable, so I am not able to confirm this by my own experiment. Thanks! Nikhil On Sat,

Hi, I would like to know how to locate an LLVM instruction in the source code, i.e. to get the line number of its corresponding source code statement. I remember in LLVM 2.4, DbgStopPointInst is designed to help this locating, but it seems deprecated in the latest LLVM. Thanks, Jingyue -- Jingyue Wu Department of Computer Science Columbia University New York, NY 10027

On 2009-09-24 22:34, hc2428 at columbia.edu wrote: > Dear developers, > When I try to map line numbers in source code back to LLVM > basicblocks, I meet some problems: there is a source file with 1500 > lines of code, but when I use BasicBlockPass to collect all > DbgStopPoint instructions in this file, I can only get 500 lines of code. > The source code and the collected

Hi all, I just come across an IR instruction like this: %0 = getelementptr i32* getelementptr inbounds ([42 x i32]* @aaa, i32 0, i32 0), i32 %2 What does the part "i32* getelementptr inbounds ([42 x i32]* @aaa, i32 0, i32 0)" mean? As far as I could understand this is a GetElementPtrConstantExpr, isn't it? My question is: how can I instantiate a class that represents that

Hi During a pass, the XCore target lowers thread local global variables by turning them into global variable arrays indexed by the (max 8) thread ID. (see XCoreLowerThreadLocal.cpp) This works fine for instructions e.g. GetElementPtrInst But can't be done for constants e.g. GetElementPtrConstantExpr Thus I would like to replace GetElementPtrConstantExpr with GetElementPtrInst when it is

Hmm... looks like my LLVM build script only built debug versions of the tools, not release versions. I'm investigating, I didn't change anything that should have caused that. [s] On Apr 28, 2009, at 4:56 PM, Bill Wendling wrote: > On Tue, Apr 28, 2009 at 4:43 PM, Sarah Thompson <sarah at findatlantis.com > > wrote: >> OK, that got much further, but I'm now

Is it consistent to have a Pass instance's run method's implementation use getAnalysisIfAvailable<AnalysisType>() (vs just using getAnalysis< AnalysisType >) when that same instance's getAnalysisUsage(AnalysisUsage &au) implementation invokes au.addRequired<AnalysisType>()? For example in the implementation of SelectionDAGISel::runOnMachineFunction(...) (called