This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Overwhelmed by GCC frustration

On 01/08/17 13:08, Eric Gallager wrote:
> On 8/1/17, Richard Biener <> 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]