ICBW but I think the CodeBender <https://github.com/codebendercc/compiler> team were using Clang at least, though I don't think they were using LLVM. GCC is pretty entrenched, but there was a good deal of excitement about the rise of LLVM last year IIRC...
Cheers, Vic Victor Aprea // Wicked Device victor.ap...@wickeddevice.com T: @vicatcu <http://twitter.com/vicatcu/> On Thu, Mar 16, 2017 at 7:12 AM, David Brown <da...@westcontrol.com> wrote: > On 16/03/17 11:22, Senthil Kumar Selvaraj wrote: > > > > David Brown writes: > > > >> It might be a little heretical to ask here, but has anyone tried out the > >> experimental AVR backend in the latest llvm/clang release? I have not > >> made much use of clang, but it's been good for gcc to have a bit of > >> friendly competition. I think it will be interesting to see how > >> clang/llvm differs from gcc for the AVR. > > > > I built it a while back when I added basic support for avr to clang. > > Dylan McKay, who IIRC has corresponded in this list before, owns the > > backend, and has added a bunch of support to clang as well. His > > primary motivation is to get the Rust programming language running on > > the avr, again IIRC. > > > > Last I checked, I still had to use the binutils linker, as lld didn't > > yet know about the avr. The generated code did look suboptimal compared > > to gcc, but I didn't play around much to be honest. > > > > Thanks for that information. > > It would be interesting to know if clang/llvm could generate better code > for the AVR. gcc has a few fundamental problems with the port. In > particular, gcc expects its targets to have registers capable of holding > an int - in this case, 16 bits. So the AVR port of gcc has to work with > register pairs r0:r1, r2:r3, r4:r5, etc., and then the backend peephole > passes try to remove redundant operations. But there are always some > redundant operations that get left, and the register allocator cannot > take full advantage of the AVR's registers when you are using 8-bit > types. I have no idea if the same thing affects llvm, or if there is > potential for getting better results there. > > Of course, this would require someone spending a good deal of time and > effort on the task - it would be a challenge to justify it as a business > decision for Microchip. > > > > _______________________________________________ > AVR-GCC-list mailing list > AVR-GCC-list@nongnu.org > https://lists.nongnu.org/mailman/listinfo/avr-gcc-list >
_______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
