Eric Weddington wrote:
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Joerg Wunsch
Sent: Wednesday, August 22, 2007 1:28 PM
To: [email protected]
Subject: Re: [avr-chat] Can't Install avr-gcc in FreeBSD
David Brown <[EMAIL PROTECTED]> 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
_______________________________________________
AVR-chat mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-chat