search for: i192

Hi all, opt and opt + llc generate the difference aarch64 asm code for the following LLVM code. Is it intended behavior? I expected (A) because I cast %p from i192* to i64*. The information is dropped by opt and 8-byte padding is inserted or I write a bad code? % cat a.ll define void @store0_to_p4(i192* %p) { %p1 = bitcast i192* %p to i64* %p2 = getelementptr i64, i64* %p1, i64 3 %p3 = getelementptr i64, i64* %p2, i64 1 store i64 0, i64* %p3 ret vo...

Hello all! I'm working on a library with bignum support, and I wanted to try LLVM as an apparently simpler and more portable system to my current design (a Haskell script which spits out mixed C and assembly). Porting the script to use the LLVM bindings instead of the current hack was pretty easy. But I have a few remaining questions: (1) Are bignums exposed to any higher-level

...t 04:29, MITSUNARI Shigeo via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>Is your default target aarch64? Otherwise opt may be assuming a different >>target which might explain the difference. > > No, My target is x86-64, x86, arm, aarch64, ..., then I'll avoid using i192* and datalayout. I believe Tom's point was about the line: % opt-3.8 -O3 a.ll -o - | llc-3.8 -O3 -o - -march=aarch64 If your host is x86_64, then the first call to opt will assume x86_64 unless you have a triple in the IR (which I believe you didn't). You can override with: % opt-3.8 -...

...orized code and relying directly on LLVM for wider-than-legal types: http://llvm.org/bugs/show_bug.cgi?id=20011 (crash with <2 x i2>) http://llvm.org/bugs/show_bug.cgi?id=20012 (error when storing <2 x i4>) http://llvm.org/bugs/show_bug.cgi?id=19797 (assert failure on multiplication of i192) http://llvm.org/bugs/show_bug.cgi?id=20921 (assert failure on stores and loads of i193) http://llvm.org/bugs/show_bug.cgi?id=21184 (miscompilation of wider-than-legal types) I would *really* wish that the documentation made sure to mention, that wider-than-legal types are not expected to work....

...mp.i185 = mul i32 %conv44, 298 %mul17.i186 = mul nsw i32 %sub6.i184, 459 %add18.i187 = add i32 %tmp.i185, -4640 %add19.i188 = add i32 %mul17.i186, %add18.i187 %shr.i189 = ashr i32 %add19.i188, 8 %mul26.i190 = mul nsw i32 %sub.i183, -55 %mul30.i191 = mul nsw i32 %sub6.i184, -136 %add31.i192 = add i32 %add18.i187, %mul26.i190 %add32.i193 = add i32 %add31.i192, %mul30.i191 %shr33.i194 = ashr i32 %add32.i193, 8 %mul40.i195 = mul nsw i32 %sub.i183, 541 %add46.i196 = add i32 %add18.i187, %mul40.i195 %shr47.i197 = ashr i32 %add46.i196, 8 store i32 %tmp, i32* %x139, align 4, !tba...

...128 %tmp.i185 = mul i32 %conv44, 298 %mul17.i186 = mul nsw i32 %sub6.i184, 459 %add18.i187 = add i32 %tmp.i185, -4640 %add19.i188 = add i32 %mul17.i186, %add18.i187 %shr.i189 = ashr i32 %add19.i188, 8 %mul26.i190 = mul nsw i32 %sub.i183, -55 %mul30.i191 = mul nsw i32 %sub6.i184, -136 %add31.i192 = add i32 %add18.i187, %mul26.i190 %add32.i193 = add i32 %add31.i192, %mul30.i191 %shr33.i194 = ashr i32 %add32.i193, 8 %mul40.i195 = mul nsw i32 %sub.i183, 541 %add46.i196 = add i32 %add18.i187, %mul40.i195 %shr47.i197 = ashr i32 %add46.i196, 8 store i32 %tmp, i32* %x139, align 4, !tbaa !2...

...at %tmp7.i163.i, %tmp30.i186.i > %tmp32.i188.i = fadd float %tmp31.i187.i, 0x3FFC80EF00000000 > %tmp33.i189.i = fmul float %tmp7.i163.i, %tmp32.i188.i > %tmp34.i190.i = fadd float %tmp33.i189.i, 0xBFD6D1F0E0000000 > %tmp35.i191.i = fmul float %tmp7.i163.i, %tmp34.i190.i > %tmp36.i192.i = fadd float %tmp35.i191.i, 0x3FD470BF40000000 > %tmp37.i193.i = fmul float %tmp19.i175.i, %tmp36.i192.i > %tmp38.i194.i = fsub float 1.000000e+00, %tmp37.i193.i > %cmp.i197.i = fcmp olt float %tmp11.i29.i, 0.000000e+00 > br i1 %cmp.i197.i, label %cond.then.i201.i, label %entry.he...

Hi everyone! Here, I have a question and am curious about i128. I want to know how the LLVM handle i128, because many compiler backend doesn't support i128 directly. So I am very curious and want to how the llvm handle this situation? Besides i128, such as i256, i512, even i24? Thanks. Best Regards Wu Zhao -------------- next part -------------- An HTML attachment was scrubbed...

Hello everybody, I have stumbled upon a test case (the attached module is a slightly reduced version) that shows extremely reduced performance on linux compared to windows when executed using LLVM's JIT. We narrowed the problem down to the actual code being generated, the source IR on both systems is the same. Try compiling the attached module: llc -O3 -filetype=asm -o BAD.s BAD.ll Under

...; preds = %CF242, %CF250, %CF248, %CF236 %L189 = load i8, i8* %0 store i8 %Sl29, i8* %0 %E190 = extractelement <4 x i16> %B9, i32 3 %Shuff191 = shufflevector <4 x i16> %Shuff26, <4 x i16> %Shuff26, <4 x i32> <i32 6, i32 0, i32 2, i32 4> %I192 = insertelement <1 x i32> %I122, i32 %3, i32 0 %B193 = udiv i8 %5, %L168 %Se194 = sext <8 x i1> %Sl71 to <8 x i32> %Sl195 = select i1 %Cmp188, i8 %L182, i8 %L168 %Cmp196 = icmp slt i16 %B77, %Sl102 br i1 %Cmp196, label %CF242, label %CF250 CF250:...

...store i16 %storemerge.i187.i, i16* %x.addr.023.i173.i, align 2 %shl14.i188.i = shl nuw nsw i32 %conv5.i183.i, 1 %conv15.i189.i = trunc i32 %shl14.i188.i to i16 %incdec.ptr.i190.i = getelementptr inbounds i16* %x.addr.023.i173.i, i32 -1 %inc.i191.i = add nsw i32 %i.025.i171.i, 1 %exitcond.i192.i = icmp eq i32 %inc.i191.i, 13 br i1 %exitcond.i192.i, label %eshup1.exit194.i, label %for.body.i175.i eshup1.exit194.i: ; preds = %if.end.i193.i %54 = load i16* %incdec.ptr1.1.i.i, align 2, !tbaa !5 %cmp205.i = icmp eq i16 %54, 0 br i1 %cmp205.i, label %if...