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

[John Regehr]

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

I believe that superior IR design is the main advantage of LLVM.  My 
experience (based on submitting many bug reports to both LLVM and GCC) has 
been that LLVM is just fundamentally easier to fix due to reduced coupling 
between its parts.  Every bug has been clearly in either the middle-end or 
a back-end, and fixes tend to be local.  From following bug-fixing 
discussions for gcc, my impression is that fixes are more likely to 
involve difficult global and/or cross-platform reasoning.  See this one 
for example:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35729

> 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'm pretty sure this is not an issue (anymore, at least).  I could be 
wrong.  The recently-added PIC port of LLVM would be a good place to start 
looking.  PIC is of course a particularly evil target.  I claim that if it 
can be supported at all, AVR should be easy :).

John Regehr