On 31/07/17 15:25, Georg-Johann Lay wrote: > This weekend I un-mothed an old project, just an innocent game on a > cathode-ray-tube, driven by some AVR µC. After preparing the software > so that it compiled with good old v3.4, the results overwhelmed me > with complete frustration: Any version from v4.7 up to v8 which I > fed into the compiler (six major version to be precise), produced a > code > 25% larger than compiled with v3.4.6 and the code is not only > bigger, it's all needless bloat that will also slow down the result; > optimizing for speed might bloat and slow even more. >
At the risk of stirring up a hornets nest, have you tried the AVR backend of LLVM/clang ? It is still a work in progress, and I haven't tried it at all myself (my experience with clang is very minimal). Ultimately, the aim of the AVR gcc users community is to have free, cross-platform tools that will work with their existing and future code and generate good AVR object code. Few users really care if it is gcc or clang (especially if the clang binaries are named "avr-gcc"). And ultimately the aim of Microchip, who make and sell the chips themselves, should be to keep the users happy. If the structure of llvm/clang is such that it makes more sense for Microchip to put resources into that project, and when it is good enough they could move to it as their default toolchain for users, then the quality of AVR code generation in gcc becomes a non-issue. (Personally, I like to see friendly competition between llvm/clang and gcc, as I think it has helped both projects, but there are severe limits to the development resources that can be put into a minor target like this.)
