A source file mrSurfaceList.cc of 252.eon produces less efficient
code initializing instance objects to 0 at -O2 than at -O1. Behavior
is random and it does not happen on all x86 platforms and making the
test smaller makes the problem go away. But here is what I found out
is the cause.
When source is compiled with -O1 -march=pentium4, 'cse' phase sees
the following pattern initializing a 'double' with 0.
(insn 18 13 19 0 (set (reg:SF 109)
(mem/u/i:SF (symbol_ref/u:SI ("*LC11") [flags 0x2]) [0 S4
A32])) -1 (nil)
(nil))
(insn 19 18 20 0 (set (mem/s/j:DF (plus:SI (reg/f:SI 20 frame)
(const_int -32 [0xffffffffffffffe0])) [0
objectBox.pmin.e+16 S8 A128])
(float_extend:DF (reg:SF 109))) 86 {*extendsfdf2_sse} (nil)
(nil))
Then fold_rtx routine converts it into its reduced form, resulting
in optimum code:
(insn 19 13 21 0 (set (mem/s/j:DF (plus:SI (reg/f:SI 20 frame)
(const_int -32 [0xffffffffffffffe0])) [0
objectBox.pmin.e+16 S8 A128])
(const_double:DF 0.0 [0x0.0p+0])) 64 {*movdf_nointeger} (nil)
(nil))
But when the same source is compiled with -O2 march=pentium4, 'cse'
phase sees a slightly different pattern (note that float_extend:DF
has moved)
(insn 18 13 19 0 (set (reg:DF 109)
(float_extend:DF (mem/u/i:SF (symbol_ref/u:SI ("*LC13")
[flags 0x2]) [0 S4 A32]))) -1 (nil)
(nil))
(insn 19 18 20 0 (set (mem/s/j:DF (plus:SI (reg/f:SI 20 frame)
(const_int -32 [0xffffffffffffffe0])) [0
objectBox.pmin.e+16 S8 A128])
(reg:DF 109)) 64 {*movdf_nointeger} (nil)
(nil))
This cannot be simplified by fold_rtx, resulting in less efficient code.
Change in pattern is most likely because of additional tree
optimization phases running at -O2. If so, then should the cse be
taught to simplify the new rtl pattern. Or, the tree optimizer phase
responsible for the less than optimal tree need be twiked to generate
the same tree as with -O1?
Thanks, fariborz
