[avr-libc-dev] Re: Linker relaxation

avr-libc-dev

[Top][All Lists] Advanced

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

## [avr-libc-dev] Re: Linker relaxation

From: | BjÃrn Haase
Subject: | [avr-libc-dev] Re: Linker relaxation
Date: | Fri, 21 Apr 2006 08:44:52 +0200
User-agent: | KMail/1.7.1

    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.

reply via email to

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

- [avr-libc-dev] Re: Linker relaxation, BjÃrn Haase <=
  - Re: [avr-libc-dev] Re: Linker relaxation, Bernd Trog, `2006/04/21`

- Prev by Date: Re: [avr-libc-dev] RFC: Database for device properties.?
- Next by Date: Re: [avr-libc-dev] RFC: Database for device properties.?
- Previous by thread: [avr-libc-dev] RFC: Database for device properties.?
- Next by thread: Re: [avr-libc-dev] Re: Linker relaxation
- Index(es):
  - Date
  - Thread