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 http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://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).http://llvm.org/bugs/show_bug.cgi?id=8961
Reasonably Related 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