[Bug optimization/11261] New: Weak code generated for JPEG compression

["tm at kloo dot net" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11261

           Summary: Weak code generated for JPEG compression
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: optimization
        AssignedTo: joern.rennecke@superh.com
        ReportedBy: tm@kloo.net
                CC: gcc-bugs@gcc.gnu.org
 GCC build triplet: i386-linux
  GCC host triplet: i386-linux
GCC target triplet: sh-elf

GCC generates particularly awful code for jpeg_idct_float from the JPEG package,
which is the same code used in the EEMBC benchmark.

For the tail end of jpeg_idct_float(), there exists this code:

    outptr[0] = range_limit[(int) (( ( (INT32) (tmp0 + tmp7) ) + (((INT32) 1) 
<< ((  3 )-1)) ) >> (    3  ))
                            & (255  * 4 + 3) ];
    outptr[7] = range_limit[(int) (( ( (INT32) (tmp0 - tmp7) ) + (((INT32) 1) 
<< ((  3 )-1)) ) >> (    3  ))
                            & (255  * 4 + 3) ];
    outptr[1] = range_limit[(int) (( ( (INT32) (tmp1 + tmp6) ) + (((INT32) 1) 
<< ((  3 )-1)) ) >> (    3  ))
                            & (255  * 4 + 3) ];
    outptr[6] = range_limit[(int) (( ( (INT32) (tmp1 - tmp6) ) + (((INT32) 1) 
<< ((  3 )-1)) ) >> (    3  ))
                            & (255  * 4 + 3) ];
    outptr[2] = range_limit[(int) (( ( (INT32) (tmp2 + tmp5) ) + (((INT32) 1) 
<< ((  3 )-1)) ) >> (    3  ))
                            & (255  * 4 + 3) ];
    outptr[5] = range_limit[(int) (( ( (INT32) (tmp2 - tmp5) ) + (((INT32) 1) 
<< ((  3 )-1)) ) >> (    3  ))
                            & (255  * 4 + 3) ];
    outptr[4] = range_limit[(int) (( ( (INT32) (tmp3 + tmp4) ) + (((INT32) 1) 
<< ((  3 )-1)) ) >> (    3  ))
                            & (255  * 4 + 3) ];
    outptr[3] = range_limit[(int) (( ( (INT32) (tmp3 - tmp4) ) + (((INT32) 1) 
<< ((  3 )-1)) ) >> (    3  ))
                            & (255  * 4 + 3) ];

Unfortunately, GCC chooses to use the @(r0,rm) addressing mode for the read of
range_limit[] which causes the resulting code to be only single-issuable because
there are dependencies on r0:

        add     #4,r0
        shad    r4,r0
        and     r6,r0
        mov.b   @(r0,r7),r1
        sts     fpul,r0
        ftrc    fr1,fpul
        mov.b   r1,@r3
        add     #5,r3
        fmov    fr11,fr1
        fadd    fr6,fr1
        add     #4,r0
        fsub    fr6,fr11
        shad    r4,r0
        and     r6,r0
        mov.b   @(r0,r7),r1
        sts     fpul,r0
        ftrc    fr10,fpul
        mov.b   r1,@r3
        add     #-4,r3
        add     #4,r0
        shad    r4,r0
        and     r6,r0
        mov.b   @(r0,r7),r1
        sts     fpul,r0
        ftrc    fr1,fpul
        mov.b   r1,@r3

The instruction scheduler has very little freedom to reorder instructions
because of the overdependency on the r0 register.

This should be addressed because similar if not identical code is in the EEMBC
benchmark.

Toshi