> -----Original Message----- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > org] On Behalf Of David Brown > Sent: Thursday, November 13, 2008 1:57 PM > To: [email protected] > 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 _______________________________________________ AVR-GCC-list mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
