[RFH] - Less than optimal code compiling 252.eon -O2 for x86

[Fariborz Jahanian]

FYI, the change to rtl  in -O2 vs. -O1 is that -O2 includes -fforce- 
mem which forces memory operands to registers to make memory  
references common sub-expressions. In this case, the constant double  
float value is assigned to an xmm register which is used where it is  
needed. So, I would say this behavior is as expected but not ideal  
for x86 where a couple of 'movl   $0x0, mem' may be preferred to a  
single 'movsd   %xmm7, mem' for 252.eon on x86-darwin.

- fariborz

On Jun 24, 2005, at 3:07 PM, Fariborz Jahanian wrote:

> 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
>
>