Useless conditional branches

[Alain Ketterlin <alain dot ketterlin at gmail dot com>]

It looks like gcc sometimes produces "useless" conditional branches.
I've found code like this:

  xor    %edx,%edx
  ; code with no effect on edx (see full code below)
  test   %edx,%edx
  jne    <somewhere else>

The branch on the last line is never taken. Why does gcc generate such
code sequences? Is this patched at runtime, or something? Am I missing
something obvious here?

I append the function's complete code below. There is another
suspicious branch at 0xb31cd8 (never taken, for less obvious
reasons---edx is never zero at that point).

I have found hundreds such occurrences across the CPU2006 suite. Does
anybody have any idea why this happens? Is there any specific
optimization to enable or disable to avoid such dead edges? Thanks in
advance for any remark/idea/...


This code is from 416.gamess (from SPEC CPU2006), function "formf",
compiled with "gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)" (from a
stock ubuntu 9.10), with options "-g -O3 -march=native
-fno-optimize-sibling-calls". 416.gamess is compiled with gfortran,
but the same thing happens with C or C++ programs. The same also
happens at lower optimization levels (-01), but less frequently.

uname -m gives "x86_64", and /proc/cpuinfo contains:

vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Intel(R) Core(TM)2 Duo CPU     P8700  @ 2.53GHz
[...]
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor
ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm ida
tpr_shadow vnmi flexpriority

Here is an objdump disassembly of the code, broken into basic-blocks:

0000000000b31c60 <formf_>:
  b31c60: push   %rbx
  b31c61: xor    %edx,%edx
  b31c63: mov    %rsi,%rbx
  b31c66: mov    $0x2,%r9d
  b31c6c: mov    $0xa,%r8d
  b31c72: mov    $0x6,%esi
  b31c77: mov    $0xe,%ecx
  b31c7c: test   %edx,%edx
  b31c7e: jne    b31cda <formf_+0x7a>

  b31c80: mov    $0x3ff8000000000000,%r11
  b31c8a: mov    $0xbfe0000000000000,%r10
  b31c94: mov    %r11,(%rdi)
  b31c97: movq   $0x0,0x40(%rdi)
  b31c9f: movq   $0x0,0x20(%rdi)
  b31ca7: mov    %r10,0x60(%rdi)
  b31cab: xor    %eax,%eax
  b31cad: nopl   (%rax)

  b31cb0: inc    %edx
  b31cb2: movq   $0x0,0x10(%rdi,%rax,8)
  b31cbb: movq   $0x0,0x50(%rdi,%rax,8)
  b31cc4: movq   $0x0,0x30(%rdi,%rax,8)
  b31ccd: movq   $0x0,0x70(%rdi,%rax,8)
  b31cd6: test   %edx,%edx
  b31cd8: je     b31c80 <formf_+0x20>

  b31cda: cmp    $0x2,%edx
  b31cdd: jne    b31d18 <formf_+0xb8>

  b31cdf: mov    $0xbfe0000000000000,%r11
  b31ce9: mov    $0xbfe0000000000000,%r10
  b31cf3: mov    %r11,(%rdi,%r9,8)
  b31cf7: mov    $0x2,%eax
  b31cfc: movq   $0x0,(%rdi,%r8,8)
  b31d04: movq   $0x0,(%rdi,%rsi,8)
  b31d0c: mov    %r10,(%rdi,%rcx,8)
  b31d10: jmp    b31cb0 <formf_+0x50>

  b31d12: nopw   0x0(%rax,%rax,1)

  b31d18: movslq %edx,%rax
  b31d1b: cmp    $0x1,%edx
  b31d1e: movq   $0x0,(%rdi,%rax,8)
  b31d26: movq   $0x0,0x40(%rdi,%rax,8)
  b31d2f: movq   $0x0,0x20(%rdi,%rax,8)
  b31d38: movq   $0x0,0x60(%rdi,%rax,8)
  b31d41: jne    b31cb0 <formf_+0x50>

  b31d47: movq   $0x0,0x50(%rdi,%rax,8)
  b31d50: movq   $0x0,0x30(%rdi,%rax,8)
  b31d59: mov    $0x3fe0000000000000,%r9
  b31d63: mov    $0xbff8000000000000,%r8
  b31d6d: mov    %r9,0x10(%rdi,%rax,8)
  b31d72: mov    %r8,0x70(%rdi,%rax,8)
  b31d77: mov    $0xd0f838,%edx
  b31d7c: mov    $0xd0f7b0,%esi
  b31d81: mov    %rbx,%rdi
  b31d84: xor    %eax,%eax
  b31d86: callq  977b20 <vclr_>
  b31d8b: mov    $0x3fe0000000000000,%rsi
  b31d95: mov    $0x3fe0000000000000,%rcx
  b31d9f: mov    %rsi,(%rbx)
  b31da2: mov    %rcx,0x60(%rbx)
  b31da6: mov    $0xbfe0000000000000,%rdx
  b31db0: mov    $0xbfe0000000000000,%rax
  b31dba: mov    %rdx,0x18(%rbx)
  b31dbe: mov    %rax,0x78(%rbx)
  b31dc2: pop    %rbx
  b31dc3: retq

Let me know if more detail is needed.

-- Alain.