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.
_______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
