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

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

[tm at kloo dot net]

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

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

[tm at kloo dot net]

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



------- Additional Comments From tm at kloo dot net  2003-06-20 00:57 -------
Created an attachment (id=4254)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=4254&action=view)
testcase for problem

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

[pinskia at physics dot uc dot edu]

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


pinskia at physics dot uc dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pessimizes-code

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

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


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4                         |---

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

[dhazeghi at yahoo dot com]

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


dhazeghi at yahoo dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
  GCC build triplet|i386-linux                  |
   GCC host triplet|i386-linux                  |


------- Additional Comments From dhazeghi at yahoo dot com  2003-08-25 00:39 -------
What optimization flags did you use to produce the assembly snippet you included?

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2003-11-22 20:18 -------
Changing back to NEW as this is not really required.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2003-11-22 20:18:21
               date|                            |


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

[Bug rtl-optimization/11261] Weak code generated for JPEG compression

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2005-06-25 13:08 -------
This bug hasn't been modified in more than 18 months.  What is the 
current status of this bug?  And is this not really a target specific 
issue for SH with its silly r0, or can other targets also have this 
problem?? 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


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

[Bug rtl-optimization/11261] Weak code generated for JPEG compression

[amylaar at gcc dot gnu dot org]

------- Additional Comments From amylaar at gcc dot gnu dot org  2005-07-05 17:24 -------
(In reply to comment #4)
> This bug hasn't been modified in more than 18 months.  What is the 
> current status of this bug?  And is this not really a target specific 
> issue for SH with its silly r0, or can other targets also have this 
> problem?? 

The sh-elf libraries won't build because of PR 22258.
Because we have sched1 enabled, the scheduling problem is currently
non-existant; the values that are needed in r0 can be calculated
in a different general purpose register, and moved into r0 in time for the
indexed addressing.
However, because of sched1 we now have too high register pressure for other
benchmarks.  Vlad proposed at the summit to postpone scheduling after reload
to fix the register pressure issue.  Unless his porposed register renaming
schedme can handle this case and snarf the required registers too, we'll
go back to square one.




-- 


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

[Bug rtl-optimization/11261] Weak code generated for JPEG compression

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
   Last reconfirmed|2003-11-22 20:18:21         |2005-09-12 01:18:36
               date|                            |


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