RE: [SH4] DFmode splits after reload

["Rakesh Kumar - Software, Noida" <rakeshku at noida dot hcltech dot com>]

> -----Original Message-----
> From: Jim Wilson [mailto:wilson@specifixinc.com]
> Sent: Tuesday, December 16, 2003 6:46 AM
> To: Rakesh Kumar - Software, Noida
> Cc: gcc@gcc.gnu.org
> Subject: Re: [SH4] DFmode splits after reload
> 
> The code seems broken in that it isn't setting fr3 before 
> using it.  Why 
> did that load get optimized out?  When did it get optimized out?  Was 
> the load really unnecessary?
> 

Hi,

  Probably it was my mistake to snip the assembly. I have a simple statement

         a[i] += a[j];   /* a is a double array */

There is no loop involved. On SH4, with -O2 -ml -m4 -fno-schedule-insns2,
following is the assembly output by GCC (r1 holds a[i] and r2 holds a[j]).

        fmov.s  @r1+,fr3   <-- Load 64-bit a[i] in two 32-bit halves
        fmov.s  @r1,fr2
        add     #-4,r1     <-- Restore the value in r1
        fmov.s  @r2+,fr5   <-- Load first 32-bits of a[j]
        fmov.s  @r2,fr4    <-- Load second 32-bits of a[j]
        fadd    dr4,dr2    <-- a[i] + a[j]
        add     #4,r1
        fmov.s  fr2,@r1    <-- Store a[i] in 32-bit pieces
        fmov.s  fr3,@-r1

  As I said earlier, SH4 doesn't allow 64-bit load/stores. It has to be
broken into two 32-bit transfers in flow2 pass. Hence, first 3
instructions in the assembly are a result of split of a single
instruction (from postreload pass)

         (insn:HI 19 18 20 1 0x4024f800 (parallel [
            (set (reg:DF 66 fr2 [171])
                (mem:DF (reg/f:SI 1 r1 [164]) [3 S8 A32]))
            (use (reg/v:PSI 151 fpscr))
            (clobber (scratch:SI))
        ]) 142 {movdf_i4} (insn_list 12 (nil))
    (nil))

Similarly, last 3 instructions are splitted from

         (insn:HI 22 21 24 1 0x4024f800 (parallel [
            (set (mem:DF (reg/f:SI 1 r1 [164]) [3 S8 A32])
                (reg:DF 66 fr2 [171]))
            (use (reg/v:PSI 151 fpscr))
            (clobber (scratch:SI))
        ]) 142 {movdf_i4} (insn_list 21 (nil))
    (nil))

In the ideal case, if the splitter had known in advance that r1 does not
need to be restored, because it is being used in subsequent instructions,
we could have avoided the address arithmetic insns. But splitter cannot
foresee the problems. And then it could be modified to compensate for
its past mistakes.

reload_cse_move2add does not help in this case, since these splits
happen in flow2. My idea is to recombine the instructions,
if possible, as and when splitting takes place. As in this case, at the
time of DFmode store insn, the splitter could have looked for the previous
use/definition of r1, hence removing two address arithmetic instructions.

Thanks and Regards,
Rakesh Kumar