2003-08-08 02:39:08

by Bernardo Innocenti

Subject: Big kernel size increase with gcc 3.4

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

2003-08-08 02:52:55

by Aaron Lehmann

Subject: Re: Big kernel size increase with gcc 3.4

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.

2003-08-08 14:00:49

by Bernardo Innocenti

Subject: Re: Big kernel size increase with gcc 3.4

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

2003-08-08 15:10:34

by Bernardo Innocenti

Subject: Re: Big kernel size increase with gcc 3.4

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

2003-08-08 19:37:24

by tm_gccmail

Subject: Re: Big kernel size increase with gcc 3.4

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