GCC-SH: reload CSE weakness?

[Toshi Morita <tm2 at best dot com>]

   host: i386-linux
 target: sh-elf
version: CVS 10/20/2000

Lately, I've been examining JPEG decompression performance
problems on the Hitachi SH.  This is fairly important for graphics
compression in games, and also for CPU benchmarking as well, since
JPEG decompression is one of the EEMBCS benchmarking tests.

The basic gist of the problem seems to be GCC's still-weak
handling of deep stack frames when limited offsets are available.

One big problem appears to be jpeg_idct_ifast() in
jidctfst.c, which coincidentally is one of the files in stress-1.16.

A quick perusal reveals that there is an int workspace[64] on the
stack in this function.

When I compile the function with "-O2 -m4-single-only -ml" the
.text section of the object file is 0x3e4 bytes long:

bash$ sh-elf-objdump --section-headers jidctfst.o

jidctfst.o:     file format elf32-shl

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000003e4  00000000  00000000  00000040  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000000  00000000  00000000  00000424  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  00000424  2**0
                  ALLOC
  3 .comment      00000029  00000000  00000000  00000424  2**0
                  CONTENTS, READONLY

In fact, here are the first dozen or so instructions of the
function. You will see that GCC creates multiple pointers to
the same offset from the stack:

_jpeg_idct_ifast:
        mov.l   r8,@-r15
        add     #64,r5
        mov.l   r9,@-r15
        mov.l   r10,@-r15
        mov.l   r11,@-r15
        mov.w   .L40,r3
        mov.l   r12,@-r15
        mov.l   r13,@-r15
        mov     r6,r12
        mov.l   r14,@-r15
        mov.w   .L41,r0
        sub     r3,r15
        mov.w   .L41,r1
        mov     r15,r14
        mov.w   .L41,r2
        add     r14,r0          <- here
        mov.l   @(12,r5),r5
        add     r14,r1          <- here
        mov.l   r7,@(4,r0)
        add     r14,r2          <- here
        mov.w   .L42,r0
        mov.l   r5,@(8,r2)
        mov     #8,r5
        mov.l   r14,@(12,r2)
        mov.l   @(r0,r4),r4
        mov.l   r5,@(20,r2)
        mov.l   r4,@(16,r1)
        mov     r4,r3
        mov.w   .L43,r1
        add     r1,r3
        mov.l   r3,@(16,r2)

If I reduce the stack dept by changing the workspace array
to a static, e.g.:

static int workspace[64];

...then the object file size drops noticeably:

jidctfst.o:     file format elf32-shl

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000376  00000000  00000000  00000040  2**5
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000000  00000000  00000000  000003b6  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000100  00000000  00000000  000003b8  2**2
                  ALLOC
  3 .comment      00000029  00000000  00000000  000003b8  2**0
                  CONTENTS, READONLY

Basically, this *one-line* change decreases the .text section size
from 1744 to 1566 bytes, which is about a 9% difference.

These problems should have been addressed in SH4 Phase 2, but
it seems problems still remain. It would be nice if these problems
were fixed so the penalty for deep stacks would be only a few
percent or so.

Toshi