[avr-gcc-list] Re: Code optimistaion in AVR Tiny13

[David Brown]

Weddington, Eric wrote:
> > -----Original Message----- From: 
> > address@hidden 
> > [mailto:address@hidden org]
> > On Behalf Of David Brown Sent: Monday, February 16, 2009 5:07 PM 
> > To: address@hidden Subject: [avr-gcc-list] Re: Code
> > optimistaion in AVR Tiny13
> >
> > Weddington, Eric wrote:
> > > > -----Original Message----- From: 
> > > > address@hidden 
> > > > [mailto:address@hidden
> > > > org] On Behalf Of David Brown Sent: Monday, February 16, 2009
> > > > 2:31 PM To: address@hidden 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. :-/

We can always hope that the people working on gcc link time optimisation 
eventual get something working - that will make -fwhole-program and 
-combine fairly redundant.  It seems that LTO *is* of interest to 
companies like Google and the other "big players".

Getting maintainers for parts of gcc outside of the x86 realm is always 
going to be tough.  There are not many companies that are willing to pay 
someone to do the work, embedded development is a branch where people 
already tend to work very long hours (and some of us have a family they 
like to see on occasion...), making it hard on volunteers.  I'm probably 
not alone in wanting to help out, but simply not having the time.

Would it help if people tell Atmel that we consider avr-gcc to be a 
selling point of the AVR's?  I used to prefer the msp430 devices because 
of their good gcc support (they are a far easier fit for gcc than the 
AVR), but msp430-gcc has stagnated at about gcc 3.2, and avr-gcc (and 
the library) are now far beyond the msp430 port.  This is definitely one 
of the reasons we now buy more AVR's and far fewer msp430 devices.

Is there much cooperation between the avr-gcc development and the 
avr32-gcc development?  Although the avr32 is not an official gcc port, 
it certainly seems that Atmel is putting a lot of effort into it.  While 
the AP700x devices are "big" processors, the UC3 parts are small enough 
that they could benefit from -fwhole-program, -combine, and 
-frtl-abstract-sequences.

mvh.,

David