[LLVMdev] Wrong assembly is written for x86_64 target in JIT without optimization?
Dale Johannesen
dalej at apple.com
Tue Jan 11 17:07:59 PST 2011
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.
>
> Yuri
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 ---
> %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>
More information about the llvm-dev
mailing list