[Bug c/34903] New: -Os code size regression

[Bug c/34903] New: -Os code size regression

[sposelenov at emcraft dot com]

I can't build the embedded application (U-Boot firmware) using the GCC 4.2.2
powerpc-linux cross because resultant code doesn't fit into the reserved space
anymore. GCC 4.0.0 powerpc cross build it OK.
Investigation showed that the code size generated by the GCC 4.2.2 is about 6%
bigger as produced by GCC 4.0.0, as reported by 'size':
gcc 4.2.2:
   text    data     bss     dec     hex filename
   2696      60    1536    4292    10c4 interrupts.o


gcc 4.0.0:
 text    data     bss     dec     hex filename
   2424      88    1536    4048     fd0 interrupts.o


In both cases, same compilation options are used:
ppc-linux-gcc -g -Os -fPIC -ffixed-r14 -meabi -fno-strict-aliasing -D__KERNEL__
-DTEXT_BASE=0xfffc0000 -I/work/psl/tmp/u-boot/include -fno-builtin
-ffreestanding -nostdinc -isystem
/opt/eldk-4.2-01-08/usr/bin/../lib/gcc/powerpc-linux/4.2.2/include -pipe
-DCONFIG_PPC -D__powerpc__ -DCONFIG_4xx -ffixed-r2 -ffixed-r29 -mstring
-msoft-float -Wa,-m440 -mcpu=440 -DCONFIG_440=1 -Wall -Wstrict-prototypes -c -o
interrupts.o interrupts.c

Removing "-ffixed" doesn't change the generated assembler code for 4.2.2
Test case and generated outputs will follow.


-- 
           Summary: -Os code size regression
           Product: gcc
           Version: 4.2.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sposelenov at emcraft dot com
GCC target triplet: powerpc-linux


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

[Bug c/34903] -Os code size regression

[sposelenov at emcraft dot com]

------- Comment #1 from sposelenov at emcraft dot com  2008-01-21 15:36 -------
Created an attachment (id=14987)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14987&action=view)
Preprocessed output, GCC 4.2.2


-- 


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

[Bug c/34903] -Os code size regression

[sposelenov at emcraft dot com]

------- Comment #2 from sposelenov at emcraft dot com  2008-01-21 15:37 -------
Created an attachment (id=14988)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14988&action=view)
Resulted assembler,GCC 4.2.2


-- 


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

[Bug c/34903] -Os code size regression

[sposelenov at emcraft dot com]

------- Comment #3 from sposelenov at emcraft dot com  2008-01-21 15:41 -------
Created an attachment (id=14989)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14989&action=view)
preprocessed output, GCC 4.0.0


-- 


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

[Bug c/34903] -Os code size regression

[sposelenov at emcraft dot com]

------- Comment #4 from sposelenov at emcraft dot com  2008-01-21 15:42 -------
Created an attachment (id=14990)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14990&action=view)
resulted assmbelr, GCC 4.0.0


-- 


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

[Bug target/34903] -Os code size regression

[dje at gcc dot gnu dot org]

------- Comment #5 from dje at gcc dot gnu dot org  2008-01-21 15:54 -------
The "regression" is due to a wrong-code bug fix.  To reduce the code size, the
prologue and epilogue need to emit lwm/stwm for two ranges of registers, which
does not correspond to a standard PowerPC ABI.


-- 

dje at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dje at gcc dot gnu dot org
           Severity|normal                      |enhancement
             Status|UNCONFIRMED                 |NEW
          Component|c                           |target
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-01-21 15:54:02
               date|                            |


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

[Bug c/34903] -Os code size regression

[sposelenov at emcraft dot com]

------- Comment #6 from sposelenov at emcraft dot com  2008-01-21 16:08 -------
(In reply to comment #5)
> The "regression" is due to a wrong-code bug fix.  To reduce the code size, the
> prologue and epilogue need to emit lwm/stwm for two ranges of registers, which
> does not correspond to a standard PowerPC ABI.
> 

Thanks, understood. Would you please specify the bug # for this fix? I can't
find any useful.


-- 

sposelenov at emcraft dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |normal
          Component|target                      |c


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

[Bug target/34903] -Os code size regression

[dje at gcc dot gnu dot org]

------- Comment #7 from dje at gcc dot gnu dot org  2008-01-21 16:37 -------
First, please stop changing the categorization of this bug.

The patch which changed this behavior is

http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00276.html


-- 

dje at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
          Component|c                           |target


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

[Bug target/34903] -Os code size regression

[sposelenov at emcraft dot com]

------- Comment #8 from sposelenov at emcraft dot com  2008-01-22 10:55 -------
(In reply to comment #7)
> First, please stop changing the categorization of this bug.
> 
Sorry. 

> The patch which changed this behavior is
> 
> http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00276.html
> 
Thanks.

> The "regression" is due to a wrong-code bug fix.  To reduce the code size, the
> prologue and epilogue need to emit lwm/stwm for two ranges of registers, which
> does not correspond to a standard PowerPC ABI.
> 

Would you please comment the fact, that the removal of the "-ffixed" options
doesn't change the code for 4.2.2?


-- 


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

[Bug target/34903] -Os code size regression

[dje at gcc dot gnu dot org]

------- Comment #9 from dje at gcc dot gnu dot org  2008-01-22 15:59 -------
GCC does not use the load and store multiple instructions because the source
file declares r29 a global variable:

register volatile gd_t *gd asm ("r29");

The bug fix mentioned above inhibits GCC from using lmw/stmw if global
registers are present in the contiguous register sequence because GCC
incorrectly would overwrite the register.  If the register variable declaration
is removed, GCC uses the lmw/stmw instructions.  r29 is a bad choice for a
global register variable.


-- 


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

[Bug target/34903] -Os does not use lmw/stmw for multiple ranges

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2008-01-22 20:24 -------
Even though it has not been said here yet, the way to fix this is to have
lmw/stmw  emitted for r30/r31.  Though this only saves 8 bytes per function. 
It is the only fix which will help.  It does not fix the "regression" as it is
not really a regression anymore.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|-Os code size regression    |-Os does not use lmw/stmw
                   |                            |for multiple ranges


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