[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/11.1.0.040913 |
> 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)