search for: scevgep9

...1, i1* %lsr.iv56, i32 %0 %2 = bitcast i1* %scevgep7 to i32* %exitcond27 = icmp eq i32 %inc10, %Size br i1 %exitcond27, label %for.cond.cleanup.loopexit, label %for.body.4.lr.ph for.body.4: ; preds = %for.body.4, %for.body.4.lr.ph %lsr.iv8 = phi i32* [ %scevgep9, %for.body.4 ], [ %lsr.iv5, %for.body.4.lr.ph ] %lsr.iv3 = phi i32* [ %scevgep4, %for.body.4 ], [ %lsr.iv1, %for.body.4.lr.ph ] %lsr.iv = phi i32 [ %lsr.iv.next, %for.body.4 ], [ %Size, %for.body.4.lr.ph ] %3 = load i32, i32* %lsr.iv8, align 4, !tbaa !1 %mul5 = mul i32 %3, %Val store i32...

...; > %exitcond27 = icmp eq i32 %inc10, %Size > > br i1 %exitcond27, label %for.cond.cleanup.loopexit, label % > for.body.4.lr.ph > > > > for.body.4: ; preds = > > %for.body.4, %for.body.4.lr.ph > > %lsr.iv8 = phi i32* [ %scevgep9, %for.body.4 ], [ %lsr.iv5, > > %for.body.4.lr.ph ] > > %lsr.iv3 = phi i32* [ %scevgep4, %for.body.4 ], [ %lsr.iv1, > > %for.body.4.lr.ph ] > > %lsr.iv = phi i32 [ %lsr.iv.next, %for.body.4 ], [ %Size, % > for.body.4.lr.ph ] > > %3 = load i32, i32* %lsr.iv8, a...

...v10 %uglygep13 = bitcast i8* %uglygep to i32* %uglygep15 = getelementptr i8, i8* %Dst14, i32 %lsr.iv10 %uglygep1516 = bitcast i8* %uglygep15 to i32* br label %for.body.4 for.body.4: ; preds = %for.body.4, %for.body.4.lr.ph %lsr.iv8 = phi i32* [ %scevgep9, %for.body.4 ], [ %uglygep13, %for.body.4.lr.ph ] %lsr.iv3 = phi i32* [ %scevgep4, %for.body.4 ], [ %uglygep1516, %for.body.4.lr.ph ] %lsr.iv = phi i32 [ %lsr.iv.next, %for.body.4 ], [ %Size, %for.body.4.lr.ph ] %1 = load i32, i32* %lsr.iv8, align 4, !tbaa !0 %mul5 = mul i32 %1, %Val...

On Mon, Aug 31, 2015 at 5:52 PM, Jake VanAdrighem <jvanadrighem at gmail.com> wrote: > Do you have some specific performance measurements? Averaging 4 runs of 10000 iterations each of Coremark on my X86_64 desktop showed: -O2 performance: +2.9% faster with the L.E.V. pass -Os size: 1.5% smaller with the L.E.V. pass In the case of Coremark, the benefit comes mainly from the matrix

...exec0 it recognizes that it doesn't need the tables and doesn't create them and also, it simplifies the expression, so that the generated code inside the loop is just a multiplication: %scevgep = getelementptr i32* %X, i64 %indvar %scevgep2 = getelementptr i32* %Y, i64 %indvar %scevgep9 = getelementptr i32* %res, i64 %indvar %3 = load i32* %scevgep, align 4, !tbaa !0 %4 = load i32* %scevgep2, align 4, !tbaa !0 %5 = mul nsw i32 %4, %3 store i32 %5, i32* %scevgep9, align 4, !tbaa !0 2) In exec1 however it fails to recognize that the temporary variables are not reused...

On Wed, Sep 23, 2015 at 12:00 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> >> Should we try the patch in it's current location, namely after LSR? > > Sure; post the patch as you have it so we can look at what's going on. > http://reviews.llvm.org/D12494 One particular point: The algorithm checks that SCEV's are equal when their raw pointers are equal. Is

Hi, We are experimenting directly generating vectorized LLVM IR (using <8 x float> kind of types), then compiling the code to SSE on a 64 bits machine. Right now the equivalent code in scalar mode sill outperform the SSE one. What is the quality of the SSE support in X86 LLVL backend? Are they any specific things to be aware of to improve the speed? Thanks Stéphane Letz

...gep16, !tbaa !14, !noalias !13, addrspace 1) SU(8): %39:gpr = LW %56:gpr, 0 :: (load 4 from %ir.lsr.iv6, !tbaa !14, !noalias !13, addrspace 1) SU(9): %40:gpr = LW %55:gpr, 0 :: (load 4 from %ir.lsr.iv12, !tbaa !14, !noalias !13, addrspace 1) SU(12): %42:gpr = LW %56:gpr, 4 :: (load 4 from %ir.scevgep9, !tbaa !14, !noalias !13, addrspace 1) SU(13): %43:gpr = LW %55:gpr, 4 :: (load 4 from %ir.scevgep15, !tbaa !14, !noalias !13, addrspace 1) SU(2): %35:gpr = nsw ADD %34:gpr, %33:gpr SU(3): SW %35:gpr, %55:gpr, -8 :: (store 4 into %ir.scevgep14, !tbaa !14, !noalias !13, addrspace 1) SU(6): %...

Hi Jeroen, That's great! I was trying to use the patch, what's the latest version of the project we could apply it on? Hi Neil, That seems like what I can do as well! Do you happen to have some examples lying around? Maybe a pointer to the planned presentation, if that's okay? Thank you, Bandhav On Mon, Jun 22, 2020 at 1:55 AM Neil Henning <neil.henning at unity3d.com>