[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Brown
Subject: Re: [avr-gcc-list] binutils 2.22 blow up program size with -flto
Date: Mon, 13 Aug 2012 11:36:11 +0200
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0

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

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]