Displaying 13 results from an estimated 13 matches for "add10".
Did you mean:
add1
2013 Oct 30
3
[LLVMdev] loop vectorizer
...t; %add51 = shl i64 %0, 2
> %mul6 = or i64 %rem, %add51
> %add8 = or i64 %mul6, 4
> %arrayidx = getelementptr inbounds float* %a, i64 %add2
> %1 = load float* %arrayidx, align 4
> %arrayidx9 = getelementptr inbounds float* %b, i64 %add2
> %2 = load float* %arrayidx9, align 4
> %add10 = fadd float %1, %2
> %arrayidx11 = getelementptr inbounds float* %c, i64 %add2
> store float %add10, float* %arrayidx11, align 4
> %arrayidx12 = getelementptr inbounds float* %a, i64 %add8
> %3 = load float* %arrayidx12, align 4
> %arrayidx13 = getelementptr inbounds float* %b, i64...
2013 Oct 30
2
[LLVMdev] loop vectorizer
...tride - Not an AddRecExpr pointer %arrayidx15 = getelementptr
inbounds float* %c, i64 %add8 SCEV: ((4 * %add8)<nsw> + %c)<nsw>
LV: Src Scev: ((4 * %add2)<nsw> + %c)<nsw>Sink Scev: ((4 * %add8)<nsw> +
%c)<nsw>(Induction step: 0)
LV: Distance for store float %add10, float* %arrayidx11, align 4 to
store float %add14, float* %arrayidx15, align 4: ((4 * %add8)<nsw> + (-4
* %add2))
Non-consecutive pointer access
LV: We don't need a runtime memory check.
LV: Can't vectorize due to memory conflicts
LV: Not vectorizing.
Here the code:
entry:
%...
2013 Oct 30
0
[LLVMdev] loop vectorizer
...l i64 %div, 3
%rem = and i64 %i.015, 3
%add2 = or i64 %mul, %rem
%add8 = or i64 %add2, 4
%arrayidx = getelementptr inbounds float* %a, i64 %add2
%0 = load float* %arrayidx, align 4
%arrayidx9 = getelementptr inbounds float* %b, i64 %add2
%1 = load float* %arrayidx9, align 4
%add10 = fadd float %0, %1
%arrayidx11 = getelementptr inbounds float* %c, i64 %add2
store float %add10, float* %arrayidx11, align 4
%arrayidx12 = getelementptr inbounds float* %a, i64 %add8
%2 = load float* %arrayidx12, align 4
%arrayidx13 = getelementptr inbounds float* %b, i64 %add8
%...
2013 Oct 30
2
[LLVMdev] loop vectorizer
...= and i64 %i.015, 3
> %add2 = or i64 %mul, %rem
> %add8 = or i64 %add2, 4
> %arrayidx = getelementptr inbounds float* %a, i64 %add2
> %0 = load float* %arrayidx, align 4
> %arrayidx9 = getelementptr inbounds float* %b, i64 %add2
> %1 = load float* %arrayidx9, align 4
> %add10 = fadd float %0, %1
> %arrayidx11 = getelementptr inbounds float* %c, i64 %add2
> store float %add10, float* %arrayidx11, align 4
> %arrayidx12 = getelementptr inbounds float* %a, i64 %add8
> %2 = load float* %arrayidx12, align 4
> %arrayidx13 = getelementptr inbounds float* %b,...
2013 Oct 30
0
[LLVMdev] loop vectorizer
...oremerge10, 1
%add51 = shl i64 %0, 2
%mul6 = or i64 %rem, %add51
%add8 = or i64 %mul6, 4
%arrayidx = getelementptr inbounds float* %a, i64 %add2
%1 = load float* %arrayidx, align 4
%arrayidx9 = getelementptr inbounds float* %b, i64 %add2
%2 = load float* %arrayidx9, align 4
%add10 = fadd float %1, %2
%arrayidx11 = getelementptr inbounds float* %c, i64 %add2
store float %add10, float* %arrayidx11, align 4
%arrayidx12 = getelementptr inbounds float* %a, i64 %add8
%3 = load float* %arrayidx12, align 4
%arrayidx13 = getelementptr inbounds float* %b, i64 %add8
%...
2013 Oct 30
3
[LLVMdev] loop vectorizer
On 30 October 2013 09:25, Nadav Rotem <nrotem at apple.com> wrote:
> The access pattern to arrays a and b is non-linear. Unrolled loops are
> usually handled by the SLP-vectorizer. Are ir0 and ir1 consecutive for all
> values for i ?
>
Based on his list of values, it seems that the induction stride is linear
within each block of 4 iterations, but it's not a clear
2013 Oct 30
0
[LLVMdev] loop vectorizer
...Not an AddRecExpr pointer %arrayidx15 = getelementptr inbounds float* %c, i64 %add8 SCEV: ((4 * %add8)<nsw> + %c)<nsw>
> LV: Src Scev: ((4 * %add2)<nsw> + %c)<nsw>Sink Scev: ((4 * %add8)<nsw> + %c)<nsw>(Induction step: 0)
> LV: Distance for store float %add10, float* %arrayidx11, align 4 to store float %add14, float* %arrayidx15, align 4: ((4 * %add8)<nsw> + (-4 * %add2))
> Non-consecutive pointer access
> LV: We don't need a runtime memory check.
> LV: Can't vectorize due to memory conflicts
> LV: Not vectorizing.
>
>...
2013 Oct 30
0
[LLVMdev] loop vectorizer
...d2 = or i64 %mul, %rem
>> %add8 = or i64 %add2, 4
>> %arrayidx = getelementptr inbounds float* %a, i64 %add2
>> %0 = load float* %arrayidx, align 4
>> %arrayidx9 = getelementptr inbounds float* %b, i64 %add2
>> %1 = load float* %arrayidx9, align 4
>> %add10 = fadd float %0, %1
>> %arrayidx11 = getelementptr inbounds float* %c, i64 %add2
>> store float %add10, float* %arrayidx11, align 4
>> %arrayidx12 = getelementptr inbounds float* %a, i64 %add8
>> %2 = load float* %arrayidx12, align 4
>> %arrayidx13 = geteleme...
2017 Feb 13
2
RFC: Representing unions in TBAA
...* getelementptr inbounds (%struct.Q, %struct.Q* @q,
i32 0, i32 0), align 4, !tbaa !13
%conv7 = sitofp i32 %7 to float
%add8 = fadd float %add6, %conv7
%8 = load i32, i32* getelementptr inbounds (%struct.R, %struct.R* @r,
i32 0, i32 1), align 4, !tbaa !15
%conv9 = sitofp i32 %8 to float
%add10 = fadd float %add8, %conv9
%conv11 = fptosi float %add10 to i32
ret i32 %conv11
}
!0 = !{i32 1, !"PIC Level", i32 2}
!1 = !{!"clang version 4.0.0 (trunk 290896)"}
!2 = !{!3, !3, i64 0}
!3 = !{!"int", !4, i64 0}
!4 = !{!"omnipotent char", !5, i64 0}
!5 =...
2012 Jul 15
0
[LLVMdev] Issue with Machine Verifier and earlyclobber
...loat %add2) nounwind readnone
%mul4 = fmul float %sub, %call
%mul5 = fmul float %days, 0x3E27C04CA0000000
%sub6 = fsub float 0x3F94790B80000000, %mul5
%mul7 = fmul float %add2, 2.000000e+00
%call8 = tail call float @dsin(float %mul7) nounwind readnone
%mul9 = fmul float %sub6, %call8
%add10 = fadd float %mul4, %mul9
%add11 = fadd float %add, %add10
%mul12 = fmul float %days, 0x3E13C5B640000000
%sub13 = fsub float 0x3F911C1180000000, %mul12
%mul14 = fmul float %add, 2.000000e+00
%call15 = tail call float @dsin(float %mul14) nounwind readnone
%mul16 = fmul float %call15, 0x3...
2012 Jul 15
2
[LLVMdev] Issue with Machine Verifier and earlyclobber
On Jul 15, 2012, at 9:20 AM, Borja Ferrer <borja.ferav at gmail.com> wrote:
> Jakob, one more hint, I've placed some asserts around the code you added and noticed that the InlineSpiller::insertReload() function is not being called.
>
> 2012/7/14 Borja Ferrer <borja.ferav at gmail.com>
> Hello Jakob,
>
> I'm still getting the error, I can give you any other
2012 Nov 11
2
[LLVMdev] problem trying to write an LLVM register-allocation pass
Hi Susan,
It looks like the bitcode you have attached is corrupted. You should make
sure to attach it as a binary file. Alternatively you can attach the LLVM
assembly as text. You can generate an assembly file from bitcode with:
llvm-dis -o <asm file> <bitcode>
Regards,
Lang.
On Fri, Nov 9, 2012 at 11:15 AM, Susan Horwitz <horwitz at cs.wisc.edu> wrote:
> Thanks Lang,
2012 Nov 11
0
[LLVMdev] problem trying to write an LLVM register-allocation pass
...x.0, 5
%mul = mul nsw i32 %x.0, 2
%sub = sub nsw i32 %mul, 1
%mul3 = mul nsw i32 %add, %sub
%add4 = add nsw i32 %x.0, %mul3
%div5 = sdiv i32 %add4, %x.0
%add6 = add nsw i32 5, %add
%sub7 = sub nsw i32 %div5, %add6
%add8 = add nsw i32 %add4, %sub7
%add9 = add nsw i32 %add8, %x.0
%add10 = add nsw i32 %add9, %add
%add11 = add nsw i32 %add10, %sub
%call12 = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([37 x i8]* @.str1, i32 0, i32 0), i32 %add4, i32 %sub7, i32 %add11, i32 %x.0, i32 %add, i32 %sub)
ret i32 0
}
declare i32 @rand() nounwind
declare i32 @printf(i8*,...