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: Dylan McKay
Subject: Re: [avr-gcc-list] LLVM 4.0 AVR backend
Date: Fri, 17 Mar 2017 10:33:37 +1300

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 <address@hidden> wrote:
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

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


_______________________________________________
AVR-GCC-list mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list



reply via email to

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