> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 10, 2008 11:48 AM > To: [email protected]; 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 _______________________________________________ AVR-GCC-list mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
