为什么编译器不能优化这些无法访问的指令？

Question

Given this code:

int x;

int a (int b) {
    b = a (b);
    b += x;
    return b;
}

why does GCC return this output (Intel Syntax): http://goo.gl/8D32F1 - Godbolt's GCC Explorer

a:
    sub rsp, 8
    call    a
    mov edx, DWORD PTR x[rip]
    add rsp, 8
    lea eax, [rax+rdx*8]
    add eax, edx
    ret

and Clang return this output (AT&T Syntax): http://goo.gl/Zz2rKA - Godbolt's Clang Explorer

a:                                      # @a
    pushq   %rax
    callq   a
    addl    x(%rip), %eax
    popq    %rdx
    ret

when part of the code is clearly unreachable? Since the very first statement of the function is

b = a (b);

the function will forever keep calling itself recursively (until the stack overflows and you get a segfault). This means that you will never go beyond that line, and therefore, the rest of the code is unreachable. Reachability optimization should in theory remove the code, correct?

---

Both compilers were running on x64 and with the following flags

• -O3 - max optimization
• -march=native - [unnecessary] use machine specific optimizations when possible
• -xc - assume input language is C

---

I was thinking that they should have returned something more along the lines (pun intended) of this:

GCC (Intel Syntax):

a:
.L1:
    jmp .L1

Clang (AT&T Syntax):

a:
.LBB0_1:
    jmp .LBB0_1

note: these samples were written by hand from memory of previous observations and may be incorrect.

---

So overall, why don't either of the compilers collapse the function into a single recursive jump due to the rest of the code being unreachable?

---

EDIT:

Response to Jack's comment on semantic equivalence:

For the following code:

int j (int x) {
    while (1) {};
    x++;
    return x;
}

GCC returns: http://goo.gl/CYSUW2

j:
.L2:
    jmp .L2

Clang returns:

j:                                      # @j
.LBB0_1:                                # =>This Inner Loop Header: Depth=1
    jmp .LBB0_1

---

Response to Adam's comment on blowing out the stack:

For this code:

int r (int x) {
    return r (x);
}

GCC generates a recursive jump: http://goo.gl/eWo2Nb

r:
.L2:
    jmp .L2

Clang returns cleanly early: http://goo.gl/CVJKiZ

r:                                      # @r
    ret

Answer 1

The compilers you're using probably implement data flow analysis only at the block level within a single function frame, not taking into consideration recursion. (Or perhaps, only interesting recursion, namely tail recursion.) Since the recursive call isn't a tail call, it isn't interesting from an optimization point of view.

Your function has a problem: the way it is compiled, it blows up the stack. It is compiled that way because the call isn't a tail call; it is not a legitimate optimization to treat it as one.

The call could be considered a "pseudo tail call" on grounds that that the code after the call is never invoked, and so if we remove that code, then the recursive call is the last thing which the function does. Then we could reduce the stack-blowing code to a mere infinite loop. This cannot really be called an optimization, though; it's the replacement of one bug manifestation by a different bug manifestation.