RE: [avr-gcc-list] GCC-AVR Register optimisations

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Andrew Hutchinson
> Sent: Wednesday, January 09, 2008 6:52 PM
> To: address@hidden
> Subject: [avr-gcc-list] GCC-AVR Register optimisations
> 
> Hi all,
> 
> just spend some days going over gcc-avr and missed optimizations.
> 
> One area I looked at was register allocation
<snip>
> So is there an better order?

I certainly appreciate all your effort in looking at missed
optimizations. I know that not very many people are able to look into
this area in AVR GCC right now.

However, I'd like to bring up a few points:

- Changing the register order, while it seems promising, introduces a
major backwards incompatibility. Avr-libc is written in mostly
hand-optimized assembly, which means that C functions in the application
call assembly routines in avr-libc. Changing the register order means a
complete overhaul of avr-libc; something that is not likely to happen
quickly or without a lot of effort. Would you be prepared to help take
this on?

- There are many missed optimization bugs in the bug database that
probably could be fixed without resorting to changing the register
order. These are definitely real world problems that need to be fixed.
<http://www.nongnu.org/avr-libc/bugs.html>

- I, and others, are very interested in what you are using to test your
proposed changes. I have plans to put together an AVR Benchmark Suite,
consisting of a variety of publicly available programs that can be used
to test the compiler performance over time. It definitely needs to have
different types of programs, and publicly available programs so there
are no issues with distributing such a Benchmark Suite. I welcome any
collaboration on this.

- The bug list <http://www.nongnu.org/avr-libc/bugs.html> has a number
of bugs that are "wrong-code" bugs or bugs that generate an internal
compiler error on valid code ("ICE-on-valid-code"). These bugs are much
more important to fix right now then tackling the various missed
optimization bugs. These higher priority bugs show where the compiler,
or AVR back end of the compiler, is *failing*. Any help in fixing these
would be very much appreciated. IMHO, after these high-priority bugs get
fixed, then it would be worthwhile to start looking at fixing missed
optimizations.

Eric Weddington