Big kernel size increase with gcc 3.4

Big kernel size increase with gcc 3.4

[Bernardo Innocenti]

Hello,

these figures speak for themselves:

   text    data     bss     dec     hex filename
 833352   47200   78884  959436   ea3cc linux-2.6.x/vmlinux_gcc331
 877420   53212   78884 1009516   f676c linux-2.6.x/vmlinux_gcc34


 - target is linux-2.6.0-test2-uc0 for m68knommu (full config
   available on request);

 - same optimization flags: -m5307 -O2 -fno-strict-aliasing
      -fno-common -fno-builtin -fomit-frame-pointer

 - same ColdFire GCC patches were used (I strongly doubt it
   could be a back-end issue);

 - gcc-3.3.1-20030720 VS gcc-3.4-20030806.

I can provide more datails if needed. Could be an inlining issue
of course.

Out of curiosity, it seems that the old 2.95.3 could finally be
sent to rest now:

   text    data     bss     dec     hex filename
  833352   47200   78884  959436   ea3cc linux-2.6.x/vmlinux_gcc331
  857208   72800   60836  990844   f1e7c linux-2.6.x/vmlinux_gcc295

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html

Re: Big kernel size increase with gcc 3.4

[Aaron Lehmann]

On Fri, Aug 08, 2003 at 04:39:02AM +0200, Bernardo Innocenti wrote:
> - same optimization flags: -m5307 -O2 -fno-strict-aliasing
>      -fno-common -fno-builtin -fomit-frame-pointer

You should try -Os if you want to optimize for size.

Re: Big kernel size increase with gcc 3.4

[Bernardo Innocenti]

Aaron Lehmann wrote:
> On Fri, Aug 08, 2003 at 04:39:02AM +0200, Bernardo Innocenti wrote:
> 
>>- same optimization flags: -m5307 -O2 -fno-strict-aliasing
>>     -fno-common -fno-builtin -fomit-frame-pointer
> 
> You should try -Os if you want to optimize for size.

I did some time ago, and it seems to reduce the code size greatly,
but then I noticed some problems with the memory allocator and
switched back to -O2 for fear that changing the inlining policy
could lead to instability.

I still see those memory allocator problems, so I think I could
safely switch back to -Os now... actually I would recommend it
for all embedded targets.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html

Re: Big kernel size increase with gcc 3.4

[Bernardo Innocenti]

Ville Herva wrote:

>>You should try -Os if you want to optimize for size.
> 
> I was about to suggest that, too.
> 
> It could be that while optimizing for speed, gcc 3.4 simply inlines way more
> by default (whether or not that actually makes the code faster is a
> different question). I think -Os could be a better comparison.

You were both right. With -Os, GCC 3.3.1 and 3.4 perform
similarly, with a slight advantage for 3.4 :-)

   text    data     bss     dec     hex filename
 833352   47200   78884  959436   ea3cc vmlinux_gcc331
 807140   48036   78884  934060   e40ac vmlinux_gcc331_Os
 796264   50560   78884  925708   e200c vmlinux_gcc34_Os

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html

Re: Big kernel size increase with gcc 3.4

[tm_gccmail]

On Fri, 8 Aug 2003, Bernardo Innocenti wrote:

> Hello,
> 
> these figures speak for themselves:
> 
>    text    data     bss     dec     hex filename
>  833352   47200   78884  959436   ea3cc linux-2.6.x/vmlinux_gcc331
>  877420   53212   78884 1009516   f676c linux-2.6.x/vmlinux_gcc34
> 
> 
>  - target is linux-2.6.0-test2-uc0 for m68knommu (full config
>    available on request);
> 
>  - same optimization flags: -m5307 -O2 -fno-strict-aliasing
>       -fno-common -fno-builtin -fomit-frame-pointer

Could you add -fno-reorder-blocks and report the result?

Toshi