search for: arrayidx5

...e %b, i32* noalias nocapture %c) #0 { entry: br label %for.body for.body: ; preds = %entry, %for.body %arrayidx.phi = phi i32* [ %b, %entry ], [ %arrayidx.inc, %for.body ] %arrayidx3.phi = phi i32* [ %c, %entry ], [ %arrayidx3.inc, %for.body ] %arrayidx5.phi = phi i32* [ %a, %entry ], [ %arrayidx5.inc, %for.body ] %indvars.iv = phi i32 [ 0, %entry ], [ %indvars.iv.next, %for.body ] %0 = load i32* %arrayidx.phi, align 4, !tbaa !0 %1 = load i32* %arrayidx3.phi, align 4, !tbaa !0 %add = add nsw i32 %1, %0 store i32 %add, i32* %arrayidx5...

...%x, 3 %add1 = add nsw i32 %x, 6 %idxprom3 = sext i32 %x to i64 %1 = sext i32 %add to i64 %2 = sext i32 %add1 to i64 br label %for.body for.body: ; preds = %for.body, %entry %indvars.iv = phi i64 [ %indvars.iv.next, %for.body ], [ %1, %entry ] %arrayidx5 = getelementptr inbounds [6 x [6 x [6 x i32]]], [6 x [6 x [6 x i32]]]* %mat, i64 0, i64 %idxprom3, i64 %indvars.iv, i64 1 %3 = load i32, i32* %arrayidx5, align 4, !tbaa !1 %add6 = add nsw i32 %3, 5 store i32 %add6, i32* %arrayidx5, align 4, !tbaa !1 %indvars.iv.next = add nsw i64 %indvars.i...

...%x, 3 %add1 = add nsw i32 %x, 6 %idxprom3 = sext i32 %x to i64 %1 = sext i32 %add to i64 %2 = sext i32 %add1 to i64 br label %for.body for.body: ; preds = %for.body, %entry %indvars.iv = phi i64 [ %indvars.iv.next, %for.body ], [ %1, %entry ] %arrayidx5 = getelementptr inbounds [6 x [6 x [6 x i32]]], [6 x [6 x [6 x i32]]]* %mat, i64 0, i64 %idxprom3, i64 %indvars.iv, i64 1 %3 = load i32, i32* %arrayidx5, align 4, !tbaa !1 %add6 = add nsw i32 %3, 5 store i32 %add6, i32* %arrayidx5, align 4, !tbaa !1 %indvars.iv.next = add nsw i64 %indvars.i...

...strict) and my_struct.source[i] (readonly). The compiler should easily figure out that they do not alias. Compiling for x86, the loop alias analysis works just fine: AST: Alias Set Tracker: 2 alias sets for 2 pointer values. AliasSet[0x7fd8e2f32290, 1] must alias, No access Pointers: (double* %arrayidx5, 18446744073709551615) AliasSet[0x7fd8e2f322e0, 1] must alias, No access Pointers: (double* %arrayidx, 18446744073709551615) Compiling for PPC with -target powerpc64le-ibm-linux-gnu, the two addresses now alias: AST: Alias Set Tracker: 1 alias sets for 2 pointer values. AliasSet[0x7f931bd5bd...

...ler should easily figure out that >> they do not alias. >> >> Compiling for x86, the loop alias analysis works just fine: >> AST: Alias Set Tracker: 2 alias sets for 2 pointer values. >> AliasSet[0x7fd8e2f32290, 1] must alias, No access Pointers: (double* >> %arrayidx5, 18446744073709551615) >> AliasSet[0x7fd8e2f322e0, 1] must alias, No access Pointers: (double* >> %arrayidx, 18446744073709551615) >> >> Compiling for PPC with -target powerpc64le-ibm-linux-gnu, the two >> addresses now alias: >> AST: Alias Set Tracker: 1 ali...

Hi, I have a LLVM IR file generated for a different source language (Not C). I have added a rand() function in it to generate random numbers. I compiled the .ll file to .o using clang. However, when I execute the .o file all generated numbers are zeros. How should I link the .ll file with the standard library for the clang to generate the random numbers? Thanks -Shilpa -------------- next

...; preds = %entry, %for.body %indvars.iv = phi i64 [ 0, %entry ], [ %indvars.iv.next, %for.body ] %arrayidx = getelementptr inbounds [255 x i8]* @b, i64 0, i64 %indvars.iv %0 = load i8* %arrayidx, align 1 %1 = xor i8 %0, -1 %2 = load i8* @DELTA, align 1 %sub2 = sub i8 %1, %2 %arrayidx5 = getelementptr inbounds i8* %a, i64 %indvars.iv store i8 %sub2, i8* %arrayidx5, align 1 ... %indvars.iv.next = add nuw nsw i64 %indvars.iv, 3 %11 = trunc i64 %indvars.iv.next to i32 %cmp = icmp ult i32 %11, 255 br i1 %cmp, label %for.body, label %for.end So, as you can see, my origina...

...%arrayidx3 = getelementptr inbounds [3 x <2 x i32>]* %sPrivateStorage, i64 0, i64 1 store <2 x i32> %1, <2 x i32>* %arrayidx3, align 8, !tbaa !9 %arrayidx4 = getelementptr inbounds <2 x i32>* %src, i64 2 %2 = load <2 x i32>* %arrayidx4, align 8, !tbaa !9 %arrayidx5 = getelementptr inbounds [3 x <2 x i32>]* %sPrivateStorage, i64 0, i64 2 store <2 x i32> %2, <2 x i32>* %arrayidx5, align 8, !tbaa !9 %idx.ext = zext i32 %alignmentOffsets to i64 %add.ptr = getelementptr inbounds [3 x <2 x i32>]* %sPrivateStorage, i64 0, i64 0, i64...

On 07/04/2013 01:39 PM, Stéphane Letz wrote: > Hi, > > Our DSL can generate C or directly generate LLVM IR. With LLVM 3.3, we can vectorize the C produced code using clang with -O3, or clang with -O1 then opt -O3 -vectorize-loops. But the same program generating LLVM IR version cannot be vectorized with opt -O3 -vectorize-loops. So our guess is that our generated LLVM IR lacks some

...--------------- for.body: ; preds = %for.body, %entry %store_forwarded = phi i32 [ %load_initial, %entry ], [ %mul, %for.body ] %indvars.iv = phi i64 [ 1, %entry ], [ %indvars.iv.next, %for.body ] %mul = mul nsw i32 %store_forwarded, %store_forwarded %arrayidx5 = getelementptr inbounds [10 x i32], [10 x i32]* @X, i64 0, i64 %indvars.iv store i32 %mul, i32* %arrayidx5, align 4, !tbaa !2 %indvars.iv.next = add nuw nsw i64 %indvars.iv, 1 %exitcond = icmp eq i64 %indvars.iv.next, 10 br i1 %exitcond, label %for.end, label %for.body --------------------...

Hi, Our DSL can generate C or directly generate LLVM IR. With LLVM 3.3, we can vectorize the C produced code using clang with -O3, or clang with -O1 then opt -O3 -vectorize-loops. But the same program generating LLVM IR version cannot be vectorized with opt -O3 -vectorize-loops. So our guess is that our generated LLVM IR lacks some informations that are needed by the vectorization passes to

...[ %indvars.iv.next, %for.body ]* %arrayidx = getelementptr inbounds i32, i32* %x, i64 %indvars.iv %2 = load i32, i32* %arrayidx, align 4, !tbaa !1 %arrayidx3 = getelementptr inbounds i32, i32* %y, i64 %indvars.iv %3 = load i32, i32* %arrayidx3, align 4, !tbaa !1 %div = sdiv i32 %2, %3 %arrayidx5 = getelementptr inbounds i32, i32* %z, i64 %indvars.iv store i32 %div, i32* %arrayidx5, align 4, !tbaa !1 * %indvars.iv.next = add nuw i64 %indvars.iv, 5* %cmp = icmp slt i64 %indvars.iv.next, %1 %cmp1 = icmp slt i64 %indvars.iv.next, %0 %or.cond = and i1 %cmp, %cmp1 br i1 %or.cond, labe...

...i32* %input, i64 %idxprom %0 = load i32* %arrayidx, align 4, !tbaa !1 %call1 = tail call i32 @get_local_id(i32 0) #2 %idxprom2 = zext i32 %call1 to i64 %arrayidx3 = getelementptr inbounds i32* %mask, i64 %idxprom2 %1 = load i32* %arrayidx3, align 4, !tbaa !1 %add = add nsw i32 %1, %0 %arrayidx5 = getelementptr inbounds i32* %output, i64 %idxprom store i32 %add, i32* %arrayidx5, align 4, !tbaa !1 ret void } As you can see in the R600 IR the address space information is present because the R600 address space map in CLANG is non trivial and it map opencl address spaces to R600 target ad...

...t; they do not alias. >>>> >>>> Compiling for x86, the loop alias analysis works just fine: >>>> AST: Alias Set Tracker: 2 alias sets for 2 pointer values. >>>> AliasSet[0x7fd8e2f32290, 1] must alias, No access Pointers: (double* >>>> %arrayidx5, 18446744073709551615) >>>> AliasSet[0x7fd8e2f322e0, 1] must alias, No access Pointers: (double* >>>> %arrayidx, 18446744073709551615) >>>> >>>> Compiling for PPC with -target powerpc64le-ibm-linux-gnu, the two >>>> addresses now alias:...

...dy > %indvars.iv = phi i64 [ 0, %entry ], [ %indvars.iv.next, %for.body ] > %arrayidx = getelementptr inbounds [255 x i8]* @b, i64 0, i64 %indvars.iv > %0 = load i8* %arrayidx, align 1 > %1 = xor i8 %0, -1 > %2 = load i8* @DELTA, align 1 > %sub2 = sub i8 %1, %2 > %arrayidx5 = getelementptr inbounds i8* %a, i64 %indvars.iv > store i8 %sub2, i8* %arrayidx5, align 1 > ... > %indvars.iv.next = add nuw nsw i64 %indvars.iv, 3 > %11 = trunc i64 %indvars.iv.next to i32 > %cmp = icmp ult i32 %11, 255 > br i1 %cmp, label %for.body, label %for.end &...

It's not clear what is actually wrong from your original message, I think you need to give some more information as to what you are doing: Example source, what target GPU, compiler error messages or other evidence of "it's wrong" (llvm IR, disassembly, etc) ... -- Mats On 8 April 2016 at 09:55, Liu Xin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I built it

> -----Original Message----- > From: Michele Scandale [mailto:michele.scandale at gmail.com] > Sent: Saturday, August 10, 2013 6:29 AM > To: Micah Villmow > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Address space extension > > On 08/10/2013 02:47 PM, Micah Villmow wrote: > > Michele, > > The information you are trying to gather is fundamentally

Renato, can you post a hand-created vectorized IR of how a reduction would work on your example? I don’t think that recognizing this as a reduction is going to get you far. A reduction is beneficial if the value reduced is only truly needed outside of a loop. This is not the case here (we are storing/loading from the pointer). Your example is something like WRITEPTR = phi i8* [ outsideval,

I just subscribed this group. This is my first time to post a question (not sure if this is a right place for discussion) after I have a brief look at LLVM OPT (dev trunk). I would expect loop simplification and induction variable canonicalization pass (IndVarSimplify pass) should be able to convert the following loops into a simple canonical form, i.e., there is a canonical induction variable

...; preds = %for.body, %entry ... %0 = load float* %arrayidx, !llvm.mem.vector_loop_access !{metadata i32 10, !0} ... %1 = load float* %arrayidx2, !llvm.mem.vector_loop_access !{metadata i32 15, !0} ... store float %add3, float* %arrayidx5, !llvm.mem.vector_loop_access !{metadata i32 17, !0} ... br i1 %exitcond, label %for.end, label %for.body, !llvm.loop !0 for.end: ; preds = %for.body ret void } !0 = metadata !{metadata !0, metadata !1} !1 = metadata !{met...