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

[Weddington, Eric]

> -----Original Message-----
> From: address@hidden [mailto:address@hidden 
> Sent: Thursday, January 10, 2008 11:48 AM
> To: address@hidden; Weddington, Eric
> Subject: RE: [avr-gcc-list] GCC-AVR Register optimisations
> 
> 
> > 
> > - 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.

Thanks for the clarification. It certainly helps that the call order
essentially won't change. I'm still not fond of the idea of having to
change libgcc. It brings up a whole host of issues of synchronizing
these changes and introducing them to the end user.

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

Thanks again! I hope that your patch can be reviewed soon. :-)

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

I look forward to seeing your work when it's ready! :-)

Eric Weddington