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

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).

http://llvm.org/bugs/show_bug.cgi?id=8961