search for: cmp6

...__restrict b, int n) { #pragma unroll 4 for(int i=0; i<n; ++i) { a[i] += b[i]; } } results in: ; Function Attrs: nofree norecurse nounwind define dso_local void @_Z7vec_addPiS_i(i32* nocapture %a, i32* nocapture readonly %b, i32 %n) local_unnamed_addr #0 { entry: %cmp6 = icmp sgt i32 %n, 0 br i1 %cmp6, label %for.body.preheader, label %for.cond.cleanup . . ... I'm running this with LLVM RISC-V backend using RISC-V GCC compiled Newlib as the C/C++ library. Is it not okay to use GCC libraries with LLVM? Or could this be a specific issue with Newlib's he...

...%entry ], [ %inc, %for.cond ] %0 = icmp ne <2 x i32> %vecinit1, <i32 0, i32 -23> %1 = extractelement <2 x i1> %0, i32 %i.022 %vecext4 = extractelement <2 x i32> %vecinit1, i32 %i.022 %vecext5 = extractelement <2 x i32> <i32 0, i32 -23>, i32 %i.022 %cmp6 = icmp ne i32 %vecext4, %vecext5 %cmp7 = xor i1 %1, %cmp6 ... and the SelectionDAG before TypeLegalizer is like this. t0: ch = EntryToken t2: i32,ch = CopyFromReg t0, Register:i32 %vreg0 t3: ch = ValueType:i32 t5: i32,ch = CopyFromReg t2:1, Register:i32 %vreg1 t7: i32 = A...

...ext i32 %call to i64 br i1 %tobool, label %if.then, label %if.end if.then: ; preds = %entry br i1 false, label %cond.true5.i, label %if.end.thread53 cond.true5.i: ; preds = %if.then %0 = trunc i64 %conv to i32 %cmp6.i = icmp ugt i32 %0, 16 br i1 %cmp6.i, label %cond.true5.i26.thread, label %cond.true5.i26.thread59 cond.true5.i26.thread59: ; preds = %cond.true5.i %1 = bitcast [16 x i8]* %source18 to i8* call void @llvm.memcpy.p0i8.p0i8.i64(i8* nonnull %1, i8* nonnull %py_src, i6...

...or.cond ] > %0 = icmp ne <2 x i32> %vecinit1, <i32 0, i32 -23> > %1 = extractelement <2 x i1> %0, i32 %i.022 > %vecext4 = extractelement <2 x i32> %vecinit1, i32 %i.022 > %vecext5 = extractelement <2 x i32> <i32 0, i32 -23>, i32 %i.022 > %cmp6 = icmp ne i32 %vecext4, %vecext5 > %cmp7 = xor i1 %1, %cmp6 > > ... > > and the SelectionDAG before TypeLegalizer is like this. > > t0: ch = EntryToken > t2: i32,ch = CopyFromReg t0, Register:i32 %vreg0 > t3: ch = ValueType:i32 > t5: i32,ch = CopyFromReg...

...%entry ], [ %inc, %for.cond ] %0 = icmp ne <2 x i32> %vecinit1, <i32 0, i32 -23> %1 = extractelement <2 x i1> %0, i32 %i.022 %vecext4 = extractelement <2 x i32> %vecinit1, i32 %i.022 %vecext5 = extractelement <2 x i32> <i32 0, i32 -23>, i32 %i.022 %cmp6 = icmp ne i32 %vecext4, %vecext5 %cmp7 = xor i1 %1, %cmp6 ... and the SelectionDAG before TypeLegalizer is like this. t0: ch = EntryToken t2: i32,ch = CopyFromReg t0, Register:i32 %vreg0 t3: ch = ValueType:i32 t5: i32,ch = CopyFromReg t2:1, Register:i32 %vreg1 t7: i3...

...> v as it is constant. However you have a constant address to an array, which > is represented by [10000 x double]* @v in the IR, which requires to use the > two-level GEP. > > You “could” manage to represent it this way: > > define double @zap(i64 %n) #0 { > entry: > %cmp6 = icmp sgt i64 %n, 0 > %hoisted = bitcast [10000 x double]* @v to double* > br i1 %cmp6, label %for.body.preheader, label %for.cond.cleanup > > for.body.preheader: ; preds = %entry > br label %for.body > > for.cond.cleanup.loopexit:...

On 2/25/2013 2:08 PM, Redmond, Paul wrote: > > I've been looking through past threads looking for an answer to why the loop metadata is attached to the loop latch branch. What is the reason for putting the metadata inside the loop rather than outside (for example on the branch into the loop header.) Latch is a branch to the header. What branch in particular do you have in mind? Loop

...; preds = %for.body [...] br label %for.cond for.end: ; preds = %for.cond ret void } Which optimizes to the following (with a small change to LoopRotation.cpp) define void @foo(i32 %n, float* nocapture %a, float* nocapture %b) #0 { entry: %cmp6 = icmp sgt i32 %n, 0 br i1 %cmp6, label %for.body, label %for.end, !llvm.loop.parallel !0 for.body: ; preds = %entry, %for.body %indvars.iv = phi i64 [ %indvars.iv.next, %for.body ], [ 0, %entry ] %arrayidx = getelementptr inbounds float* %b, i64 %indv...

...er you have a constant address to an array, >> which is represented by [10000 x double]* @v in the IR, which requires to >> use the two-level GEP. >> >> You “could” manage to represent it this way: >> >> define double @zap(i64 %n) #0 { >> entry: >> %cmp6 = icmp sgt i64 %n, 0 >> %hoisted = bitcast [10000 x double]* @v to double* >> br i1 %cmp6, label %for.body.preheader, label %for.cond.cleanup >> >> for.body.preheader: ; preds = %entry >> br label %for.body >> >> for.cond...

Hi, I've been looking through past threads looking for an answer to why the loop metadata is attached to the loop latch branch. What is the reason for putting the metadata inside the loop rather than outside (for example on the branch into the loop header.) Note that I'm asking about llvm.loop.parallel not llvm.mem.parallel_loop_access which obviously must be inside the loop. It seems

...%entry ], [ %inc, %for.cond ] %0 = icmp ne <2 x i32> %vecinit1, <i32 0, i32 -23> %1 = extractelement <2 x i1> %0, i32 %i.022 %vecext4 = extractelement <2 x i32> %vecinit1, i32 %i.022 %vecext5 = extractelement <2 x i32> <i32 0, i32 -23>, i32 %i.022 %cmp6 = icmp ne i32 %vecext4, %vecext5 %cmp7 = xor i1 %1, %cmp6 ... and the SelectionDAG before TypeLegalizer is like this. t0: ch = EntryToken t2: i32,ch = CopyFromReg t0, Register:i32 %vreg0 t3: ch = ValueType:i32 t5: i32,ch = CopyFromReg t2:1, Register:i32 %vreg1 t7: i3...

When I compile two different modules using clang -O -S -emit-llvm I get different .ll files, no surprise. The first looks like double *v; double zap(long n) { double sum = 0; for (long i = 0; i < n; i++) sum += v[i]; return sum; } yielding @v = common global double* null, align 8 ; Function Attrs: nounwind readonly uwtable define double @zap(i64 %n) #0 { entry: %cmp4 =

...o an array, >>> which is represented by [10000 x double]* @v in the IR, which requires to >>> use the two-level GEP. >>> >>> You “could” manage to represent it this way: >>> >>> define double @zap(i64 %n) #0 { >>> entry: >>> %cmp6 = icmp sgt i64 %n, 0 >>> %hoisted = bitcast [10000 x double]* @v to double* >>> br i1 %cmp6, label %for.body.preheader, label %for.cond.cleanup >>> >>> for.body.preheader: ; preds = %entry >>> br label %for.body >&g...

...ch is represented by [10000 x double]* @v in the IR, which requires to >>>> use the two-level GEP. >>>> >>>> You “could” manage to represent it this way: >>>> >>>> define double @zap(i64 %n) #0 { >>>> entry: >>>> %cmp6 = icmp sgt i64 %n, 0 >>>> %hoisted = bitcast [10000 x double]* @v to double* >>>> br i1 %cmp6, label %for.body.preheader, label %for.cond.cleanup >>>> >>>> for.body.preheader: ; preds = %entry >>>> br la...

...x double]* @v in the IR, which >>>>> requires to use the two-level GEP. >>>>> >>>>> You “could” manage to represent it this way: >>>>> >>>>> define double @zap(i64 %n) #0 { >>>>> entry: >>>>> %cmp6 = icmp sgt i64 %n, 0 >>>>> %hoisted = bitcast [10000 x double]* @v to double* >>>>> br i1 %cmp6, label %for.body.preheader, label %for.cond.cleanup >>>>> >>>>> for.body.preheader: ; preds = %entry >>...

...ure the resulting predicate strictly partitions the predicate and does not wrap 4. Using *test* to determine whether the first lane is active (and thus at least one more iteration is required) ```llvm define i32 @SimpleReduction(i32* nocapture readonly %a, i32 %count) #0 { entry: %cmp6 = icmp sgt i32 %count, 0 br i1 %cmp6, label %min.iters.checked, label %for.cond.cleanup min.iters.checked: %0 = add i32 %count, -1 %1 = zext i32 %0 to i64 %2 = add nuw nsw i64 %1, 1 %wide.end.idx.splatinsert = insertelement <n x 4 x i64> undef, i64 %2, i32 0 %wide.e...

....i125.i.i.i.i, align 2, !tbaa !5 %phitmp.i.i.i.i = add i32 %i.025.i.i.i.i.i, 1 br label %for.body.i.i.i.i.i for.cond.i.i.i.i: ; preds = %if.end52.i.i.i.i, %for.body.i.i.i.i %j.0.i.i.i.i = phi i32 [ %inc.i.i.i.i, %for.body.i.i.i.i ], [ 1, %if.end52.i.i.i.i ] %cmp64.i.i.i.i = icmp slt i32 %j.0.i.i.i.i, 12 br i1 %cmp64.i.i.i.i, label %for.body.i.i.i.i, label %for.end.i.i.i.i for.body.i.i.i.i: ; preds = %for.cond.i.i.i.i %arrayidx66.i.i.i.i = getelementptr inbounds [13 x i16]* %bi.i.i.i.i, i32 0, i32 %j.0.i.i.i.i %195 = lo...