AVR Freaks :: View topic - WinAVR 20081205 code bloat

WinAVR 20081205 code bloat

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » AVR GCC forum

Author

Message

slarge

Posted: Jan 15, 2009 - 01:58 PM

Joined: Jan 15, 2009
Posts: 8

I have been using WinAVR-20070525 for sometime. When I change to 20081205 my code gets considerably larger using the same compiler switches. I'm using the -Os option and the 2008 compiler seems to be doing a lot of function inlining that the 2007 didn't, which is the main cause of the bloat.

The specific options I am using are these:

-g -Os -Wall -Wstrict-prototypes -Wa,-ahlms=$*.lst -mmcu=$(MCU) -ffreestanding

Anyone else seen this or know a fix for it?

clawson

Posted: Jan 15, 2009 - 02:20 PM

Joined: Jul 18, 2005
Posts: 34381
Location: (using avr-gcc in) Finchingfield, Essex, England

Well there are command line switches to prevent inlining (see section of GCC manual about optimisation)

But another approach would be to ensure that any functions local to one file be marked 'static' so that when the file is compiled, even if the function body is inlined for efficiency the standlaone copy will not be generated (as there's no chance it being called from outside of the file)

You may also want to thread search "gc-sections AND relax" for other possible size optimisations (also whole program)

For example, here's just one of several useful threads that search will hit:

http://www.avrfreaks.net/index.php?name ... ions+relax

_________________

slarge

Posted: Jan 15, 2009 - 03:39 PM

Joined: Jan 15, 2009
Posts: 8

This seems to be a problem with the space optimisation. Looking at the LST file some functions are being inlined many times in the same file, even though this generates far more code than having multiple calls to a single function. It generates faster but larger code, and according to the GCC docs -Os should not use that optimisation.

I tried -fno-inline-small-functions and that reduces the bloat from 20% down to about 4%. So I guess the remaining bit is due to the functions that qualify as 'small' but still generate more code when inlined many times.

Quote:

Well there are command line switches to prevent inlining (see section of GCC manual about optimisation)

I don't want to disable inlining entirely as having called-once static functions inlined does indeed save space, as does inlining _very_ short functions.

I already have as many functions declared static as I can to avoid creating an export copy of inline functions.

clawson

Posted: Jan 15, 2009 - 08:31 PM

Joined: Jul 18, 2005
Posts: 34381
Location: (using avr-gcc in) Finchingfield, Essex, England

Well it was actually the -fno-inline-small-functions I was thinking of when I made that comment in fact.

_________________

slarge

Posted: Jan 16, 2009 - 09:30 AM

Joined: Jan 15, 2009
Posts: 8

My point is that in previously versions, GCC with -Os would only inline if it didn't inflate the code size. The new version seems to be inlining for speed and ignoring the 'optimize for space' requirement.

-fno-inline-small-functions seems to help some; in fact maybe it does brings the inlining back to how it was previously, and there is some other factor which I have not discovered yet which is causing the remainder of the growth.

Posted: Jan 16, 2009 - 09:50 AM

Joined: Mar 01, 2001
Posts: 4227
Location: Rocky Mountains

There is already a GCC bug report about this (the inlining differences), so we're aware of the issue.

Magister

Posted: Feb 04, 2009 - 09:41 PM

Joined: Aug 06, 2008
Posts: 26
Location: Montréal, QC

Same problem here between 20080610 and 20081205, my application went from 15524 bytes to 16734 bytes (+1210) so it does not fit my 16K.

My optimization is as follow:
-Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -fno-split-wide-types -Wl,--relax -fno-inline-small-functions -mcall-prologues

It's annoying Crying or Very sad

wek

Posted: Feb 06, 2009 - 07:31 AM

Joined: Dec 16, 2005
Posts: 1454
Location: Bratislava, Slovakia

Without further analysis, I'd say this is the price we pay for gcc being primarily targeted to the "big" processors - the optimisation decisions have a different precedence in that very different world.

My policy is now to resist updating to newer versions of avr-gcc. Unfortunately, there appears to be no information what benefits would result from updating to any particular version...

JW

skeeve

Posted: Feb 06, 2009 - 04:20 PM

Joined: Oct 29, 2006
Posts: 1487

IIRC gcc has a flag for setting the threshold
between small and large functions.
Does --relax do anything with avr-ld?
The documentation I've found suggests not.

_________________
Michael Hennebry
"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

Posted: Feb 06, 2009 - 04:44 PM

Joined: Mar 01, 2001
Posts: 4227
Location: Rocky Mountains

Yes, linker relaxation exists for the AVR port, though I don't think that the documentation has been updated to say so.

Magister

Posted: Feb 06, 2009 - 07:22 PM

Joined: Aug 06, 2008
Posts: 26
Location: Montréal, QC

-Wl,--relax saves 608 bytes on my project so yes it works Smile

Posted: Feb 07, 2009 - 03:15 AM

Joined: Mar 01, 2001
Posts: 4227
Location: Rocky Mountains

IIRC, there's a target specific flag -mrelax which then turns on that linker flag for you automatically.

slarge

Posted: Feb 10, 2009 - 11:03 AM

Joined: Jan 15, 2009
Posts: 8

EW wrote:

There is already a GCC bug report about this (the inlining differences), so we're aware of the issue.

Is there a GCC fix yet, or a link to the bug in their issue tracker?

Posted: Feb 10, 2009 - 03:43 PM

Joined: Mar 01, 2001
Posts: 4227
Location: Rocky Mountains

No fix yet.

A list of all AVR toolchain bugs can be found here:
http://www.nongnu.org/avr-libc/bugs.html

All times are GMT + 1 Hour

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » AVR GCC forum