avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Brown
Subject: Re: [avr-gcc-list] LLVM 4.0 AVR backend
Date: Thu, 16 Mar 2017 12:12:11 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]