On 01/08/17 13:08, Eric Gallager wrote: > On 8/1/17, Richard Biener <richard.guent...@gmail.com> wrote:
>> >> Heh. I suspect -Os would benefit from a separate compilation pipeline >> such as -Og. Nowadays the early optimization pipeline is what you >> want (mostly simple CSE & jump optimizations, focused on code >> size improvements). That doesn't get you any loop optimizations but >> loop optimizations always have the chance to increase code size >> or register pressure. >> > > Maybe in addition to the -Os optimization level, GCC mainline could > also add the -Oz optimization level like Apple's GCC had, and clang > still has? Basically -Os is -O2 with additional code size focus, > whereas -Oz is -O0 with the same code size focus. Adding it to the > FSF's GCC, too, could help reduce code size even further than -Os > currently does. > I would not expect that to be good at all. With no optimisation (-O0), gcc produces quite poor code - local variables are not put in registers or "optimised away", there is no strength reduction, etc. For an architecture like the AVR with a fair number of registers (32, albeit 8-bit registers) and relatively inefficient stack access, -O0 produces /terrible/ code. There is also the body of existing code, projects, practice and knowledge - all of that says "-Os" is for optimised code with an emphasis on size, and it is the flag of choice on a large proportion of embedded projects (not just for the AVR). The ideal solution is to fix gcc so that -Os gives (close to) minimal code size, or at least as good as it used to give - while retaining the benefits of the newer optimisations and features of later gcc versions. The question is, can this be done in a way that is practical, maintainable, achievable with the limited resources of the AVR port, and without detriment to any of the other ports? As has been noted, the AVR port is considered a minor port for gcc (though it is vital for the AVR development community), and other ports have seen a trend of improvement in code size - gcc can't take changes to improve the AVR if it makes things worse for MIPS. Is it possible to get some improvement in AVR generation by enabling or disabling specific combinations of optimisation in addition to -Os? Are there tunables that could be fiddled with to improve matters (either "--param" options, or in the AVR backend code)? Can the "-fdump-rtl" or "-fopt-info" flags be used to get an idea of which passes lead to code increase? If these led to improvements, then it should be possible to better the situation by simply changing the defaults used by the AVR port. Of course, this sort of analysis would require significant effort - but not many changes to the gcc code. Could Microchip (who now own Atmel, the AVR manufacturer) provide the resources for the work? It is clearly in their interest that the AVR port of gcc is as good as it can be - they ship it as part of their standard development tools.
