Re: LLVM 4.0 AVR backend

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
[email protected]
T: @vicatcu <http://twitter.com/vicatcu/>

On Thu, Mar 16, 2017 at 7:12 AM, David Brown <[email protected]> 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
> [email protected]
> https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>

_______________________________________________
AVR-GCC-list mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list