[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Kang Tin LAI
Subject: Re: [avr-gcc-list] regression in size from 4.2.2 to 4.5.0
Date: Thu, 07 May 2009 22:16:24 +0800
User-agent: Thunderbird (X11/20080213)

Schwichtenberg, Knut wrote:
 The increase in size was also subject for other gcc versions. Often the 
following gcc comand-line swichtes were proposed:


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:


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.

Kang Tin Lai

reply via email to

[Prev in Thread] Current Thread [Next in Thread]