Yann Ramin wrote:
Just did a test run on an application we have on the F1611.
-fno-inline -Os on 4.3.4
text data bss dec hex filename
45314 24 7968 53306 d03a app.bin
-Os on 3.2.3
text data bss dec hex filename
43738 72 7940 51750 ca26 app.bin
which is a slightly curious outcome. -fno-inline increases code size.
without -fno-inline
text data bss dec hex filename
44188 24 7968 52180 cbd4 app.bin
I haven't done a function by function analysis yet to determine where
the size increase is coming from. I also haven't attempted a whole
program build (-fwhole-program -combine) as the makefile is
programmatically generated by our dependency tool and thats a place I'm
not ready to go just now ;)
This is mainly from my experience with avr-gcc, which has had the same
issues regarding code size when moving to newer gcc versions.
-fno-inline can increase code size, because contrary to popular opinion,
inlining will often reduce code size. The key to keeping size down
during automatic inlining is to make sure your functions are either
"static" or explicitly "extern" - that way the compiler will either
generate a non-inline version, or inline a single usage, but not both
(use flags -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls
to help enforce this).
Note that inlining single-use functions always reduces code size. The
reduction can sometimes be quite dramatic - it's very common that
parameters for things like initialisation functions are constants, and
the compiler can use this to simplify and eliminate code.
The other issue with inlining is that on higher optimisation settings
(but not -Os), -finline-small-functions is enabled which (surprise,
surprise) inlines functions of a certain size even if they are used more
than once. Sometimes this will reduce code size as well as speeding up
the code - the function call overhead in the callee (the actual "call"
statement, along with code to shuffle registers around for parameters)
could be bigger than the inlined code. Personally, I prefer to
explicitly label such small functions as "inline".
Another flag that can be used to reduce code space is
"-frtl-abstract-sequences". This should take common code sequences and
generate extra subroutines for them. I don't know how well this works
(if it works at all), but it could be worth trying.
All in all, with avr-gcc, gcc 4.3 produces slightly larger code than gcc
3.x even with care regarding inlining and appropriate compiler flags.
Of course, results vary according to the type of code. My expectation
is that msp430-gcc will see much the same effects as for avr-gcc.
