similar to: [LLVMdev] Effect on NSW attribute on 'mul' during InstCombine pass ?

Hi all, I'm using LLVM 3.0, for which I've filed following bug http://llvm.org/bugs/show_bug.cgi?id=12130. I'm trying to solve this problem by myself digging into LLVM sources. It seems that problem that I'm experiencing is related to presence or absence of NSW attribute on a 'mul'. Considering following code: define void @t2(double* %x) { L.entry: %a = alloca [2 x

Hi all, I'm using LLVM 3.0, for which I've filed following bug http://llvm.org/bugs/show_bug.cgi?id=12130<https://webmail-eu.st.com/owa/redir.aspx?C=f2882890c0064e71ba4c8238dc7fd399&URL=http%3a%2f%2fllvm.org%2fbugs%2fshow_bug.cgi%3fid%3d12130> . I'm trying to solve this problem by myself digging into LLVM sources. It seems that problem that I'm experiencing is related to

Hi Seb, I think it is an opt bug. If you run opt at -O1 then you get: define void @t2(double* nocapture %x) nounwind { L.entry: %a = alloca [2 x i64], align 8 %0 = getelementptr inbounds [2 x i64]* %a, i32 0, i32 0 store i64 3, i64* %0, align 8 %1 = getelementptr [2 x i64]* %a, i32 0, i32 1 store i64 5, i64* %1, align 8 %2 = bitcast [2 x i64]* %a to double* %3 = load double*

Hi Duncan, Indeed, I made same experiment as you and concluded that it might be a BUG. Shall I submit it to llvm bug tracking support ? Do you think there could be a work-around ? Thanks for your quick answer. Best Regards Seb 2012/2/28 Duncan Sands <baldrick at free.fr> > Hi Seb, I think it is an opt bug. If you run opt at -O1 then you get: > > define void @t2(double*

Hi all, I'm looking at following code snippet: void t2(double *x) { long long a[2]; a[0] = 3; a[1] = 5; *x = * ((double *) a); *(x+1) = * ((double *) &a[a[0]-2]); } I use generate LLVM code using my own front-end that looks like: ; ModuleID = 'jb.c' target datalayout =

Yes, you need the latest ToT version of llvm or you run -loop-vectorize -earlycse -instcombine -simplifycfg The bitcast essentially is a noop to satisfy the type system. This is how your example looks like for me: vector.body: ; preds = %vector.body, %vector.ph %index = phi i64 [ 0, %vector.ph ], [ %index.next, %vector.body ] %.lhs = shl i64 %6, 2

The instcombine pass cleans up a lot. Any idea why there are still shufflevector, insertelement, *and* bitcast (!!) etc. instructions left? The original loop is so clean, a textbook example I'd say. There is no need to shuffle anything.At least I don't see it. Frank vector.ph: ; preds = %L5 %broadcast.splatinsert1 = insertelement <4 x

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

According to comment in tree-nested.c, these frames should be only introduced in case of debug or OpenMP lowering: /* A subroutine of convert_nonlocal_reference_op. Create a local variable in the nested function with DECL_VALUE_EXPR set to reference the true variable in the parent function. This is used both for debug info and in OpenMP lowering. */ However, in this code example we

The loop vectorized does not estimate the cost of vectorization by looking at the IR you list below. It does not vectorize and then run the CostAnalysis pass. It estimates the cost itself before it even performs the vectorization. The way it works is that it looks at all the scalar instructions and asks: What is the cost if I execute the scalar instruction as a vector instruction. Therefore, it

Hello, Everyone. I have a question about llvm's "Combine redundant instructions(instcombine)" pass. I have tested instcombine pass by writing the following three test cases. But, CASE3 is not optimized as I expected. Is this behavior expected? The version of llvm is: clang version 5.0.1 (tags/RELEASE_501/final 325232) Option of clang command is: clang -O1 a.c -S -emit-llvm

The loop vectorizer relies on cleanup passes to be run after it: from Transforms/IPO/PassManagerBuilder.cpp: // Add the various vectorization passes and relevant cleanup passes for // them since we are no longer in the middle of the main scalar pipeline. MPM.add(createLoopVectorizePass(DisableUnrollLoops)); MPM.add(createInstructionCombiningPass());

When I compile attached IR with LLVM 3.6 llc -march=x86-64 -o f.S f.ll it generates an aligned ADDPS with unaligned address. See attached f.S, here an extract: addq $12, %r9 # $12 is not a multiple of 4, thus for xmm0 this is unaligned xorl %esi, %esi .align 16, 0x90 .LBB0_1: # %loop2

The following IR implements the following nested loop: for (int i = start ; i < end ; ++i ) for (int p = 0 ; p < 4 ; ++p ) a[i*4+p] = b[i*4+p] + c[i*4+p]; define void @main(i64 %arg0, i64 %arg1, i1 %arg2, i64 %arg3, float* noalias %arg4, float* noalias %arg5, float* noalias %arg6) { entrypoint: br i1 %arg2, label %L0, label %L1 L0:

Hello, I've been redirected from cfe-dev, as code optimizations in clang are done in llvm layer. I'm investigating how optimized code clang generates, and have come across such an example: I have two procedures: void exec0(const int *X, const int *Y, int *res, const int N) { int t1[N],t2[N],t3[N],t4[N],t5[N],t6[N]; for(int i = 0; i < N; i++) { t1[i] = X[i]+Y[i];

Hi Duncan, A DragonEgg/GCC-related question: do you know where these strange FRAME tokens originate from (e.g. %struct.FRAME.matmul)? Compiling simple Fortran code with DragonEgg: > cat matmul.f90 subroutine matmul(nx, ny, nz) implicit none integer :: nx, ny, nz real, dimension(nx, ny) :: A real, dimension(ny, nz) :: B real, dimension(nx, nz) :: C integer :: i, j, k real,

thank john, i have used dump() , and each blocks had pred except entery block, i get the following output: fun main entry entry: %retval = alloca i32 %0 = alloca i32 %i = alloca i32 %j = alloca i32 %a = alloca [2 x i32] %n = alloca i32 %t = alloca i32 %"alloca point" = bitcast i32 0 to i32 %1 = getelementptr inbounds [2 x i32]* %a, i32 0, i32 0 %2 = load i32*

I changed the input C to using a 64 bit type for the loop index (this eliminates 'sext' instructions in the IR) Here the IR produced with clang -O0 define float @foo(i64 %start, i64 %end, float* %A) #0 { entry: %start.addr = alloca i64, align 8 %end.addr = alloca i64, align 8 %A.addr = alloca float*, align 8 %sum = alloca [4 x float], align 16 %i = alloca i64, align 8

Hi, I have a doubt with GEP transformation in the instruction-combiner. Consider below test-case: struct ABC { int A; int B[100]; struct XYZ { int X; int Y[100]; } OBJ; }; void Setup(struct ABC *); int foo(int offset) { struct ABC *Ptr = malloc(sizeof(struct ABC)); Setup(Ptr); return Ptr->OBJ.X + Ptr->OBJ.Y[33]; } Generated IR for the test-case: define i32 @foo(i32

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