Re: [avr-chat] Can't Install avr-gcc in FreeBSD

[David Brown]

Eric Weddington wrote:
> > -----Original Message-----
> > From: address@hidden
> > [mailto:address@hidden
> >  On Behalf Of Joerg Wunsch
> > Sent: Wednesday, August 22, 2007 1:28 PM
> > To: address@hidden
> > Subject: Re: [avr-chat] Can't Install avr-gcc in FreeBSD
> >
> > David Brown <address@hidden> wrote:
> >
> > > Back to gcc and other compilers - there is one area where
> > gcc lags many
> > > of the big names in commercial compilation.  ...
> > > ..., but what is
> > > lacking is proper link time optimisation.
> > My guess is this is mainly lack of experience with those features by
> > the GCC developers, rather than lack of the tools.  For example, Björn
> > Haase recently implemented linker relaxations for the AVR, which is
> > something I've already noticed (supposedly, in IAR generated code)
> > when disassembling the first JTAG ICE firmware years ago.  Still,
> > until very recently, there wasn't even the respective -mrelax option
> > available for AVR-GCC, you had to make your way through -Wl,-relax in
> > order to use it.  Anatoly recently changed that, as I understand.
>
> FYI, GCC does have an "LTO" project (Link Time Optimizations) that I guess
> several people are working on. It has it's own branch in the GCC repository.
> There was a talk about some of the LTO stuff at the most recent GCC Summit.
> There are some pages on it in the GCC wiki. Start here:
> <http://gcc.gnu.org/wiki/LinkTimeOptimization>
>
> So the GCC folks *are* working on it. Stuff like this takes time as, by
> nature, these folks are very conservative when making changes. They don't
> want to break things in the middle when they're adding things.
>
> Offhand, I don't know the schedule for inclusion of this. I tend to doubt
> that it will get included in 4.3. My gut feel is it might be in 4.4. But I
> could be horribly wrong.
>
> Eric

I read about the LTO project a few days ago (which is what made me think 
of it).  It seems people started looking at LTO for gcc about five years 
ago, yet it is still very much a work in progress - gcc 4.4 would be an 
optimistic (though not unrealistic) guess.  I understand that this is 
fairly hard stuff for gcc - it breaks the traditional sequence of phases 
of C compilation, and the gcc developers do not introduce such large 
changes without being very sure that it will work.  gcc's strengths in 
its portability and wide-spread use are also its weakness for this sort 
of thing - the changes have to work for half a dozen languages, several 
dozen targets, and vast ranges of projects from small embedded systems 
to huge desktop application projects.

mvh.,

David