Bug 56700 - Optimizing at compile and link result in different binary size than only optimizing at link time
Summary: Optimizing at compile and link result in different binary size than only opti...
Status: RESOLVED DUPLICATE of bug 55102
Alias: None
Product: gcc
Classification: Unclassified
Component: lto (show other bugs)
Version: lto
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-23 19:34 UTC by uran238
Modified: 2018-11-15 00:41 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description uran238 2013-03-23 19:34:43 UTC
When I'm building wget (1.14) with CFLAGS=LDFLAGS="-Os -flto" the resulting binary is about 5-8% smaller than building with CFLGAS="-flto" LDFLAGS="-Os -flto".

Adding -fno-fat-lto-objects leads to very similar results (~50 Bytes difference).

Here are the (stripped) sizes:
CFLAGS=-Os LDFLAGS=-Os
gcc-4.7.2: 353904
gcc-4.8.0: 349808

CFLAGS=-O0 -flto LDFLAGS=-Os -flto
gcc-4.7.2: 353408
gcc-4.8.0: 360696

CFLAGS=-Os -flto LDFLAGS=-Os -flto
gcc-4.7.2: 336896
gcc-4.8.0: 332784

So not optimizing for size during compile leads to worse results than omitting lto at all for gcc-4.8

I thought optimizations can be ommitted completely during compile, when doing lto.
Comment 1 Eric Botcazou 2013-03-24 11:39:15 UTC
> So not optimizing for size during compile leads to worse results than omitting
> lto at all for gcc-4.8
> 
> I thought optimizations can be ommitted completely during compile, when doing
> lto.

Absolutely not, where did you get this info from?  You should pass the same optimization options at compile and link stage, the compiler will do the rest.
Comment 2 uran238 2013-03-26 18:46:25 UTC
> where did you get this info from?

From the man page:

<snip>
The only important thing to keep in mind is that to enable link-time optimizations the -flto flag needs to be passed to both the compile and the link commands. 
[...]
Additionally, the optimization flags used to compile individual files are not necessarily related to those used at link time. For instance, 

 

        gcc -c -O0 -flto foo.c
        gcc -c -O0 -flto bar.c
        gcc -o myprog -flto -O3 foo.o bar.o



 This produces individual object files with unoptimized assembler code, but the resulting binary myprog is optimized at -O3. If, instead, the final binary is generated without -flto, then myprog is not optimized.
</snip>

Misleading at best.
If "the resulting binary" "is optimized at -O3", but that's not the same as optimizing the individual object files and the resulting binary at -O3, that's definitely worth mentioning.
Please clarify that in the man page. It's not just me who concluded that wrong.
Comment 3 Dmitry Gorbachev 2013-03-26 20:12:42 UTC
> It's not just me who concluded that wrong.

Bug 55102.
Comment 4 Eric Botcazou 2013-03-26 20:51:48 UTC
Dup.

*** This bug has been marked as a duplicate of bug 55102 ***
Comment 5 sandra 2018-11-15 00:41:42 UTC
Author: sandra
Date: Thu Nov 15 00:41:10 2018
New Revision: 266168

URL: https://gcc.gnu.org/viewcvs?rev=266168&root=gcc&view=rev
Log:
2018-11-14  Sandra Loosemore  <sandra@codesourcery.com>

	PR lto/55102
	PR lto/56700

	gcc/
	* doc/invoke.texi (Optimize Options): Remove bad example about
	interaction between -flto and -O.  Replace it with a note that
	you need to compile with -O and not just link.  Copy-edit -flto
	discussion to reduce verbiage and improve flow.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/doc/invoke.texi