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