LLVM's llc generates seemly incorrect code

Question

I'm writing a function pass in LLVM, which generates IR file. The problem is that the assembled code does not seem to behave as I expect. Since I'm pretty new to LLVM, I'd like to know if I misunderstood the LLVM IR semantics or this is an incorrect behavior of llc.

The LLVM IR is:

define void @fff(i32*) #0 {
  %2 = alloca i32*, align 8
  %3 = alloca i32, align 4
  %4 = load i8*, i8** @dirty
  br label %5

; <label>:5:                                      ; preds = %1
  store i32* %0, i32** %2, align 8
  %6 = load i32*, i32** %2, align 8
  %7 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([11 x i8], [11 x i8]* @.str.4, i32 0, i32 0), i32* %6)
  %8 = load i32*, i32** %2, align 8
  %9 = load i32, i32* %8, align 4
  %readDirty = load atomic i8, i8* %4 acquire, align 8
  %10 = icmp eq i8 %readDirty, 1
  br i1 %10, label %Restart, label %11, !prof !3

; <label>:11:                                     ; preds = %5
  store i32 %9, i32* %3, align 4
  ret void

Restart:                                          ; preds = %5
  ;EDIT: bug was here. Must include label %5 as a possible destination block
  indirectbr i8* blockaddress(@fff, %5), []
}

This correspond (roughly) to the following C code:

char *dirty=1; 
void fff(int *head) ATTR{
restart:
    printf("head = %p\n", head);
    int r = *head;
    if(*dirty)
        goto restart; //But using indirect branch
}

Next I assemble, link and run using:

llc -filetype=obj simpleOut.ll -o out.o
gcc -o exe out.o
./exe

If I call the function with address 0x7ffeea51d7a8, it prints:

head = 0x7ffeea51d7a8
head = 0x2e889e825bf4005c
Segmentation fault: 11

The x86_64 assembly code is:

;head reside in rcx
100000d60:  55  pushq   %rbp
100000d61:  48 89 e5    movq    %rsp, %rbp
100000d64:  53  pushq   %rbx
100000d65:  48 83 ec 18     subq    $24, %rsp
100000d69:  48 89 f9    movq    %rdi, %rcx
100000d6c:  48 8d 3d dd 02 00 00    leaq    733(%rip), %rdi
100000d73:  ff 17   callq   *(%rdi)
100000d75:  48 8b 18    movq    (%rax), %rbx
100000d78:  48 8d 3d c0 01 00 00    leaq    448(%rip), %rdi
100000d7f:  48 89 4d f0     movq    %rcx, -16(%rbp)
100000d83:  48 8b 75 f0     movq    -16(%rbp), %rsi
100000d87:  b0 00   movb    $0, %al
100000d89:  e8 62 01 00 00  callq   354 ;call to printf, corrupt rcx
100000d8e:  48 8b 45 f0     movq    -16(%rbp), %rax
100000d92:  8b 00   movl    (%rax), %eax
100000d94:  80 3b 01    cmpb    $1, (%rbx)
100000d97:  74 0a   je  10 <_fff+0x43>
100000d99:  89 45 ec    movl    %eax, -20(%rbp)
100000d9c:  48 83 c4 18     addq    $24, %rsp
100000da0:  5b  popq    %rbx
100000da1:  5d  popq    %rbp
100000da2:  c3  retq
100000da3:  48 8d 05 ce ff ff ff    leaq    -50(%rip), %rax
100000daa:  ff e0   jmpq    *%rax ;jumps to 100000d78
100000dac:  0f 1f 40 00     nopl    (%rax)

The problem seems to be that the LLVM statement store i32* %0, i32** %2, align 8 translates to movq %rcx, -16(%rbp) even after the restart, where the register rcx was already corrupted by printf function.

If this seems like a bug I'll file a bug report with LLVM. Just wanted to check that I don't misunderstand the LLVM IR.

llc version is 5.0.0, installed via homebrew. gcc (used for linking) is clang-900.0.39.2.

Thanks

Answer 1

According to the documentation, indirectbr instruction should be supplied with the list of all possible destination blocks. Omitting a BB that is being jumped to produces undefined behavior.