similar to: [LLVMdev] Getting source line numbers from within a Pass?

Hi, I'm just getting back to working on the cfe debug info after a brief hiatus. It appears that the appropriate place to be inserting stoppoints is starting in llvm_expand_stmt, using STMT_LINENO(t) . If that's not the best place, comments would be appreciated. Using the debug_hooks seems to be a non-starter, because they're called during rtl generation, which apparently isn't

Hi, I've got the cfe debug info to the point where it outputs correct function info, stoppoints for statements (but not for declarations anymore) and region ends at the beginning of the return block. So this is about as far as I wanted to go with it. However, there's one last big problem that I need some advice on. Running : gcc -g -S -o foo.ll llvmas foo.ll produces bytecode that works

Hi, It's taking me a while to get familiar with the cfe in order to add emitting stop points for debugging. It's a lot to work through, so in order to speed things up, I've got a few questions. Any help would be appreciated. I understand the design of the intrinsics once they're in the code, but how to generate them is still a little fuzzy, mainly because llvm_expand is a little

On Oct 31, 2008, at 1:29 PM, Török Edwin wrote: > Hi Dan, > I am actually more interested in Analysis working in presence of debug > info, but in order to get any meaningful results, you need to run some > transformations, at least GVN, otherwise loops aren't transformed to > canonical form either. Right. > So we could: > - teach GVN that a dependency on a debug

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,

On 2008-11-03 12:33, Chris Lattner wrote: > On Oct 31, 2008, at 1:29 PM, Török Edwin wrote: > >> Hi Dan, >> I am actually more interested in Analysis working in presence of debug >> info, but in order to get any meaningful results, you need to run some >> transformations, at least GVN, otherwise loops aren't transformed to >> canonical form either.

Richard Osborne wrote: > It seems to me that emitting DWARF line number information using .loc > directives is currently broken. CellSPU is currently the only in tree > target that sets HasDotLocAndDotFile in its MCAsmInfo and I can't get it > to produce any line number information. > I think I understand why this is happening. Since HasDotLocAndDotFile is set the

On Tue, 23 Aug 2005, Michael McCracken wrote: >> Okay... this is tricky. Anything that will bind to variables will >> prevent modification to the variable. > > I see - so if I wanted to use my earlier approach, I'd need to change every > optimization and analysis to treat the 'marker' instructions specially as > instructions that don't modify their

On Aug 5, 2004, at 5:30 PM, Chris Lattner wrote: > On Thu, 5 Aug 2004, Michael McCracken wrote: > >> Hi, I have a hopefully quick question. I'm writing a Pass that needs >> to >> see a whole module at a time and keep some state, so I subclassed >> Pass. >> However, I want to be able to see the Loops in each Function. Roughly, > > ok. > >>

Chris, Thanks for the suggestions. On 8/22/05, Chris Lattner <sabre at nondot.org> wrote: > On Fri, 19 Aug 2005, Michael McCracken wrote: > > > I've been thinking of adding an instruction, and I'm following the > > advice in the docs to consult the list before doing something rash. > > Always a good idea! :) Instead of adding an instruction, I'd

Hi, I have a hopefully quick question. I'm writing a Pass that needs to see a whole module at a time and keep some state, so I subclassed Pass. However, I want to be able to see the Loops in each Function. Roughly, here's what I want: virtual bool run(Module &M){ // do stuff... for (Module::iterator I = M.begin(), E = M.end(); I != E; ++I){ if(! I->isExternal())

Hi, I'm trying to access an analysis pass from the Inliner pass, and I'm having a lot of trouble getting that to work - I can verify that my pass is loaded and run (it is a dynamically loaded pass that is part of an analysisgroup), however, when I access it using getAnalysis<> from within Inliner::runOnSCC, I am instead getting the default, dummy version of my analysis, which should

[Moving discussion to LLVMdev] On 2008-10-31 21:55, Dan Gohman wrote: > Hi Török, > > @llvm.dbg.stoppoint actually does read and write memory, in a > sense. It's a point where a user could stop in a debugger, and > use the debugger to both read and write memory. If the optimizers > are allowed to reorder or delete memory operations, these > intrinsics will become

On Thu, 5 Aug 2004, Michael McCracken wrote: > Hi, I have a hopefully quick question. I'm writing a Pass that needs to > see a whole module at a time and keep some state, so I subclassed Pass. > However, I want to be able to see the Loops in each Function. Roughly, ok. > However, when running I'm informed that: > > PassManagerT.h:421: failed assertion

Hi Martijn, On Tue, Nov 17, 2009 at 3:25 AM, Martijn <martijn at martijnrutten.com> wrote: >> >> Without mem2reg pass, you're unlikely to get much optimization done on your IR. > > Clear, thanks! I presume the mem2reg pass is also essential in the > CLang frontend, so CLang is not an alternative to llvm-gcc to keep > more debug information? Yes. > For the

Hi Devang, >> I use llvm and llvm-gcc as a C-to-C transformation tool using a >> modified version of the c backend, and rely on llvm debug instructions >> to link back to the original source code. >> >> Does anyone know how to get detailed line number and variable debug >> information at optimization levels beyond O0? >> >> Currently, I extract this

On Mon, 20 Mar 2006, Michael McCracken wrote: > Hi, I'm trying to access an analysis pass from the Inliner pass, and > I'm having a lot of trouble getting that to work - I can verify that > my pass is loaded and run (it is a dynamically loaded pass that is > part of an analysisgroup), however, when I access it using > getAnalysis<> from within Inliner::runOnSCC, I am

On 8/23/05, Chris Lattner <sabre at nondot.org> wrote: > On Tue, 23 Aug 2005, Michael McCracken wrote: > >> Okay... this is tricky. Anything that will bind to variables will > >> prevent modification to the variable. > > > > I see - so if I wanted to use my earlier approach, I'd need to change every > > optimization and analysis to treat the

Hi, Chris Lattner wrote: > In the 2.3 release, we included a list of the major LLVM API changes. If you > are working on upgrading your code from 2.3 to 2.4, I'd appreciate it if you > could compile a list of the major stumbling blocks you have, so that others > can benefit from your experience. Please send any info to the list, thanks! No major stumbling blocks during our

I've been thinking of adding an instruction, and I'm following the advice in the docs to consult the list before doing something rash. What I want to do is provide a way to identify variable names and source locations that doesn't affect the effectiveness of optimizations. This is not the same problem as supporting debug info, because I don't care about being able to look up