> -----Original Message----- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > org] On Behalf Of Bernard Fouché > Sent: Friday, July 04, 2008 8:54 AM > To: Wouter van Gulik > Cc: avr-libc-dev@nongnu.org > Subject: Re: [avr-libc-dev] Definition of putchar/getchar > causes code growth > > Hi. > > I just began yesterday to move from gcc-4.2.0/avr-libc-1.4.6 to > gcc-4.3.0/avr-libc-1.6.2 (with the patches taken from WINAVR0610). > > I first experienced a significant code growth (about 4%) because of: > > - functions like eeprom_read/write_byte() that now inline more code, > hence I had to write wrapper functions like you did in your > example for > putchar(). In a previous run of 'hand optimization', I did replace > fputc() calls directly to 'myputc' (stream->putc()), sparing > even more > bytes (the size of fputc()) while getting more speed (often > the checks > performed in fputc() (i.e. (if((stream->flags...)) are > useless (depends > on the application considered)). > > - gcc-4.3.0 seems to automatically inline bigger static > functions than > gcc-4.2.0. I have to use -finline-limit to a very low value like 10. > > I now have a code size with gcc-4.3.0/avr-libc-1.6.2 a litle > bit smaller > than with gcc-4.2.0/avr-libc-1.4.6. (and I will have to perform > extensive tests to check that the application still works :)) and I > reclaimed the 256 bytes of RAM that were previously lost because of > __clz_tab (my main reason for moving to a newer compilation chain) > > IMHO the 'stock' distribution of avr-gcc/avr-libc should be tuned to > give results as good (hence small) as possible with -Os since most of > the traffic in the mailing lists seems code size oriented, so > I have a > point of view similar to Wouter.
The developers of the AVR toolchain are already aware of these issues. Yes, we agree that the stock distributions should be tuned to give the best, smallest results with -Os. The problem is one of resources; there are a limited number of people working on the AVR toolchain, and practically all are volunteers. > IMHO: reliable, small, tunable, in that order. > > -dave I certainly agree with Dave on this. Reliability was the reason for the change to the EEPROM routines, as was discussed extensively on this list a while back before the changes went in. Yes, it's unfortunate that GCC 4.3.x does more aggressive inlining, which is a detriment on the AVR causing code size increases. The inlining heuristics need to be tuned for the AVR port. It seems that this was only discovered *after* the release. But at this point, the AVR developers have been working aggressively on the "reliability" factor. The GCC Regression Test Suite has been getting a lot of work for the AVR port. The AVR port is getting tested with the Regression Test Suite on an almost daily basis. Bugs that generate wrong-code, or involve internal compiler errors are getting fixed. However, the tradeoff is that bugs or problems involving optimizations are not getting as much attention, but they are getting some. Yes, we are aware of the issues and they will be addressed. Keep the reports coming. :-) Eric Weddington _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
