> -----Original Message----- > From: > [email protected] > [mailto:avr-gcc-list-bounces+eweddington=cso.atmel....@nongnu. > org] On Behalf Of David Brown > Sent: Monday, February 16, 2009 5:07 PM > To: [email protected] > Subject: [avr-gcc-list] Re: Code optimistaion in AVR Tiny13 > > Weddington, Eric wrote: > > > > > >> -----Original Message----- From: > >> [email protected] > >> [mailto:avr-gcc-list-bounces+eweddington=cso.atmel....@nongnu. org] > >> On Behalf Of David Brown Sent: Monday, February 16, 2009 2:31 PM > >> To: [email protected] Subject: [avr-gcc-list] Re: Code > >> optimistaion in AVR Tiny13 > >> > >> Another important point in getting code as small as possible is to > >> use -combine and -fwhole-program - it can significantly improve > >> code, especially for functions that are called only once but live > >> in different modules. > > > > In my tests on real world programs, it have decreased the code by up > > to 25%. And it has also *increased* the code by up to 25%! > > Unfortunately I don't know what about the code that causes it to > > increase. But clearly it is not always a win and can be a detriment. > > So be sure to check your code sizes when you use this. > > If these flags *increase* code size, there's a bug somewhere - or at > least some badly tuned parameters (such as -finline-limit, or > something > similar). They give the compiler increased knowledge and more > opportunity to combine code and do inter-procedural > optimisations across > compilation units. I've only used it myself on a couple of programs > (boot programs, which are particularly space-concious), and it helped > significantly.
Oh, I definitely agree that it could help significantly. The problem, again, has to do with maintenance. I spoke with one of the guys who works on gcc (for Google) and it seems that no one is really maintaining -fwhole-program. Most targets on gcc optimize for speed, not size. So there's no one to go to with problems with this switch. It's one of those: if we want it fixed, we have to do it ourselves because no one else is working on it. :-/ _______________________________________________ AVR-GCC-list mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
