Weddington, Eric wrote:
-----Original Message-----
From: John Regehr [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 13, 2008 9:40 AM
To: Weddington, Eric
Cc: Arnim Littek; [email protected]
Subject: RE: [avr-gcc-list] AVR LLVM backend?
In my opinion the advantage of llvm-avr-gcc wouldn't so much
be better
code (though it may be a bit better) but rather decreased compiler
maintenance effort. The LLVM interfaces seem (1) pretty
stable and (2)
relatively narrow compared to gcc's.
And that decreased maintenance effort is a compelling argument.
Someone should just do it. A hacky backend supporting only
the megas is
probably less than a month effort for a reasonable hacker. Then if
initial results are promising, others will jump in to help
and eventually
perhaps an avr-gcc replacement would emerge.
Great! Do you have a month's worth of free time? ;-)
I sure don't at this point in time. Perhaps sometime next year I will.
In my opinion LLVM needs a few tweaks before it's a really
strong embedded
compiler. For example its inliner can cause significant
bloat even at
-Os. But overall it is quite good. On the other hand there are the
advantages above plus the developers are extremely responsive. For
example in the past year I've been reporting lots of bugs in
compilers'
implementations of volatile. The LLVM people almost always
fix bugs in a
few days whereas there's at least one volatile bug that has
sat in the gcc
bugzilla for 6 months without even being confirmed. As a
result LLVM is
at present almost totally volatile-correct, gcc has a ways to go.
And their developers' responsiveness is one of the major reasons why I have
been considering it.
There are a few features of LLVM that appeal to me (I haven't tried it,
but I've read through some of their website on a couple of occasions).
It looks to me that their compiler structure cleaner and more modular,
and thus more of the optimisations and features are in the middle-end,
independent of the front-end language and the back-end target. It also
seems that it is easier to add or change parts, which would make
development and testing faster, simpler, and less likely to break things.
One of the highlights of LLVM, especially in the context of embedded
systems, is link-time optimisation. The traditional
compile-assemble-link cycle of gcc (and most C compilers) is really a
hang-over from twenty years ago when computers did not have the
resources to handle a program all at once. LLVM (AFAIU) analyses source
files and converts them to LLVM code on "compilation", but does not
fully optimise and convert to target code until linking the code. This
can be a vast improvement, and would be specially useful in small
embedded systems where code space is often tight, and where you have the
complete program on-hand.
The latest versions of gcc can do this to a fair extent with
-fwhole-program and -fcombine, but it's still only a partial solution.
It doesn't support C++, and it doesn't work if you have a more modular
source code and want to compile code in stages. It is fine for smaller
programs, but far too limited for larger programs.
Proper link-time optimisation is becoming a missing feature when
comparing gcc to other compilers. When you look at information about
commercial embedded compilers, they are full of terms like "whole
program optimisation" and "omniscient code generation".
I have seen significant differences in the code size of avr programs
using -fwhole-program and -fcombine (something like 15% savings on size
on a small program). With larger programs, the size difference can be
larger. More importantly, you can write more natural and modular code -
you can put more code in C files instead of headers, and have C
functions calculate values instead of hard-coding them or using macros.
One possible problem with LLVM, as far as I have read, is that it is
aimed at 32-bit processors - the LLVM language seems to have little
support for working directly with 16-bit or 8-bit data. This may mean
that an 8-bit back-end will generate very inefficient code, or will have
to work specially hard to figure out what calculations can be done in
8-bit data (somewhat like fighting C's insistence on promoting
everything to int, only worse).
I too would love to have a month of free time to work on this!
mvh.,
David
_______________________________________________
AVR-GCC-list mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
