similar to: [LLVMdev] optimizer problem, possibly involving instcombine

On Fri, Apr 14, 2017 at 2:19 PM, Mikulin, Dmitry <dmitry.mikulin at sony.com> wrote: > >>> Is this a run with debug info? i.e. are you passing -g to the per-TU >>> pipeline? I'm inclined to think this is mostly an additive effect >>> adding matchers here and there that don't really hurt small testcases >>> but we pay the debt over time (in

The code for ccall looks right. Sounds like you have a very small range of instructions where an uninitialized value appear. You could try debugging at asm level. Shadow for b should be passed at offset 0 in __msan_param_tls. MSan could propagate shadow through arithmetic and even some logic operations (like select). It could be that b is clean on function entry, but then something uninitialized

Looks like when you materialize the stores, you should check the size of the the store and emit an appropriate amount of stores to the origin shadow (or just a memset intrinsic?). On Wed, Feb 5, 2014 at 2:13 PM, Keno Fischer <kfischer at college.harvard.edu>wrote: > The @entry stuff is just a gdb artifact. I've been tracking this back a > little further, and it seems there's

Yes, it would be great to get that fixed. On Wed, Feb 5, 2014 at 4:09 PM, Evgeniy Stepanov <eugeni.stepanov at gmail.com>wrote: > On Thu, Feb 6, 2014 at 12:21 AM, Keno Fischer > <kfischer at college.harvard.edu> wrote: > > Looks like when you materialize the stores, you should check the size of > the > > the store and emit an appropriate amount of stores to the

> On Apr 13, 2017, at 7:43 PM, Davide Italiano <davide at freebsd.org> wrote: > > On Thu, Apr 13, 2017 at 5:18 PM, Mikulin, Dmitry > <dmitry.mikulin at sony.com> wrote: >> I’m taking a first look at InstCombine performance. I picked up the caching patch and ran a few experiments on one of our larger C++ apps. The size of the *.0.2.internalize.bc no-debug IR is ~ 30M.

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

I'm going to show the same function, first normally, and then as a coroutine, and show how gdb can see the variable when it's a normal function, but not when it's a coroutine. I'd like to understand if this can be improved. I'm trying to debug a real world problem, but the lack of debug info on variables in coroutines is making it difficult. Should I file a bug? Is this a

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

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 =

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 =

On Mon, Jun 19, 2017 at 12:06 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > Hi, > > 2017-06-19 8:45 GMT-07:00 Andrew Kelley via llvm-dev < > llvm-dev at lists.llvm.org>: > >> Greetings, >> >> I have a Zig implementation of ceil which is emitted into LLVM IR like >> this: >> >> ; Function Attrs: nobuiltin nounwind >> define

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

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

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

I have been investigating missing variables / incorrect variable values when debugging code compiled at -O1 (and above) and believe that I have tracked the issue down to the interaction of the generation of IR @llvm.dbg.value entries and phi nodes. I would welcome someone who is more familiar with the generation of debug information to help me determine if what I think is going wrong is correct

When zig updated to llvm 5 we started hitting this assertion: zig: /home/andy/downloads/llvm-project/llvm/include/llvm/Support/Casting.h:106: static bool llvm::isa_impl_cl<To, const From*>::doit(const From*) [with To = llvm::Instruction; From = llvm::Value]: Assertion `Val && "isa<> used on a null pointer"' failed. I wonder if however this was caused by an

Can you please open a bug on bugzilla and attach the ir testcase? Your fix doesn't look right (just hiding the assertion failure) On Sep 17, 2017 10:45 AM, "Andrew Kelley via llvm-dev" < llvm-dev at lists.llvm.org> wrote: > What do you think about this patch? > > --- a/llvm/lib/Transforms/Scalar/NewGVN.cpp > +++ b/llvm/lib/Transforms/Scalar/NewGVN.cpp > @@

Hi, I want to clone a given function, and add an argument to it. I then want to add a call to that new function. I have a callInstruction CI, which I want to transform to call this new function, and to take a new argument. The code I added was as follows CI->getCalledFunction()->dump(); Function* DirectF = CloneFunction(CI->getCalledFunction());

I was trying to build the Linux kernel with clang and observed a crash due to incorrect loop optimization: drivers/base/firmware_class.c extern struct builtin_fw __start_builtin_fw[]; extern struct builtin_fw __end_builtin_fw[]; static bool fw_get_builtin_firmware(struct firmware *fw, const char *name) { struct builtin_fw *b_fw; for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw;