Yuri
2011-Jan-12 00:50 UTC
[LLVMdev] Wrong assembly is written for x86_64 target in JIT without optimization?
When I try running one llvm function in JIT without optimization I get SEGV. Looking at assembly (below) I see that the local value 0xffffffffffffffe0(%rbp) is used without being ever initialized (see my comment in asm). Same code on i386 works fine, with and w/out optimization. My guess is that this is a bug in LLVM. Yuri --- llvm --- %struct.mystruct = type { i32, i8, i8, i8, i8 } define i32 @xfunc(%struct.mystruct* %a1, %struct.mystruct* %a2) { br label %lbl1 lbl1: %v1 = call i32 @yfunc(i32 1, i32 0, i32 0) %v2 = bitcast %struct.mystruct* %a1 to i8* %v3 = getelementptr i8* %v2, i32 %v1 %v4 = bitcast i8* %v3 to i32* %v5 = load i32* %v4 %v6 = call i32 @yfunc(i32 1, i32 4, i32 0) %v7 = bitcast %struct.mystruct* %a2 to i8* %v8 = getelementptr i8* %v7, i32 %v6 %v9 = bitcast i8* %v8 to i32* %v10 = load i32* %v9 %op.dual.plus.uint32 = add i32 %v5, %v10 br label %lbl2 lbl2: ret i32 %op.dual.plus.uint32 } declare i32 @yfunc(i32, i32, i32) --- assembly obtained in gdb for JITted code --- 0x0000000800989bf0: push %rbp 0x0000000800989bf1: mov %rsp,%rbp 0x0000000800989bf4: sub $0x30,%rsp 0x0000000800989bf8: mov %rdi,0xfffffffffffffff8(%rbp) 0x0000000800989bfc: mov %rsi,0xfffffffffffffff0(%rbp) 0x0000000800989c00: mov $0x1,%edi 0x0000000800989c05: xor %eax,%eax 0x0000000800989c07: mov $0x800a09060,%rcx 0x0000000800989c11: mov %eax,%esi 0x0000000800989c13: mov %eax,%edx 0x0000000800989c15: callq *%ecx 0x0000000800989c17: movslq %eax,%rcx 0x0000000800989c1a: mov 0xfffffffffffffff8(%rbp),%r8 0x0000000800989c1e: mov (%r8,%rcx,1),%eax 0x0000000800989c22: mov $0x1,%edi 0x0000000800989c27: mov $0x4,%esi 0x0000000800989c2c: xor %edx,%edx 0x0000000800989c2e: mov $0x800a09060,%rcx 0x0000000800989c38: mov %eax,0xffffffffffffffec(%rbp) 0x0000000800989c3b: callq *%ecx 0x0000000800989c3d: mov 0xffffffffffffffec(%rbp),%edx 0x0000000800989c40: mov 0xfffffffffffffff0(%rbp),%rcx 0x0000000800989c44: mov 0xffffffffffffffe0(%rbp),%r8 ; XXX use of uninitialized value 0x0000000800989c48: add (%rcx,%r8,1),%edx ; SEGV 0x0000000800989c4c: movslq %eax,%r8 0x0000000800989c4f: mov %edx,0xffffffffffffffdc(%rbp) 0x0000000800989c52: mov %r8,0xffffffffffffffe0(%rbp) 0x0000000800989c56: mov 0xffffffffffffffdc(%rbp),%eax 0x0000000800989c59: add $0x30,%rsp 0x0000000800989c5d: pop %rbp 0x0000000800989c5e: retq --- result after running llvm-as and llc on the same function --- subq $56, %rsp .Ltmp0: movq %rdi, 48(%rsp) # 8-byte Spill movq %rsi, 40(%rsp) # 8-byte Spill # BB#1: # %lbl1 movl $1, %eax movl $4, %esi movl $0, %ecx movl %eax, %edi movl %esi, 36(%rsp) # 4-byte Spill movl %ecx, %esi movl %ecx, %edx movl %eax, 32(%rsp) # 4-byte Spill movl %ecx, 28(%rsp) # 4-byte Spill callq yfunc movslq %eax, %r8 movq 48(%rsp), %r9 # 8-byte Reload movl (%r9,%r8), %eax movl 32(%rsp), %edi # 4-byte Reload movl 36(%rsp), %esi # 4-byte Reload movl 28(%rsp), %edx # 4-byte Reload movl %eax, 24(%rsp) # 4-byte Spill callq yfunc movl 24(%rsp), %ecx # 4-byte Reload movq 40(%rsp), %r8 # 8-byte Reload movq 16(%rsp), %r9 # 8-byte Reload addl (%r8,%r9), %ecx movslq %eax, %r9 movl %ecx, 12(%rsp) # 4-byte Spill movq %r9, 16(%rsp) # 8-byte Spill # BB#2: # %lbl2 movl 12(%rsp), %eax # 4-byte Reload addq $56, %rsp ret
Dale Johannesen
2011-Jan-12 01:07 UTC
[LLVMdev] Wrong assembly is written for x86_64 target in JIT without optimization?
On Jan 11, 2011, at 4:50 PMPST, Yuri wrote:> When I try running one llvm function in JIT without optimization I get > SEGV. Looking at assembly (below) I see that the local value > 0xffffffffffffffe0(%rbp) is used without being ever initialized (see my > comment in asm). > Same code on i386 works fine, with and w/out optimization. > > My guess is that this is a bug in LLVM. > > YuriThe unitialized load is there in the llc version as well (16(%rsp)). It looks like it's been erroneously moved ahead of the spill to that slot. Please file a PR. (I can see this on Darwin with llc -O0).> --- llvm --- > %struct.mystruct = type { i32, i8, i8, i8, i8 } > > define i32 @xfunc(%struct.mystruct* %a1, %struct.mystruct* %a2) { > br label %lbl1 > lbl1: > %v1 = call i32 @yfunc(i32 1, i32 0, i32 0) > %v2 = bitcast %struct.mystruct* %a1 to i8* > %v3 = getelementptr i8* %v2, i32 %v1 > %v4 = bitcast i8* %v3 to i32* > %v5 = load i32* %v4 > %v6 = call i32 @yfunc(i32 1, i32 4, i32 0) > %v7 = bitcast %struct.mystruct* %a2 to i8* > %v8 = getelementptr i8* %v7, i32 %v6 > %v9 = bitcast i8* %v8 to i32* > %v10 = load i32* %v9 > %op.dual.plus.uint32 = add i32 %v5, %v10 > br label %lbl2 > lbl2: > ret i32 %op.dual.plus.uint32 > } > > declare i32 @yfunc(i32, i32, i32) > > > --- assembly obtained in gdb for JITted code --- > 0x0000000800989bf0: push %rbp > 0x0000000800989bf1: mov %rsp,%rbp > 0x0000000800989bf4: sub $0x30,%rsp > 0x0000000800989bf8: mov %rdi,0xfffffffffffffff8(%rbp) > 0x0000000800989bfc: mov %rsi,0xfffffffffffffff0(%rbp) > 0x0000000800989c00: mov $0x1,%edi > 0x0000000800989c05: xor %eax,%eax > 0x0000000800989c07: mov $0x800a09060,%rcx > 0x0000000800989c11: mov %eax,%esi > 0x0000000800989c13: mov %eax,%edx > 0x0000000800989c15: callq *%ecx > 0x0000000800989c17: movslq %eax,%rcx > 0x0000000800989c1a: mov 0xfffffffffffffff8(%rbp),%r8 > 0x0000000800989c1e: mov (%r8,%rcx,1),%eax > 0x0000000800989c22: mov $0x1,%edi > 0x0000000800989c27: mov $0x4,%esi > 0x0000000800989c2c: xor %edx,%edx > 0x0000000800989c2e: mov $0x800a09060,%rcx > 0x0000000800989c38: mov %eax,0xffffffffffffffec(%rbp) > 0x0000000800989c3b: callq *%ecx > 0x0000000800989c3d: mov 0xffffffffffffffec(%rbp),%edx > 0x0000000800989c40: mov 0xfffffffffffffff0(%rbp),%rcx > 0x0000000800989c44: mov 0xffffffffffffffe0(%rbp),%r8 ; XXX > use of uninitialized value > 0x0000000800989c48: add (%rcx,%r8,1),%edx ; SEGV > 0x0000000800989c4c: movslq %eax,%r8 > 0x0000000800989c4f: mov %edx,0xffffffffffffffdc(%rbp) > 0x0000000800989c52: mov %r8,0xffffffffffffffe0(%rbp) > 0x0000000800989c56: mov 0xffffffffffffffdc(%rbp),%eax > 0x0000000800989c59: add $0x30,%rsp > 0x0000000800989c5d: pop %rbp > 0x0000000800989c5e: retq > > --- result after running llvm-as and llc on the same function --- > subq $56, %rsp > .Ltmp0: > movq %rdi, 48(%rsp) # 8-byte Spill > movq %rsi, 40(%rsp) # 8-byte Spill > # BB#1: # %lbl1 > movl $1, %eax > movl $4, %esi > movl $0, %ecx > movl %eax, %edi > movl %esi, 36(%rsp) # 4-byte Spill > movl %ecx, %esi > movl %ecx, %edx > movl %eax, 32(%rsp) # 4-byte Spill > movl %ecx, 28(%rsp) # 4-byte Spill > callq yfunc > movslq %eax, %r8 > movq 48(%rsp), %r9 # 8-byte Reload > movl (%r9,%r8), %eax > movl 32(%rsp), %edi # 4-byte Reload > movl 36(%rsp), %esi # 4-byte Reload > movl 28(%rsp), %edx # 4-byte Reload > movl %eax, 24(%rsp) # 4-byte Spill > callq yfunc > movl 24(%rsp), %ecx # 4-byte Reload > movq 40(%rsp), %r8 # 8-byte Reload > movq 16(%rsp), %r9 # 8-byte Reload > addl (%r8,%r9), %ecx > movslq %eax, %r9 > movl %ecx, 12(%rsp) # 4-byte Spill > movq %r9, 16(%rsp) # 8-byte Spill > # BB#2: # %lbl2 > movl 12(%rsp), %eax # 4-byte Reload > addq $56, %rsp > ret > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu llvm.cs.uiuc.edu > lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.llvm.org/pipermail/llvm-dev/attachments/20110111/f9ee4e32/attachment.html>
Yuri
2011-Jan-12 02:20 UTC
[LLVMdev] Wrong assembly is written for x86_64 target in JIT without optimization?
On 01/11/2011 17:07, Dale Johannesen wrote:> The unitialized load is there in the llc version as well (16(%rsp)). > It looks like it's been erroneously moved ahead of the spill to that > slot. Please file a PR. (I can see this on Darwin with llc -O0).llvm.org/bugs/show_bug.cgi?id=8961
Maybe Matching Threads
- [LLVMdev] Wrong assembly is written for x86_64 target in JIT without optimization?
- [LLVMdev] Missed optimization opportunity in 3-way integer comparison case
- Hmisc label function applied to data frame
- extensions.conf gotoif and label
- [LLVMdev] llvm linking issue