[avr-gcc-list] Re: AVR LLVM backend?

[David Brown]

Weddington, Eric wrote:
>  
>
> > -----Original Message-----
> > From: John Regehr [mailto:address@hidden 
> > Sent: Thursday, November 13, 2008 9:40 AM
> > To: Weddington, Eric
> > Cc: Arnim Littek; address@hidden
> > 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