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

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of David Brown
> Sent: Thursday, November 13, 2008 1:57 PM
> To: address@hidden
> Subject: [avr-gcc-list] Re: AVR LLVM backend?
> 
> 
> 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 agree with you wholeheartedly. I saw this too when I perused their website. 
Yes, the link time optimizations are a very big draw.


 
> 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.

My experience with -fwhole-program -fcombine has been less than stellar. I have 
seen a 25% code reduction, which is great! But I have also seen up to 25% code 
*increase*, which is really bad. I would have thought that, at the very least, 
they would ensure that the code size would not increase. But because of this 
wide range of results, I can't always rely on those switches, which is a real 
shame.

 
> 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).

This is what I have been afraid of. But, if overall, the backends are cleaner, 
and easier to write, then perhaps there is a way to graft an AVR backend to the 
project.

Eric