search for: stoppoints

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 results are both attached. Is there any way to map line numbers

I need to generate line number debug information for PIC16 target. PIC16 does not support dwarf format. It supports coff format. So I need to custom handle the STOPPOINT nodes. Without -fast option the STOPPOINT nodes are not created in dag because of the below check in SelectionDAGBuild.cpp if (Fast) DAG.setRoot(DAG.getDbgStopPoint(getRoot(), If I give -fast option then the Fast

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 ({ }*)*

On Apr 5, 2009, at 11:54 PMPDT, vasudev wrote: > I need to generate line number debug information for PIC16 target. > PIC16 does not support dwarf format. It supports coff format. So I > need > to custom handle the STOPPOINT nodes. Without -fast option the > STOPPOINT > nodes are not created in dag because of the below check in > SelectionDAGBuild.cpp > if (Fast)

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 variables. I am planning to custom handle these nodes, get the required info from llvm.dbg.variable global address and emit it in ISel. But without -fast option ISD::DECLARE nodes

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 (the command is: opt -anders-aa test.bc -disable-output -print-alias-sets &>

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 > variables. I am planning to custom handle these nodes, get the > required > info from llvm.dbg.variable

...t;> info correct that is fine. > > 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? For the dbg.stoppoints: many of the stoppoint instructions dissapear at higher optimization levels. We need these to link back instructions to original C statements. I guess this is not related to the mem2reg pass. Is there a way to at least keep the stoppoint instructions? > > We're working on the required su...

...ould: > - teach GVN that a dependency on a debug instruction is not a real > one, > and should ignore it > - teach GVN to remove stale dbg info due to its transformations > - if we cannot preserve dbg.stoppoint we may try to preserve > region.begin() and region.end() [or convert stoppoints to regions] I'd really like to avoid removing stoppoints unless they are redundant: two stoppoints that are right next to each other, so they represent the exact same state. Currently, I'm thinking that it would make sense to have instcombine zap two stoppoints that are right next...

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 done when EMIT_LLVM is set. A more pressing questi...

...canonical form either. So we could: - teach GVN that a dependency on a debug instruction is not a real one, and should ignore it - teach GVN to remove stale dbg info due to its transformations - if we cannot preserve dbg.stoppoint we may try to preserve region.begin() and region.end() [or convert stoppoints to regions] Consider you are debugging a crash in optimized code: Hey, your program crashed somewhere in function foo in foo.o vs. Hey, your program crashed in function foo in region foo1.c:100 - foo1.c:120 Also preserving debug info about variable names can be useful. http://nondot.org/sab...

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, { }*)*

...> >> 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 dbg.stoppoints: many of the stoppoint instructions dissapear > at higher optimization levels. We need these to link back instructions > to original C statements. I guess this is not related to the mem2reg > pass. Is there a way to at least keep the stoppoint instructions? Good news. In mainline svn sour...

...VN that a dependency on a debug instruction is not a real >> one, >> and should ignore it >> - teach GVN to remove stale dbg info due to its transformations >> - if we cannot preserve dbg.stoppoint we may try to preserve >> region.begin() and region.end() [or convert stoppoints to regions] >> > > I'd really like to avoid removing stoppoints unless they are > redundant: two stoppoints that are right next to each other, so they > represent the exact same state. Currently, I'm thinking that it would > make sense to have instcombine za...

I'm playing around with different combinations of LTO passes, and I've run into a strange problem: I have a 'main' function that looks like this: define i32 @"main(tart.core.Array[tart.core.String])->int"(%"tart.core.Array[tart.core.String]"* %args) { entry: call void @llvm.dbg.func.start(metadata !0) call void @llvm.dbg.stoppoint(i32 2, i32 19, metadata

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

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

Well, after some investigation I have a few more clues as to what is going on. I have a module which contains a call to an external native function. This native function lives in a static library, and there is an external declaration for it in the module. I find that I can run "llvm-ld -disable-opts -native -l mylibrary test.bc" and it works fine. That is, llvm-ld is able to

On Sep 30, 2009, at 12:06 AM, Talin wrote: > I'm playing around with different combinations of LTO passes, and > I've run into a strange problem: > > I have a 'main' function that looks like this: > > define i32 @"main(tart.core.Array[tart.core.String])- > >int"(%"tart.core.Array[tart.core.String]"* %args) { > entry: > call