| View previous topic :: View next topic |
| Author |
Message |
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 4076
Location: Rasi, Finland
|
 Posted: Thu Apr 10, 2025 8:47 am Post subject: LTO - how the process works? |
 |
|
I've recently only started to play around with LTO.
I've tested this on few big packages. Most notably with qtwebengine.
With LTO on the packages get build twice. Right? From the first build the some optimizer can determine better linking then the build is done again. Right?
Right now there's a single lto1 process doing... something? I guess it's picking up the most optimal assembled parts or something...
Can someone explain how the LTO compilation process goes? Explain to someone who has normally only done "-O2 -march=native" and binary comes out.
I want to know better, since I'm planning to set up some generic bin host. I guess older hardware could benefit from LTO'd binaries. Right?
_________________
..: Zucca :..
| My gentoo installs: | init=/sbin/openrc-init
-systemd -logind -elogind seatd |
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
 |
Perfect Gentleman
Veteran
Joined: 18 May 2014
Posts: 1259
|
| Posted: Thu Apr 10, 2025 8:50 am Post subject: |
|
|
| Quote: | | With LTO on the packages get build twice. Right? From the first build the some optimizer can determine better linking then the build is done again. Right? |
Nope and nope. It's PGO works in that way. |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 4076
Location: Rasi, Finland
|
| Posted: Thu Apr 10, 2025 8:59 am Post subject: |
|
|
| Perfect Gentleman wrote: | | Quote: | | With LTO on the packages get build twice. Right? From the first build the some optimizer can determine better linking then the build is done again. Right? |
Nope and nope. It's PGO works in that way. |
Ah yes. I've mixed the information I've read earlier.
_________________
..: Zucca :..
| My gentoo installs: | init=/sbin/openrc-init
-systemd -logind -elogind seatd |
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 3005
|
| Posted: Thu Apr 10, 2025 10:44 am Post subject: |
|
|
With LTO the compiler emits additional output that is then used by the linker, but how exactly, I don't know.
PGO on the other hands relies on profiling data that's collected during the execution of that first stage compilation you mention above and then is used by the compiler to pay special attention to certain parts of the code in regards to optimization.
LTO may look as though it compiles two times but it doesn't. The second stage is that link time optimization which too takes noticeable time.
Best Regards,
Georgi |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 2334
|
| Posted: Thu Apr 10, 2025 11:27 am Post subject: |
|
|
LTO is great and you should play with it if you're willing to live with increased build times.
LTO works by partially compiling files the first time and gathering information: translation units (TUs) get compiled to compiler internal representation (IR). At link-time, the compiler gathers all of these and runs the rest of the optimisation passes, and is able to treat it as one large program, inlining across boundaries and so on. That second part is the slower bit. |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 3005
|
| Posted: Thu Apr 10, 2025 2:59 pm Post subject: |
|
|
| sam_ wrote: |
LTO works by partially compiling files the first time and gathering information: translation units (TUs) get compiled to compiler internal representation (IR). At link-time, the compiler gathers all of these and runs the rest of the optimisation passes, and is able to treat it as one large program, inlining across boundaries and so on. That second part is the slower bit. |
Thanks for the explanation, I didn't know that.
| sam_ wrote: | | LTO is great and you should play with it if you're willing to live with increased build times. |
I should add it uses significant amount of RAM too.
I don't remember very well as I haven't compiled Chromium recently but I think RAM usage for LTO phase was comparable to the usage in the first phase, which is comparable to normal compilation usage.
Best Regards,
Georgi |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 4076
Location: Rasi, Finland
|
| Posted: Thu Apr 10, 2025 4:44 pm Post subject: |
|
|
I did a test with nodejs. I unmasked the lto USE flag for it (maybe I shouldn't) then applied the things the wiki told.
I think compilation took a around 1.3Gb to 1.4Gb per thread at max.
I think I'll restore the use.mask now. I don't want a broken nodejs in my system.
I'll start applying lto to some big packages.
Plan is to create few bin repos...
_________________
..: Zucca :..
| My gentoo installs: | init=/sbin/openrc-init
-systemd -logind -elogind seatd |
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 3005
|
| Posted: Thu Apr 10, 2025 5:24 pm Post subject: |
|
|
| Zucca wrote: | | I did a test with nodejs. I unmasked the lto USE flag for it (maybe I shouldn't) then applied the things the wiki told. |
I don't think you need to do anything other than enabling the flag. The wiki tells you what to do in case there isn't.
Best Regards,
Georgi |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 4076
Location: Rasi, Finland
|
| Posted: Thu Apr 10, 2025 6:03 pm Post subject: |
|
|
I had the impression that if a package has lto -USE flag, then by enabling it the build process changes so that lto can be enabled. Then user may choose which *FLAGS to set.
_________________
..: Zucca :..
| My gentoo installs: | init=/sbin/openrc-init
-systemd -logind -elogind seatd |
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 2334
|
| Posted: Thu Apr 10, 2025 6:33 pm Post subject: |
|
|
USE=lto is being phased out. It exists for a few packages still but most of the time, USE=lto only added -flto anyway. So, in some cases, we're removing all of that infra entirely. In other cases, we're detecting if LTO is enabled via *FLAGS, then passing the option to the build system as if USE=lto.
All you need to do is set the CFLAGS (and other *FLAGS) per the LTO wiki page. Nothing else. You can put USE=lto in make.conf or package.use to cover stragglers that have not yet been ported to the new way too, if you want. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1876
Location: South America
|
| Posted: Thu Apr 10, 2025 9:46 pm Post subject: |
|
|
| sam_ wrote: | | LTO works by partially compiling files the first time and gathering information: translation units (TUs) get compiled to compiler internal representation (IR). At link-time, the compiler gathers all of these and runs the rest of the optimisation passes, and is able to treat it as one large program, inlining across boundaries and so on. |
And, if you feel like explaining, what are the things that can cause breakages with LTO? You know, the situations that we see reported here sometimes where a failure is magically solved by disabling LTO.
The Wiki article says that it can happen, but not much about why.
_________________
| NeddySeagoon wrote: | I'm not a witch, I'm a retired electronics engineer  |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 2334
|
| Posted: Fri Apr 11, 2025 3:36 pm Post subject: |
|
|
| GDH-gentoo wrote: | | sam_ wrote: | | LTO works by partially compiling files the first time and gathering information: translation units (TUs) get compiled to compiler internal representation (IR). At link-time, the compiler gathers all of these and runs the rest of the optimisation passes, and is able to treat it as one large program, inlining across boundaries and so on. |
And, if you feel like explaining, what are the things that can cause breakages with LTO? You know, the situations that we see reported here sometimes where a failure is magically solved by disabling LTO.
The Wiki article says that it can happen, but not much about why. |
Sure!
Inlining is really one of the true engines of optimisation. It unlocks everything else. You can (partially) inline something and you can suddenly infer a bunch more, you can assume the value of a variable, you can then delete a bunch of code, and so on. Inlining happens between functions without LTO, but not between TUs.
Short of compiler bugs, which are rare but can happen anyway even without LTO, what it refers to there is really cross-TU inlining from LTO that exposes a bug (usually UB in the program).
Constructing a quick example is a pain because null pointer dereferences usually trap, but if you look at e.g. the examples on https://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html, but imagine the dereference being in another function that calls it instead, that hopefully gets the idea across.
So, in one TU:
| Code: |
void contains_null_check(int *P) {
if (P == 0)
return;
*P = 4;
}
|
And in another:
| Code: |
void foo() {
int dead = *P; /* The knowledge from this dereference (=> P must be non-null) may be propagated into contains_null_check. */
contains_null_check(P);
}
|
|
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 4076
Location: Rasi, Finland
|
| Posted: Sat Apr 12, 2025 1:04 pm Post subject: |
|
|
Thanks sam, for such detailed answers in this topic. Really appreciated.
_________________
..: Zucca :..
| My gentoo installs: | init=/sbin/openrc-init
-systemd -logind -elogind seatd |
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
|
Portage & Programming
