similar to: [LLVMdev] Internalize pass

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

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

Sounds like LLVM thinks the calling conventions or declarations are mismatched. See: http://llvm.org/docs/FAQ.html#callconvwrong Reid On Sat, Oct 3, 2009 at 1:16 AM, Talin <viridia at gmail.com> wrote: > 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

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]"*

I'm trying to track down the problem with the assertion failure in SelectionDAGBuilder.cpp. This is the code: *case* *Intrinsic*::gcroot: *if* (GFI) { *const* Value *Alloca = I.getArgOperand(0); *const* Constant *TypeMap = cast<Constant>(I.getArgOperand(1)); * FrameIndexSDNode *FI = cast<FrameIndexSDNode>(getValue(Alloca).getNode());*

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 Nov 6, 2010, at 7:35 PM, Talin wrote: > After to speaking to Devang and a number of other people at the developer's conference, I was able to make some forward progress on getting debugging to work. I'm now able to actually single-step through my program and set breakpoints, and examine function parameters. > > However, I'm also seeing a lot of new problems which

After to speaking to Devang and a number of other people at the developer's conference, I was able to make some forward progress on getting debugging to work. I'm now able to actually single-step through my program and set breakpoints, and examine function parameters. However, I'm also seeing a lot of new problems which weren't exposed before. After spending the better part of two

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

On Mon, Nov 8, 2010 at 9:56 AM, Devang Patel <dpatel at apple.com> wrote: > > On Nov 6, 2010, at 7:35 PM, Talin wrote: > > After to speaking to Devang and a number of other people at the developer's > conference, I was able to make some forward progress on getting debugging to > work. I'm now able to actually single-step through my program and set > breakpoints,

On Nov 8, 2010, at 10:52 PM, Talin <viridia at gmail.com> wrote: > On Mon, Nov 8, 2010 at 9:56 AM, Devang Patel <dpatel at apple.com> wrote: > > On Nov 6, 2010, at 7:35 PM, Talin wrote: > >> After to speaking to Devang and a number of other people at the developer's conference, I was able to make some forward progress on getting debugging to work. I'm now

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 Tue, Nov 9, 2010 at 9:04 AM, Devang Patel <dpatel at apple.com> wrote: > > > On Nov 8, 2010, at 10:52 PM, Talin <viridia at gmail.com> wrote: > > On Mon, Nov 8, 2010 at 9:56 AM, Devang Patel < <dpatel at apple.com> > dpatel at apple.com> wrote: > >> >> On Nov 6, 2010, at 7:35 PM, Talin wrote: >> >> After to speaking to Devang

I'm working on the code to handle GC tracing of "intermediate values" (as described in the GC doc), and I've run into a weird problem. (Note, this has nothing to do with the patch I have proposed, this error occurs with regular old pointer-allocas.) The exception I am getting occurs in this code here in SelectionDAGBuilder.cpp: *case* *Intrinsic*::gcroot: *if* (GFI) {

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

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 Talin, I think that the framework for GC assumes llvm.gcroot to be in the first block. If it is not the case in your example, it will break these assumptions. Nicolas On Sun, Sep 26, 2010 at 1:38 AM, Talin <viridia at gmail.com> wrote: > I'm working on the code to handle GC tracing of "intermediate values" (as > described in the GC doc), and I've run into a

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

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

Hello, Nicolas. > Is there a way in llvm to get the address of a generated instruction? Or > somehow to fix the location of a label in the llvm code (something that > may look like a basic block perhaps) and get after the compilation the > address of this label? Maybe it's worth to use llvm.dbg.stoppoint? -- With best regards, Anton Korobeynikov. Faculty of Mathematics &