search for: inc6

...for.cond2.preheader.lr.ph: >> %cond22 = phi i32 [ %call, %cond.end ], [ 46, %entry ] >> %cmp314 = icmp sgt i32 %cond22, 0 >> br label %for.cond2.preheader >> for.cond2.preheader: >> %x.019 = phi i32 [ 0, %for.cond2.preheader.lr.ph ], [ %x.1.lcssa, >> %for.inc6 ] >> %a.018 = phi i32 [ 0, %for.cond2.preheader.lr.ph ], [ %inc7, %for.inc6 ] >> br i1 %cmp314, label %for.body4, label %for.inc6 >> for.body4: >> %x.116 = phi i32 [ %inc, %for.body4 ], [ %x.019, %for.cond2.preheader ] >> %b.015 = phi i32 [ %inc5, %for.body4 ],...

...h, label %for.end8 > for.cond2.preheader.lr.ph: > %cond22 = phi i32 [ %call, %cond.end ], [ 46, %entry ] > %cmp314 = icmp sgt i32 %cond22, 0 > br label %for.cond2.preheader > for.cond2.preheader: > %x.019 = phi i32 [ 0, %for.cond2.preheader.lr.ph ], [ %x.1.lcssa, > %for.inc6 ] > %a.018 = phi i32 [ 0, %for.cond2.preheader.lr.ph ], [ %inc7, %for.inc6 ] > br i1 %cmp314, label %for.body4, label %for.inc6 > for.body4: > %x.116 = phi i32 [ %inc, %for.body4 ], [ %x.019, %for.cond2.preheader ] > %b.015 = phi i32 [ %inc5, %for.body4 ], [ 0, %for.cond2.pre...

...h: >>> %cond22 = phi i32 [ %call, %cond.end ], [ 46, %entry ] >>> %cmp314 = icmp sgt i32 %cond22, 0 >>> br label %for.cond2.preheader >>> for.cond2.preheader: >>> %x.019 = phi i32 [ 0, %for.cond2.preheader.lr.ph ], [ %x.1.lcssa, >>> %for.inc6 ] >>> %a.018 = phi i32 [ 0, %for.cond2.preheader.lr.ph ], [ %inc7, %for.inc6 >>> ] >>> br i1 %cmp314, label %for.body4, label %for.inc6 >>> for.body4: >>> %x.116 = phi i32 [ %inc, %for.body4 ], [ %x.019, %for.cond2.preheader ] >>> %b.015...

...nd8 for.cond2.preheader.lr.ph: %cond22 = phi i32 [ %call, %cond.end ], [ 46, %entry ] %cmp314 = icmp sgt i32 %cond22, 0 br label %for.cond2.preheader for.cond2.preheader: %x.019 = phi i32 [ 0, %for.cond2.preheader.lr.ph ], [ %x.1.lcssa, %for.inc6 ] %a.018 = phi i32 [ 0, %for.cond2.preheader.lr.ph ], [ %inc7, %for.inc6 ] br i1 %cmp314, label %for.body4, label %for.inc6 for.body4: %x.116 = phi i32 [ %inc, %for.body4 ], [ %x.019, %for.cond2.preheader ] %b.015 = phi i32 [ %inc5, %for.body4 ], [ 0,...

...oat** %A.addr, align 8 %0 = bitcast [4 x float]* %sum to i8* call void @llvm.memset.p0i8.i64(i8* %0, i8 0, i64 16, i32 16, i1 false) %1 = load i64* %start.addr, align 8 store i64 %1, i64* %i, align 8 br label %for.cond for.cond: ; preds = %for.inc6, %entry %2 = load i64* %i, align 8 %3 = load i64* %end.addr, align 8 %cmp = icmp slt i64 %2, %3 br i1 %cmp, label %for.body, label %for.end8 for.body: ; preds = %for.cond store i64 0, i64* %q, align 8 br label %for.cond1 for.cond1:...

On 7 November 2013 17:18, Frank Winter <fwinter at jlab.org> wrote: > LV: We don't allow storing to uniform addresses > This is triggering because it didn't recognize as a reduction variable during the canVectorizeInstrs() but did recognize that sum[q] is loop invariant in canVectorizeMemory(). I'm guessing the nested loop was unrolled because of the low trip-count, and

I am trying my luck on this global reduction kernel: float foo( int start , int end , float * A ) { float sum[4] = {0.,0.,0.,0.}; for (int i = start ; i < end ; ++i ) { for (int q = 0 ; q < 4 ; ++q ) sum[q] += A[i*4+q]; } return sum[0]+sum[1]+sum[2]+sum[3]; } LV: Checking a loop in "foo" LV: Found a loop: for.cond1 LV: Found an induction variable. LV: We

...ph, label %for.end8 > for.cond2.preheader.lr.ph: > %cond22 = phi i32 [ %call, %cond.end ], [ 46, %entry ] > %cmp314 = icmp sgt i32 %cond22, 0 > br label %for.cond2.preheader > for.cond2.preheader: > %x.019 = phi i32 [ 0, %for.cond2.preheader.lr.ph ], [ %x.1.lcssa, %for.inc6 ] > %a.018 = phi i32 [ 0, %for.cond2.preheader.lr.ph ], [ %inc7, %for.inc6 ] > br i1 %cmp314, label %for.body4, label %for.inc6 > for.body4: > %x.116 = phi i32 [ %inc, %for.body4 ], [ %x.019, %for.cond2.preheader ] > %b.015 = phi i32 [ %inc5, %for.body4 ], [ 0, %for.cond2...

Hi, When I write various test cases and explore how they're handled by the code in LoopDependenceAnalysis::analysePair, I'm surprised. This loop collects pairs of subscripts from the source and destination refs. * // Collect GEP operand pairs (FIXME: use GetGEPOperands from BasicAA), adding* * // trailing zeroes to the smaller GEP, if needed.* * GEPOpdsTy destOpds, srcOpds;* *

Hi, Here is a preliminary (monolithic) version you can comment on. This is still buggy, however, and I'll be testing for and fixing bugs over the next few days. I've used your version of the strong siv test. Thanks! -- Sanjoy Das. http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.diff Type: application/octet-stream

On Jun 7, 2012, at 7:31 PM, Hal Finkel wrote: > 112B BB#1: derived from LLVM BB %for.body, ADDRESS TAKEN > Predecessors according to CFG: BB#0 BB#1 > %vreg12<def> = PHI %vreg13, <BB#1>, %vreg11, <BB#0>;CTRRC8:%vreg12,%vreg13,%vreg11 > %vreg13<def> = COPY %vreg12<kill>; CTRRC8:%vreg13,%vreg12 > %vreg13<def> = BDNZ8 %vreg13,

..., llvm::MachineBasicBlock::iterator, llvm::SlotIndex, llvm::MachineOperand&, llvm::LiveInt erval&): Assertion `!isAllocatable(interval.reg) && "Physregs shouldn't be live out!"' failed. in this case the loop is quite simple: 944B BB#8: derived from LLVM BB %for.inc6, ADDRESS TAKEN Live Ins: %CTR8 Predecessors according to CFG: BB#8 BB#3 960B BDNZ8 <BB#8>, %CTR8<imp-def>, %CTR8<imp-use,kill> Successors according to CFG: BB#8 BB#10 the preheader is: 240B BB#3: Predecessors accordi...

Hello again, I am trying to implement an optimization pass for PowerPC such that simple loops use the special "counter register" (CTR) to track the induction variable. This is helpful because, in addition to reducing register pressure, there is a combined decrement-compare-and-branch instruction BZND (there are also other related instructions). I started this process by converting the