Schwichtenberg, Knut wrote:
The increase in size was also subject for other gcc versions. Often the
following gcc comand-line swichtes were proposed:
-fno-inline-small-function
-fno-split-wide-types
-fno-move-loop-invariants
-------------------------------------
Additionally Larry Barello provided the following measurement on 16-Feb-09:
I explicitly inline code with the following attribute
#define _INLINE_ static inline __attribute__((always_inline))
For my medium size project (lots of menus/graphics/various sensors and serial
port devices)
1) -no-inline-small-function - 69034
2) --param inline-call-cost=2 - 68964
3) -fno-inline - 68816
4) -finline-limit=10 - 68810
5) #2 & #4 - 68754
6) -finline-limit=3 - 68754 (same results for 1,2 and 3)
I found that it depends on your source codes, it may be a problem of
loop, 'for' loop inside 'while' loop, multiple nested 'for' + 'while'
loop and blah... may fool the optimizer. Simple and lesser level nested
loop might help. Need further test.
My experience:
-fno-tree-loop-optimize
-fno-inline
-fsplit-wide-types
-fno-move-loop-invariants
Above switches are working well for source code A, 1.3k .text section is
reduced to 1.0k. But it is poor for source code B, -Os only generates
9.4k .text section while above switched expands to 9.9k .text section.
My avr-gcc is 4.3.3.
My source code A is a heavily nested mixing 'for' and 'while' loops
while source code B is a straight forward codes, the deepest nested loop
level is 2.
To get better code size, you have to try different switches combinations.
Cheers!
--
Kang Tin Lai
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
