similar to: [LLVMdev] Optimizations and debug info

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

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.

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

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 Martijn On Fri, Nov 13, 2009 at 4:52 AM, Martijn <martijn at martijnrutten.com> wrote: > Hello, > > 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

Hello, 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 debug information by compiling with -g. This works fine with

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 All, Today, debugging information is encoded in LLVM IR using various llvm.dbg intrinsics, such as llvm.dbg.stoppoint. For exmaple, !1 = metadata !{i32 458769, i32 0, i32 12, metadata !"foo.c", metadata !"/tmp", metadata !"clang 1.0", i1 true, i1 false, metadata !"", i32 0} ... call void @llvm.dbg.stoppoint(i32 5, i32 5, metadata !1) store i32

On Feb 8, 2010, at 8:51 PM, Duncan Sands wrote: > this can be done using debug info. Check out > http://llvm.org/docs/SourceLevelDebugging.html Wow, that threw me for a loop. I'm using the 2.6 release, thinking I was up to date, but its debug output doesn't look anything like what's described in the above link. It appears to document the upcoming 2.7 version, which

Can we help in local variable debug info work. Dale Johannesen wrote: > On Apr 7, 2009, at 9:52 PMPDT, vasudev wrote: > > >> Thanks for the info regarding DebugLoc field. Another related >> question >> that I have is regarding debug info for local variables. With -fast >> option, ISD::DECLARE nodes are created in DAG for debug info of local >>

On Nov 3, 2008, at 5:22 AM, Török Edwin wrote: >> OTOH, I'm not sure how to best handle global memory updates w.r.t. >> stoppoints. Dan is absolutely right that stoppoints represent a >> point >> where we'd like to preserve observable memory state, and so it makes >> sense to treat them as memory read points at the least. However, if >> we want to

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 Jul 8, 2008, at 3:33 AM, Matthijs Kooijman wrote: > Hi all, > > I've been fiddling around with debug info generated by clang, with > the goal of > propagating line number info to our custom backend (which is not an > llvm > backend, but does use llvm IR as its input). Cool. > I've created a small pass which strips all debug info except for > stop

Hi all, I've been fiddling around with debug info generated by clang, with the goal of propagating line number info to our custom backend (which is not an llvm backend, but does use llvm IR as its input). I've created a small pass which strips all debug info except for stop points, which are currently the only things we're interested in. Leaving only stop points in actually works

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

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,

Hi everyone, After some time hacking on llvm, let me introduce myself :) I'm a PhD student at the French university Pierre et Marie Curie in Paris. I work on a project called the "Virtual Virtual Machine" project. You can find some (dated) information on the website http://vvm.lip6.fr. Basically it's a "low level virtual machine" :) with a just in time compiler

Well, I am much happier now that I understand about dsymutil, and can actually step through my program in gdb. However, there are still some issues that are puzzling me. 1) First off, the debugger appears to stop at odd points. The IR for my main function looks correct to me: define i32 @"main(tart.core.Array[tart.core.String])->int"(%"tart.core.Array[tart.core.String]"*

Dear Staff, Here are some questions on the output formats of AliasSetTracker. The code is as below: int G1 = 9; int G2 = 5; int main() { int * XX; int * YY; XX = &G1; YY = XX; YY = &G2; XX = &G2; } The output for -anders-aa is: Alias Set Tracker: 5 alias sets for 4 pointer values. AliasSet[0xea6fb0,0] may alias, Mod/Ref 10 Call Sites: void ({ }*)*

Quoting Eli Friedman <eli.friedman at gmail.com>: Dear Eli, Thanks very much for your reply. I have modified the XX and YY to be global variables, but the output of AliasSetTracker are still MUST alias: Alias Set Tracker: 5 alias sets for 4 pointer values. AliasSet[0xea55d0,0] may alias, Mod/Ref 8 Call Sites: void ({ }*)* @llvm.dbg.func.start, void (i32, i32, { }*)*