[avr-gcc-list] Re: Code Bloat

[Nicholas Vinen]

> Here we had to change a few times of AVR-GCC versions only to be able to 
> process new AVR chips while keeping older ones up to date.  And each 
> time, since GCC 3.4.6, I've seen code bloat with newer versions and had 
> to spend time only to get the the same application fit in the same 
> memory footprint for older chips using a newer GCC (we want to keep a 
> single compiler version for all of our devices).
>   
While I agree that fixing some of the missed optimisations would be
nice, and that it's a pain to have to deal with installing a new version
of AVR-GCC then fiddling with old projects to get them to fit again,
I've found that newer versions of GCC are actually as good or better
than old ones in most cases for code size generation.. the problem is
that they are worse with no extra options.

If you take some of the suggestions posted to this list previously for
options such as "--param inline-call-cost=3" (or 2),
"-fno-split-wide-types" and "-fno-inline-small-functions" in some
combination, usually the result is as small or smaller.

Unfortunately, because the effect of these flags varies between GCC
versions, and because older versions of GCC don't support the last two,
it's hard to generate a Makefile that will compile a given project
optimally with different versions of AVR-GCC. This is the best I came up
with so far:

CFLAGS?=-Os -Wall -mmcu=atmega48 -L/usr/lib/binutils/avr/2.18/ --param 
inline-call-cost=3 `avr-gcc --version | head -1 | awk -F" " '{ printf $$3 >= 
4.3 ? "-fno-split-wide-types -fno-inline-small-functions" : "" }'`


It's a hack, I know, but I tested it on several versions of AVR-GCC with
reasonably good results. I doubt it'll work universally but could be
quite good in a number of cases.

Unfortunately I don't have enough time to work on AVR-GCC's internals
but next time I come across a badly missed optimisation I'll submit as
detailed a bug report as I can.

Another hint, this may seem obvious but I missed it for a while: declare
as many functions "static" as you can, so that if they are inlined then
there won't have to be an extra non-inlined copy stored.



Nicholas