Skip to contentSkip to conversation

Big kernel size increase with gcc 3.4

DISCUSSION Bernardo Innocenti 3 participants 5 messages Aug 8, 2003 1 message not in the archive

lore
Share & tools
lore
#0 lore raw

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
Signature · 4 lines
 // 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
#1 lore raw
Quoted 2 lines · Bernardo Innocenti

- 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.

#2 lore raw
Quoted 6 lines · Aaron Lehmann
Quoted 2 lines · Bernardo Innocenti

- 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.

Signature · 4 lines
 // 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

A message that is not in the archive (sent off-list or not yet received): [email protected]

#4 lore raw
Quoted 7 lines · Ville Herva
Quoted 1 line

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
Signature · 4 lines
 // 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
#5 lore raw
In reply to Bernardo Innocenti
Quoted 9 lines · 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
Quoted 5 lines

- 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