Andrew Haley wrote:
On 03/02/2010 08:55 AM, Alain Ketterlin wrote:
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?
We really need a test case, with source, that illustrates the problem.
When we have that, we can treat is as a missed-optimization bug.
Sure. I can provide a list of functions from the SPEC CPU2006 where it
happens. Here is the list for 403.gcc, at -01 and -03 (the CPU2006 gcc
is based on gcc-3.2, according to SPEC, so probably different from the
actual code base).
=== 403.gcc (-O1)
FUN init_builtins 0x43582f BLOCK 0x43582f
FUN cpp_finish_options 0x435a39 BLOCK 0x435a52
FUN life_analysis 0x4be8f7 BLOCK 0x4beb79
FUN optimize_mode_switching 0x580b9a BLOCK 0x580ea4
=== 403.gcc (-O3)
FUN start_function 0x413af0 BLOCK 0x41410e
FUN init_builtins 0x442640 BLOCK 0x442640
FUN cpp_finish_options 0x442ec0 BLOCK 0x442f28
FUN can_combine_p 0x4770f0 BLOCK 0x477196
FUN gen_rtx 0x4bf440 BLOCK 0x4bf5a8
FUN expand_shift 0x4ca5a0 BLOCK 0x4ca6ce
FUN life_analysis 0x4edbc0 BLOCK 0x4ee03d
FUN htab_create 0x6a1940 BLOCK 0x6a1940
FUN htab_expand 0x6a1aa0 BLOCK 0x6a1aa0
FUN htab_try_create 0x6a1ee0 BLOCK 0x6a1ee0
(the addresses may be meaningless, but if both addresses are equal it
means that the problem appears on the entry block). I can't guarantee
this list is exhaustive.
My full list for CPU2006 programs is a bit too long to post on the
mailing list (around a thousand lines). I can send it by mail (is a list
of function names enough?).
I'll try to extract a minimal example if you want and/or have no access
to CPU2006. Give me one or two days.
-- Alain.
