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

[andrewhutchinson]

---- "Weddington wrote: 
>  
> 
> > -----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?
> 
No!. Changing the order has not effect of the registers used to call functions 
or return values.  They are separately controlled in back end. The allocation 
order refers to the order in which registers are used for intermediate values 
or locals. So even if order starts with R18, functions will still expect and 
return an int in R24-25.

Changing the lower registers (CALL SAVED) does introduce a libgcc 
incompatibility, in that the routines for prolog/epilog invoked by 
-mcall-prolog assume that these registers are push/popped in a contigous 
sequence starting with R17. So changing to a different allocation order may 
well incur more push/ops than needed - unless prolog/epilog push/pop order was 
changed to match the same order. For this reason, I have left that alone. 
(although its not a big deal). prolog/epilog call are parts of gcc not replaced 
by libc. So even that would  leaves libc untouched.

Of course, any "c" still used in libc would benefit from recompilation.


> - 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>
> 
Yes, I have tried to look at underlying problems rather than concentrate on 
specfics. That way, you fix more problems


> - 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.

Absolutely!


> 
> - 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.

I have not ignored the higher priority bugs. Indeed you have my patch for 
register spill. The register allocation order is an off shoot from this to 
cover the possibility that patch would produce less optimum code.

Some of the others bugs less easy to reproduce on newer versions of gcc - also 
fixing one problem often prevent the other occuring. And having multiple 
gcc/winavr version is tricky enough with 2.

I have some WIP for other bugs - but have not posted any resolution yet.

> 
> Eric Weddington