search for: mul16

...= load i8* %incdec.ptr11, align 1, !tbaa !0 BBV: selected pair: %conv14 = zext i8 %0 to i32 <-> %conv15 = zext i8 %1 to i32 BBV: selected pair: %add26 = add i32 %mul25, %mul23 <-> %add36 = add i32 %mul35, %mul33 BBV: selected pair: %mul = mul nsw i32 %conv14, 123 <-> %mul16 = mul nsw i32 %conv15, 321 BBV: selected pair: %conv30 = trunc i32 %add29 to i8 <-> %conv40 = trunc i32 %add39 to i8 BBV: selected pair: %mul25 = mul nsw i32 %conv15, 432 <-> %mul33 = mul nsw i32 %conv14, 345 BBV: selected pair: %add29 = add i32 %add26, %mul28 <-> %add...

On Thu, 2012-01-26 at 15:12 -0600, Sebastian Pop wrote: > On Thu, Jan 26, 2012 at 2:49 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > Thanks! Did you compile with any non-default flags other than -mllvm > > -vectorize? > > I used -O3 and -vectorize, no other non-default flags. If I run clang -O3 -mllvm -vectorize -S -emit-llvm -o test.ll test.c then I get no

...ul 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, 0x3FF1F736C0000000 %mul17 = fmul float %sub13, 2.000000e+00 %mul19 = fmul float %mul17, %call %sub20 = fsub float %mul16, %mul19 %mul21 = fmul float %sub13, 4.000000e+00 %mul22 = fmul float %mul21, 0x3FF1F736C0000000 %mul24 = fmul float %mul22, %call %call26 = ta...

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

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

On Thu, Jan 26, 2012 at 3:41 PM, Hal Finkel <hfinkel at anl.gov> wrote: > On Thu, 2012-01-26 at 15:36 -0600, Sebastian Pop wrote: >> arm-none-linux-gnueabi > > Indeed, adding -ccc-host-triple arm-none-linux-gnueabi I also get Minor remark: please use -target instead of -ccc-host-triple that is now deprecated. Thanks for looking at this testcase. Sebastian -- Qualcomm

On Thu, 2012-01-26 at 15:36 -0600, Sebastian Pop wrote: > arm-none-linux-gnueabi Indeed, adding -ccc-host-triple arm-none-linux-gnueabi I also get vectorization (even though I don't get vectorization when targeting x86_64). I'll let you know what I find. -Hal -- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory

...x6 = getelementptr inbounds double* %c, i64 1 > + %i5 = load double* %arrayidx6, align 8 > + %add7 = fadd double %mul5, %i5 > + %mul9 = fmul double %add, %i1 > + %add11 = fadd double %mul9, %i2 > + %mul13 = fmul double %add7, %i4 > + %add15 = fadd double %mul13, %i5 > + %mul16 = fmul double %add11, %add15 > + ret double %mul16 > +; CHECK: @test1 > +; CHECK:<2 x double> For me this CHECK looks very short. Should all instructions be vectorized or is it sufficient if one is vectorized. Also, it would be nice if I could understand the code that is generated...

...%c, i64 1 > > + %i5 = load double* %arrayidx6, align 8 > > + %add7 = fadd double %mul5, %i5 > > + %mul9 = fmul double %add, %i1 > > + %add11 = fadd double %mul9, %i2 > > + %mul13 = fmul double %add7, %i4 > > + %add15 = fadd double %mul13, %i5 > > + %mul16 = fmul double %add11, %add15 > > + ret double %mul16 > > +; CHECK: @test1 > > +; CHECK:<2 x double> > > For me this CHECK looks very short. Should all instructions be > vectorized or is it sufficient if one is vectorized. Also, it would be > nice if I could und...

On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > > Tobias, > > > > I've attached an updated patch. It contains a few bug fixes and many > > (refactoring and coding-convention) changes inspired by your comments. > > > > I'm currently trying to fix the bug responsible for causing a compile

...%c, i64 1 > > + %i5 = load double* %arrayidx6, align 8 > > + %add7 = fadd double %mul5, %i5 > > + %mul9 = fmul double %add, %i1 > > + %add11 = fadd double %mul9, %i2 > > + %mul13 = fmul double %add7, %i4 > > + %add15 = fadd double %mul13, %i5 > > + %mul16 = fmul double %add11, %add15 > > + ret double %mul16 > > +; CHECK: @test1 > > +; CHECK:<2 x double> > > For me this CHECK looks very short. Should all instructions be > vectorized or is it sufficient if one is vectorized. Also, it would be > nice if I could und...

On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > Tobias, > > I've attached an updated patch. It contains a few bug fixes and many > (refactoring and coding-convention) changes inspired by your comments. > > I'm currently trying to fix the bug responsible for causing a compile > failure when compiling >