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