Re: [avr-gcc-list] regression in size from 4.2.2 to 4.5.0

[Kang Tin LAI]

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