Re: [avr-gcc-list] binutils 2.22 blow up program size with -flto

[David Brown]

On 12/08/2012 02:28, Volker Kuhlmann wrote:
> On Mon 30 Jul 2012 19:23:25 NZST +1200, David Brown wrote:
>
> > Also note that code size is not the only measure of how good a
> > compiler (or option) is.  While it is clearly an important measure
> > (especially on small systems), sometimes speed is more important.
>
> You've lost me here. What's your explanation of the meaning of the
> compiler flag -Os, as in -O*size*?
>
> In general of course you are right in size not being the only quality
> metric of a compiler's output, but right now it's the one most easily
> compared.

All I am trying to say is that there is sometimes a balance between 
different features of the generated code, and sometimes the balance 
changes with different compiler versions.  "-Os" says "optimise the code 
with an emphasis on code size" - it does /not/ say "generate the 
smallest possible code".  These are guidelines for the compiler, not 
absolute commands.  Taken to extremes, generating the smallest code 
would have horrendous run-time speeds as common sequences of four or 
more instructions get factored out as function calls.

In general, of course, one would hope that newer tools or more powerful 
options would lead to smaller resulting code (with -Os) that is at least 
as fast as for older tools.

> More so than speed I value producing *correct* code. Here of course 4.7
> might be better than 4.3 even if the program is slightly bigger. In my
> test application I haven't found a translation problem yet and it runs
> as expected - obviously that's nowhere near an exhaustive comparison
> though.

Correctness may also be an issue - occasionally it happens that a tool 
generates really small and fast code that may contain bugs, and in 
correcting those bugs later tools make bigger or slower code.

I don't know the situation here, and I'm probably not helping by 
stabbing in the dark, but I am just trying to vaguely suggest that maybe 
the newer tools are better in general, even if the code size is bigger.

> Volker