Maintainer of the LLVM backend here. > 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.
That's interesting - LLVM doesn't have this specific problem. One problem the backend _does_ have is that LLVM assumes that the size of your largest register makes up the standard register size. This means that LLVM sees the X,Y,Z pointer registers, assumes 16-bit operations are generally supported, and then doesn't decide to split many 16-bit operations into 8-bit ones. To work around this, we define sets of 16-bit pseudo instructions and then have a custom pass to lower the IR into assembly, often producing suboptimal code. This problem could be fixed, but it requires some changes to LLVM which are quite large. Regarding the state of the backend, GCC should definitely be preferred. Now that LLVM 4.0 has been tagged, we're working on enabling that AVR backend in Rust. There will likely be a few assertion errors and latent bugs being hit. On Fri, Mar 17, 2017 at 2:14 AM, Victor Aprea <victor.ap...@wickeddevice.com > wrote: > 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 > >
_______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
