------- Comment #2 from derek dot white at sun dot com 2008-06-06 16:08 -------
Not a duplicate of bug 5738 (?)
I don't think this can be handled by "GCSE code hoisting". The previous example
have the common subexpression independent of anything else, so code could be
hoisted or delayed. But common code could be dependent on, and depended upon by
non-common code in ways that tend to block CSE.
Look at this example and the addgt and addle instructions below.
--- c example ---
// arm-elf-gcc -S -g0 -Os -o comp-cond.s comp-cond.c
int x,y;
void foo(int b) {
if (b > 13) {
x = y + 0xFF;
} else {
y = x + 0xFF;
}
}
--- arm code ---
foo:
ldr r1, .L6
ldr r2, .L6+4
cmp r0, #13
ldrgt r3, [r2, #0]
ldrle r3, [r1, #0]
addgt r3, r3, #255 <-- DUPLICATE OF BELOW
addle r3, r3, #255 <-- replace both with: add 3, r3, #255
strgt r3, [r1, #0]
strle r3, [r2, #0]
bx lr
This is in gcc-4.2.1.
I don't know the phase order of gcc, but note that this common code is
generated by gcc in the ARM code generator somewhere, which may be too late for
CSE? It looks like a simple peephole optimization could clean this up though.
--
derek dot white at sun dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |derek dot white at sun dot
| |com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11820
