[Top][All Lists]

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

Re: [avr-libc-dev] Considerable Compiler improvement needs testing

From: Paul Schlie
Subject: Re: [avr-libc-dev] Considerable Compiler improvement needs testing
Date: Wed, 02 Feb 2005 10:47:24 -0500
User-agent: Microsoft-Entourage/

> From: Rolf Ebert <address@hidden>
>> Björn Haase <address@hidden> wrote:
>> ...  avoid useless moves across registers when dealing with variables of
>> different byte sizes. The change suggested by Andy Hutchinson affects one
>> single line in the gcc/config/avr/avr.h that presently reads
>> #define MODES_TIEABLE_P 0
>> ...
>> . My tests have shown that *with* this change, about 15 testcases in the
>> gcc testsuite work that did not beforehand and the code becomes considerably
>> tighter.
> I applied the proposed patch to the current gcc-3.4 branch of AVR-Ada, the
> Ada cross compiler for AVR. I tested it with some example programs and
> also my main application (a data logger based on Butterfly (mega169)). No
> use of floating point vars.
>   - I did not detect any functional regression,
>   - most functions (~95%) do not change size at all,
>   - a few functions shrinked by 1 - 7% in code size,
>   - a single function increased from 224 to 232 bytes,
>   - the main application shrinked from xx to 1866 bytes.
>   - I did not check RAM usage.
> Non-Ada-specific compile options: -Os -ffunction-sections
> function-sections was very helpful here as avr-size -A shows the code size
> for every function separately.

- from what I've seen, although it's effect on code-size may not seem that
significant on the average, it's effect on embedded function call and loop
efficiency seems to be more significant; such that even in circumstances
where the code-size may not have changed, the inner-loop code seems to be
typically tighter, at the expense of occasionally greater global register
usage, thereby improving overall performance. (overall, although not a
miracle, definitely seems to help more significantly than hurt, so would be
nice to see incorporated into 4.0)

reply via email to

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