search for: i64

...rontend/2008-01-25- ByValReadNone.c Failed with exit(1) at line 1 while running: /Users/wendling/llvm/llvm-gcc-4.2.install/bin/llvm-gcc -emit-llvm -O3 -S -o - -emit-llvm /Users/wendling/llvm/llvm.src/test/ CFrontend/2008-01-25-ByValReadNone.c | not grep readonly %tmp1505 = call i32 @g( i64 %x.0.0, i64 %x.0.1, i64 %x.0.2, i64 %x.0.3, i64 %x.0.4, i64 %x.0.5, i64 %x.0.6, i64 %x.0.7, i64 %x. 0.8, i64 %x.0.9, i64 %x.0.10, i64 %x.0.11, i64 %x.0.12, i64 %x.0.13, i64 %x.0.14, i64 %x.0.15, i64 %x.0.16, i64 %x.0.17, i64 %x.0.18, i64 % x.0.19, i64 %x.0.20, i64 %x.0.21, i64 %x.0.22, i64 %x...

...here is something going wrong earlier. I am wondering why it's reproducible and depending on the IR?! PS When running with -O3 it still find 256 bit, but later decides that it's not worth vectorizing. Frank target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-elf" define void @main(i64 %arg0, i64 %arg1, i64 %arg2, i1 %arg3, i64 %arg4, float* noalias %arg5, float* noalias %arg6, float* noalias %arg7, dou...

...'s reproducible and depending on the IR?! > > PS When running with -O3 it still find 256 bit, but later decides that > it's not worth > vectorizing. > > Frank > > > > > > > target datalayout = > "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128" > > target triple = "x86_64-unknown-linux-elf" > > define void @main(i64 %arg0, i64 %arg1, i64 %arg2, i1 %arg3, i64 > %arg4, float* noalias %arg5, float* noalias %arg6, flo...

...>> PS When running with -O3 it still find 256 bit, but later decides that >> it's not worth >> vectorizing. >> >> Frank >> >> >> >> >> >> >> target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8- >> i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64- >> v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128" >> >> target triple = "x86_64-unknown-linux-elf" >> >> define void @main(i64 %arg0, i64 %arg1, i64 %arg2, i1 %arg3, i64 %arg4, >> float* noalias %ar...

...on with my back end with the following basic-block due to a vector add with immediate constant vector (obtained by vectorizing a simple C program doing vector sum map): vector.ph: ; preds = %vector.memcheck50 %.splatinsert = insertelement <8 x i64> undef, i64 %i.07.unr, i32 0 %.splat = shufflevector <8 x i64> %.splatinsert, <8 x i64> undef, <8 x i32> zeroinitializer %induction = add <8 x i64> %.splat, <i64 0, i64 1, i64 2, i64 3, i64 4, i64 5, i64 6, i64 7> %.splatinsert56 = inserteleme...

...ecessary target instruction - as can be seen at the bottom. I would appreciate any input on this, and if needed I can supply a test case. /Jonas Loop before vectorize pass: while.body320: ; preds = %while.body320.preheader, %while.body320 %dl.0291 = phi i64* [ %incdec.ptr335, %while.body320 ], [ %73, %while.body320.preheader ] %ll.0290 = phi i64* [ %incdec.ptr332, %while.body320 ], [ %74, %while.body320.preheader ] %rl.0289 = phi i64* [ %incdec.ptr333, %while.body320 ], [ %75, %while.body320.preheader ] %len.0288 = phi i32 [ %dec, %while.b...

...> > PS When running with -O3 it still find 256 bit, but later > decides that it's not worth > vectorizing. > > Frank > > > > > > > target datalayout = > "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128" > > target triple = "x86_64-unknown-linux-elf" > > define void @main(i64 %arg0, i64 %arg1, i64 %arg2, i1 %arg3, > i64 %arg4, float* noalias %arg5, fl...

The following IR implements the following nested loop: for (int i = start ; i < end ; ++i ) for (int p = 0 ; p < 4 ; ++p ) a[i*4+p] = b[i*4+p] + c[i*4+p]; define void @main(i64 %arg0, i64 %arg1, i1 %arg2, i64 %arg3, float* noalias %arg4, float* noalias %arg5, float* noalias %arg6) { entrypoint: br i1 %arg2, label %L0, label %L1 L0: ; preds = %entrypoint %0 = add nsw i64 %arg0, %arg3 %1 = add nsw i64 %arg1, %arg3...

We've recently moved our project from LLVM 3.6 to LLVM 3.9. I noticed one of our code generation tests is breaking in 3.9. The test is: ; RUN: llc < %s -march=xstg | FileCheck %s define i64 @bclr64(i64 %a, i64 %b) nounwind readnone { entry: ; CHECK: bclr r1, r0, r1, 64 %sub = sub i64 %b, 1 %shl = shl i64 1, %sub %xor = xor i64 %shl, -1 %and = and i64 %a, %xor ret i64 %and } I ran llc with -debug to get a better idea of what's going on and found: Initial selection D...

Is there any way to get it to delay this optimization where it goes from this: Initial selection DAG: BB#0 'bclr64:entry' SelectionDAG has 14 nodes: t0: ch = EntryToken t2: i64,ch = CopyFromReg t0, Register:i64 %vreg0 t4: i64,ch = CopyFromReg t0, Register:i64 %vreg1 t6: i64 = sub t4, Constant:i64<1> t7: i64 = shl Constant:i64<1>, t6 t9: i64 = xor t7, Constant:i64<-1> t10: i64 = and t2, t9 t12: ch,glue = CopyToReg...

...at 8:15 AM, Frank Winter <fwinter at jlab.org> wrote: > The following IR implements the following nested loop: > > for (int i = start ; i < end ; ++i ) > for (int p = 0 ; p < 4 ; ++p ) > a[i*4+p] = b[i*4+p] + c[i*4+p]; > > > > > define void @main(i64 %arg0, i64 %arg1, i1 %arg2, i64 %arg3, float* noalias %arg4, float* noalias %arg5, float* noalias %arg6) { > entrypoint: > br i1 %arg2, label %L0, label %L1 > > L0: ; preds = %entrypoint > %0 = add nsw i64 %arg0, %arg3 > %1 = add n...

...*and* bitcast (!!) etc. instructions left? The original loop is so clean, a textbook example I'd say. There is no need to shuffle anything.At least I don't see it. Frank vector.ph: ; preds = %L5 %broadcast.splatinsert1 = insertelement <4 x i64> undef, i64 %19, i32 0 %broadcast.splat2 = shufflevector <4 x i64> %broadcast.splatinsert1, <4 x i64> undef, <4 x i32> zeroinitializer br label %vector.body vector.body: ; preds = %vector.body, %vector.ph %index = phi i64 [ 0, %v...

Hi, guys! I write a virtual machine which uses LLVM as back-end code generator. The following function code causes strange "UNREACHABLE executed!" error: define void @p1(%1*) { %2 = call i8* @llvm.stacksave() %3 = alloca %0 %4 = getelementptr %0* %3, i64 1 %5 = ptrtoint %0* %3 to i64 %6 = ptrtoint %0* %4 to i64 %7 = sub i64 %6, %5 %8 = bitcast %0* %3 to i8* call void @llvm.memset.p0i8.i64(i8* %8, i8 0, i64 %7, i32 0, i1 false) %9 = bitcast %1* %0 to [8 x i8]* %10 = bitcast %0* %3 to [8 x i8]* %11 = load [8 x i8]* %9 store [8 x i8]...

...phil.a.tomson at gmail.com> > wrote: > >> Is there any way to get it to delay this optimization where it goes from >> this: >> >> Initial selection DAG: BB#0 'bclr64:entry' >> SelectionDAG has 14 nodes: >> t0: ch = EntryToken >> t2: i64,ch = CopyFromReg t0, Register:i64 %vreg0 >> t4: i64,ch = CopyFromReg t0, Register:i64 %vreg1 >> t6: i64 = sub t4, Constant:i64<1> >> t7: i64 = shl Constant:i64<1>, t6 >> t9: i64 = xor t7, Constant:i64<-1> >> t10...

...= 1, ny do j = 1, nz B(i, j) = (1 + mod((i * j), 1024)) / 2.0 enddo enddo end subroutine init_array end subroutine matmul > kernelgen-dragonegg matmul.f90 -o - ; ModuleID = 'matmul.f90' target datalayout = "e-p:64:64:64-S128-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f16:16:16-f32:32:32-f64:64:64-f128:128:128-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" target triple = "x86_64-unknown-linux-gnu" %struct.FRAME.matmul = type { i64, i64, [0 x float]*, i64, i64, i32*, i64, i64, [0 x float]*, i64, i64, i32*, i32* } %struct._...

...test ToT version of llvm or you run -loop-vectorize -earlycse -instcombine -simplifycfg The bitcast essentially is a noop to satisfy the type system. This is how your example looks like for me: vector.body: ; preds = %vector.body, %vector.ph %index = phi i64 [ 0, %vector.ph ], [ %index.next, %vector.body ] %.lhs = shl i64 %6, 2 %7 = add i64 %.lhs, %index %8 = getelementptr float* %arg5, i64 %7 %9 = bitcast float* %8 to <4 x float>* %wide.load = load <4 x float>* %9, align 16 %10 = getelementptr float* %arg6, i64 %7 %11 = bitca...

...ngSetNodeID. 3) Something else I haven't considered. I have a patch posted implementing 2, but don't know if I should look at fixing 1 as well (or perhaps instead). The loads that trigger the assertion are: t47: v4i32,ch = load<LD16[%0+80](align=8)(dereferenceable)> t20, t46, undef:i64 t69: v4i32,ch = load<LD16[FixedStack1+80](align=8)> t50, t46, undef:i64 I would expect the the second load should also be marked dereferenceable since its loading from one of the TargetFrames. Am I on the right track here? Thanks Sean -------------- next part -------------- Initial selectio...

...j), 1024)) / 2.0 > enddo > enddo > > end subroutine init_array > > end subroutine matmul > > > kernelgen-dragonegg matmul.f90 -o - > > ; ModuleID = 'matmul.f90' > target datalayout = > "e-p:64:64:64-S128-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f16:16:16-f32:32:32-f64:64:64-f128:128:128-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" > target triple = "x86_64-unknown-linux-gnu" > > %struct.FRAME.matmul = type { i64, i64, [0 x float]*, i64, i64, i32*, i64, > i64, [0 x float]*, i64, i64, i32...

...gt; > Is there any way to get it to delay this optimization where > it goes from this: > > Initial selection DAG: BB#0 'bclr64:entry' > SelectionDAG has 14 nodes: > t0: ch = EntryToken > t2: i64,ch = CopyFromReg t0, Register:i64 %vreg0 > t4: i64,ch = CopyFromReg t0, Register:i64 %vreg1 > t6: i64 = sub t4, Constant:i64<1> > t7: i64 = shl Constant:i64<1>, t6 > t9: i64 = xor t7, Constan...

...eclare noalias %u8XY* @likely_new(i32 zeroext, i32 zeroext, i32 zeroext, i32 zeroext, i32 zeroext, i8* noalias nocapture) #0 ; Function Attrs: nounwind declare void @llvm.assume(i1) #1 ; Function Attrs: nounwind define %u8XY* @benchmark(%u8XY*) #1 { entry: %1 = getelementptr inbounds %u8XY* %0, i64 0, i32 3 %columns = load i32* %1, align 4, !range !0 %2 = getelementptr inbounds %u8XY* %0, i64 0, i32 4 %rows = load i32* %2, align 4, !range !0 %3 = tail call %u8XY* @likely_new(i32 24584, i32 1, i32 %columns, i32 %rows, i32 1, i8* null) %4 = zext i32 %rows to i64 %dst_y_step = zext i...