[avr-libc-dev] Re: Linker relaxation

[Björn Haase]

Fabrizio Tironi wrote on Freitag, 21. April 2006 17:42 :
> Björn Haase wrote:
> > It would, thus, be quite helpful if you or somebody else could test
> > the patch.
>
> We have just tried your patch.
Thanks for the rapid answer :-).
> Here is our config:
> Debian stable, kernel 2.6.13, avr-gcc 4.0.2, latest avr-libc, avr-binutils
> CVS (built with gcc 4.0.3 and with no error while patching).
>
> Compiler
> options: -Wall -Wextra -wstrict-prototypes -mcall-prologues -fno-inline -Os
> Linker
> options: -ffuncion-sections -Wl,--relax -Wl,--gc-sections -fdata-sections
> -W l,--relax -Wl,--gc-sections -Wl,-Map=fw.map -mmcu=atmega128

Ok, thus, it seems that even -fdata-sections worked. I did not test this issue 
so far. Fine.

> We experienced an improvement around 2 / 3%.
... that's about half what I got on our 16k projects. But in fact that's not 
very astonishing: For the smaller devices there are much more calls/jumps 
that could be replaced by the shorter variants than for the larger 
devices ...

You possibly could get some little additional improvement when re-compiling 
avr-libc with the new binutils: The relaxation machine does not try to 
optimize object files that had been assembled with the older tools.

> Here are the stats (all projects using ATmega128):
> - project1 without relax:  90216
> - project1 linked with relax:  88566
>
> - project2 without relax:: 100250
> - project2 linked with relax:: 98316
>
> - project3 without relax:: 19108
> - project3 linked with relax:: 18538
>
> Generated code seems ok (we are testing on our dev boards).
>
> Currently we are building a new test machine with avr-gcc 4.1.0, and we'll
> test 4.1.0  improvements combined with your patch.
> If you have any other suggestion - compiler options or linker options who
> can help with code size - please tell me.
Only thing that I could tell you is that sometimes for short functions 
inlining is the more code-efficient method. This is mainly the case when 
register shuffling takes more code than the function body. 

In order to control wether individual functions are inlined or not you could 
use __attribute__ ((noinline)) and __attribute__ ((always_inlined)).

For the more recent versions of gcc you might try the -fwhole-program and 
-funit-at-once options. I have read reports that this is good for some 
percent of code size, but I have no experience with it.

A point where one might improve code size also is: Optimizing memory accesses. 
Direct memory accesses are very expensive (4 bytes each). Sometimes it helps 
a lot if one makes gcc use pointers instead. This is, e.g., the case if one 
uses local data structures on the stack instead of static (global) data or if 
one assembles global static data in structs so that gcc knows about the 
relative offsets of the variables. This alone could be good for 1%-2% code 
size, but this depends, of course, on your code.

HTH,

Bjoern.