similar to: [LLVMdev] Problem using 'bitcast'

> call void @llvm.dbg.declare( { }* bitcast(i32* %loc0 to { }*), { }* bitcast (%llvm.dbg.variable.type* @llvm.dbg.variable1 to { }*) ) This is not legal. The distinction here is that the bitcast as an argument is a constant expression and requires constant arguments, and %loc0 is not constant. Introducing the temp variable is the "right way" to do this. - Daniel -----

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

On Thu, Dec 8, 2011 at 4:26 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Thu, Dec 8, 2011 at 2:11 PM, Vitor Luis Menezes <vitor at utexas.edu> wrote: >> We've got the following test case: >> >> >> class A { >> public: >>   int x; >>   A(int x) : x(x) {} >>   int hoo() {return 4;} >>   virtual int foo() {return x;}

You're right, it can indeed. Is there a reason -O3 doesn't do this? I had been expecting -O3 to perform full optimization. The first block still remains in any case. Is the first block needed for some purpose I'm not taking into account? On Sun, Sep 20, 2015 at 5:27 AM, Xiangyang Guo <eceguo at gmail.com> wrote: > Hi, > > if you use opt -simplifycfg, the third BB can

The following function compiles with -O3 into the following IR. http://llvm.org/docs/Passes.html#simplifycfg-simplify-the-cfg says - Eliminates a basic block that only contains an unconditional branch. but the first and third blocks in the compiled function only contain an unconditional branch; I would have expected them to be eliminated. What am I missing? double f(double *a) { for (int i

Hi Jim, Thanks for the advice. Since I'm using LLVM 2.9 style of debug information. Will this code benefit from those improvement or should I generate LLVM 3.0 style of debug information ? Best Regards Seb 2012/3/6 Jim Grosbach <grosbach at apple.com> > > On Mar 6, 2012, at 5:31 AM, Seb <babslachem at gmail.com> wrote: > > Hi all, > > Anyone have ideas/info on

On Thu, Dec 8, 2011 at 2:11 PM, Vitor Luis Menezes <vitor at utexas.edu> wrote: > We've got the following test case: > > > class A { > public: >   int x; >   A(int x) : x(x) {} >   int hoo() {return 4;} >   virtual int foo() {return x;} >   virtual int goo() {return foo()+10;} >   virtual int operator+(A &a) { >     return x + a.x; >   } > };

Hi all, Anyone have ideas/info on this topic ? Thanks Seb 2012/3/2 Seb <babslachem at gmail.com> > Hi all, > > I'm using my own front-end to generate following code .ll file targeting > x86 32-bit: > > ; ModuleID = 'check.c' > target datalayout = >

On Mar 6, 2012, at 5:31 AM, Seb <babslachem at gmail.com> wrote: > Hi all, > > Anyone have ideas/info on this topic ? > Thanks > Seb > > 2012/3/2 Seb <babslachem at gmail.com> > Hi all, > > I'm using my own front-end to generate following code .ll file targeting x86 32-bit: > > ; ModuleID = 'check.c' > target datalayout =

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

Hi all, I'm using my own front-end to generate following code .ll file targeting x86 32-bit: ; ModuleID = 'check.c' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32" target triple = "i386-pc-linux-gnu" @.str581 = internal constant [52 x i8] c"---- test number %d

Hi, Im new to llvm and I'm using llvm-2.6 and I know how to extract the metadata in the stoppoints but what I'm interested in is the meta data regarding a local variable. I know that the @llvm.dgb.declare such as: call void @llvm.dbg.declare({ }* %2, { }* bitcast (%llvm.dbg.variable.type* @llvm.dbg.variable9 to { }*)) links to meta data for @llvm.dbg.variable9 which is:

We've got the following test case: class A { public: int x; A(int x) : x(x) {} int hoo() {return 4;} virtual int foo() {return x;} virtual int goo() {return foo()+10;} virtual int operator+(A &a) { return x + a.x; } }; class B : public A { public: B(int x) : A(x) {} int hoo() {return 2;} virtual int foo() {return A::foo()*2;} }; int main() { A* a = new A(1);

Here's what this function is supposed to do: // Move early uses of spilled variable after CoroBegin. // For example, if a parameter had address taken, we may end up with the code // like: // define @f(i32 %n) { // %n.addr = alloca i32 // store %n, %n.addr // ... // call @coro.begin // we need to move the store after coro.begin in the

Mainline. ------------------------------ From: John Criswell Sent: Tuesday, May 03, 2011 8:34 PM To: Arushi Aggarwal Cc: LLVM Dev Subject: Re: [LLVMdev] GVN Infinite loop On 5/3/11 5:25 PM, Arushi Aggarwal wrote: Hi, GVN seems to be running in an infinite loop on my example. I have attached the output of one iteration. I cant seem to reduce the testcase either. Are you running with LLVM

On May 3, 2011, at 3:25 PM, Arushi Aggarwal wrote: > Hi, > > GVN seems to be running in an infinite loop on my example. I have attached the output of one iteration. I cant seem to reduce the testcase either. > > Any pointers to how to reduce the test case. Bugzilla can reduce testcases that cause infinite loops (it has a -timeout flag), I'd try it. Even if this doesn't

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());*

The frontend code is a pretty simple for loop, that counts from i = 0; i != 10; i += 1 It gets optimized into and endless loop. export fn entry() void { var array: [10]Bar = undefined; var x = for (array) |elem, i| { if (i == 1) break elem; } else bar2(); } Here's the generated IR: ; ModuleID = 'test' source_filename = "test" target datalayout =

Hi Andy, Andrew Trick wrote: > Sanjoy, > > This looks very close to my understanding of the statepoint design trajectory when you first introduced it. It’s great that you followed through and took the time to formalize the IR semantics. It’s been a couple years since I’ve thought about it so I may ask some obtuse questions. > > I think he subject line is wrong though! Did

When compiling code with lld -O0 --lto-O0 --eh-frame-hdr I get strange interleaved line info all over the place: ... 0x00000000000595ac 22 11 1 0 0 is_stmt 0x00000000000595bc 25 7 1 0 0 is_stmt <<< 0x00000000000595c0 22 11 1 0 0 is_stmt 0x00000000000595c4 25 7 1 0 0 is_stmt <<< 0x00000000000595c8 26 7 1 0 0 is_stmt but the code only has 1 reference to line 25 and the