Arch Linux

orlandu63

Member

Registered: 2010-03-29

Posts: 29

Adding -flto and related flags to default CFLAGS…

What with version 4.6 released, the gcc teams now considers its link-time optimization feature to be stable. (It's stable enough that there have been reports of successful compilations of gigantic projects like firefox and chromium with -flto, at least.) For those that don't know, link-time optimization is a compilation method that defers the optimization phase of a compiler towards the very end of the compilation cycle. It allows the compiler to perform project-wide analyses and optimizations (as opposed to only file-wide, which is the default behavior), which results in a faster and smaller binary/library (for free!). In gcc 4.5, LTO was quite buggy especially wrt to building libraries but it seems that the 4.6 release has ironed things out. This would mostly benefit larger projects such as DEs, web browsers and programming languages which are composed of hundreds of separate source files, which normally would get optimized separately.

In my opinion, it seems agreeable with The Arch Way to possibly enable LTO by default. The extra performance (if negligible in some cases) would be nice to have for those of us running Arch on low-powered netbooks and tablets. Not to mention the optimization is (mostly) free, with no strings attached. The only problem I currently see with enabling LTO by default is that conditionally disabling it would be inconvenient as there seems to be no -fno-flto flag or similar. (I may be wrong on this.)

What are the developers' opinions on this?

Some relevant compiler flags:

* -fwhopr → like -flto but splits the compilation step into multiple parts in order to reduce memory usage during linking
* -fuse-linker-plugin → uses the gold linker; it is faster and more memory efficient than the default linker

karol

Archivist

Registered: 2009-05-06

Posts: 25,440

Re: Adding -flto and related flags to default CFLAGS…

Is it related to http://mailman.archlinux.org/pipermail/ … 20231.html ?

Last edited by karol (2011-05-04 22:10:09)

orlandu63

Member

Registered: 2010-03-29

Posts: 29

Re: Adding -flto and related flags to default CFLAGS…

Is it related to http://mailman.archlinux.org/pipermail/ … 20231.html ?

Yes; that message persuaded me to suggest this. I would have posted this in the ML but the last time I tried that I received an "unauthorized to post" error, ending up feeling like an idiot. I decided to play it safe and post it in the forums.

karol

Archivist

Registered: 2009-05-06

Posts: 25,440

Re: Adding -flto and related flags to default CFLAGS…

Something tells me arch-dev-public is read-only but you can send your questions & suggestions to http://mailman.archlinux.org/mailman/li … ch-general.

Allan

Pacman

From: Brisbane, AU

Registered: 2007-06-09

Posts: 11,540

Website

Re: Adding -flto and related flags to default CFLAGS…

LTO may be consinered stable, but I would say it is not quite ready for use on an entier distro yet given the number of bug fixes that have been pulled into binutils and gcc recently to fix issues with it.    I'd same the same goes with GOLD, given I have not actually heard of anyone building an entire system using it yet.

---

PGP Key: F99FFE0FEAE999BD | I develop pacman - buy me a drink!

falconindy

Developer

From: New York, USA

Registered: 2009-10-22

Posts: 4,111

Website

Re: Adding -flto and related flags to default CFLAGS…

In my experience, lto breaks a bunch of builds (you'll often see physmem.c errors) and actually reduces performance of some programs. I noticed when building yajl 2, there was about a 7% loss in parsing performance by enabling lto.

---

blog | ±github

Grinch

Member

Registered: 2010-11-07

Posts: 265

Re: Adding -flto and related flags to default CFLAGS…

That likely means that you didn't enable LTO correctly, I haven't tried LTO on 4.6 yet but on 4.5 you needed to pass the optimization options both at compile stage (CFLAGS,CXXFLAGS) and link stage (LDFLAGS) else the resulting binary ends up without optimization and obviously slower. On 4.5 you needed to pass -flto -fwhole-program + whatever other optimization flags you use to your CFLAGS, and then pass the same to your LDFLAGS.

I've never encountered LTO making a program slower, but depending on how the code was written there is sometimes very little gain from using LTO.

I have seen it break alot of stuff though, so I wouldn't recommend using it by default unless this has changed alot in 4.6.

falconindy

Developer

From: New York, USA

Registered: 2009-10-22

Posts: 4,111

Website

Re: Adding -flto and related flags to default CFLAGS…

I wouldn't rule it out The breakages I mention are indeed with 4.6.

fwiw, adding -Wl,-O1 and -Wl,--sort-common to my LDFLAGS produces an enormous, almost unreasonable, gain in yajl's parsing performance (230Mb/s -> 300Mb/s). I wouldn't expect that to translate to a 30% performance increase across all programs, but that's pretty significant.

---

blog | ±github

Grinch

Member

Registered: 2010-11-07

Posts: 265

Re: Adding -flto and related flags to default CFLAGS…

Yes that's a very good performance increase (jealous!), I haven't come across any such boost with LTO on the programs I've benchmarked, typically 5-8% range. Using PGO (profile guided optimization) however, I've often gotten ~20-25%  performance increase on cpu intensive programs, but that's certainly not an option one can set to default given that it requires you to compile the program twice and execute it between those compiles in order to gather runtime statistics needed to perform the best possible optimizations. One nice thing with LTO apart from the performance boost is that the binaries often end up quite a bit smaller).

falconindy

Developer

From: New York, USA

Registered: 2009-10-22

Posts: 4,111

Website

Re: Adding -flto and related flags to default CFLAGS…

One nice thing with LTO apart from the performance boost is that the binaries often end up quite a bit smaller).

I'll be looking forward to that, given that binary size has only increased with the upgrades to gcc 4.4, 4.5 and 4.6

---

blog | ±github