Re: LLVM 4.0 AVR backend

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.

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

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

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.