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

[David Brown]

On 17/03/17 17:02, Georg-Johann Lay wrote:
> On 16.03.2017 12:12, David Brown wrote:
>> 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
> 
> No.
> 
>> register pairs r0:r1, r2:r3, r4:r5, etc., and then the backend peephole
> 
> That's not a "problem" of GCC, the avr backend chose to implement it
> that way, presumably to improve probability for MOVW which only works
> on register /pairs/, same for ADIW, SBIW.  I didn't try to remove
> that restriction from the backend for non-MOVW targets, but it would
> be also an ABI change because inline asm constraint "r" guarantees
> a register pair.

OK - thank you for the correction.

> 
> And I wouldn't expect a dramatic increase of code performance from
> allowing odd registers.

Really?  I would have thought it could be significant, at least when the
programmer is careful to use 8-bit types when possible.  I have
certainly seen generated code where data is put in stack frames even
though there are odd registers that have not been used.  However, it is
a long time since I have updated my avr gcc (the latest I have used is
4.5.1), if things have changed here.

> 
>> 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.
> 
> Some of the artefacts are due to GCC being a multi-pass compiler, and
> it's not always clear whether it is wise to split an instruction before
> register allocation.  Most complaints address twiddling bytes like
> when combining several bytes into one scalar.  One approach is more
> combining and post-reload splitting which I added some time ago.
> But as always, I won't backport pure optimizations and will follow
> GCC policy to only backport "real" bug fixes.

Of course.  Backporting quickly leads to duplicate effort, so it only
makes sense for serious problems such as incorrect code generation.

Maybe I just need to update my avr gcc compiler!

> 
> Johann
> 
>> 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.
>