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

[Victor Aprea]

ICBW but I think the CodeBender 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

address@hidden

T: @vicatcu

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