| View previous topic :: View next topic |
| Author |
Message |
papu
l33t
Joined: 25 Jan 2008
Posts: 746
Location: Sota algun pi o alzina...
|
 Posted: Sun Aug 18, 2024 9:01 pm Post subject: Does gcc support thinlto? |
 |
|
hi,
I am not sure if gcc have thinLTO like clang has,
if yes , are there same level of performance between gcc and clang with thin?
COMMON_FLAGS="-O2 -pipe -march=native -flto=thin"
COMMON_FLAGS="-O2 -pipe -march=native -flto"
thanks 
_________________
~amd64 & openrc --cpu 7700 --ram 2x32GB --gpu RX 6600 |
|
| Back to top |
|
 |
krumpf
Apprentice
Joined: 15 Jul 2018
Posts: 228
|
| Posted: Sun Aug 18, 2024 9:12 pm Post subject: |
|
|
From GCC flto documentation :
| Quote: | -flto[=n]
If you specify the optional n, the optimization and code generation done at link time is executed in parallel using n parallel jobs by utilizing an installed make program.
[…]
Use -flto=auto to use GNU make’s job server, if available, or otherwise fall back to autodetection of the number of CPU threads present in your system. |
Afaik, there's no thinlto in gcc, it's specific to clang.
If you want to get better lto performance when using gcc, try to install and setup the mold linker.
_________________
Dragon Princess Music Games Heroes and villains |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23540
|
| Posted: Sun Aug 18, 2024 9:21 pm Post subject: |
|
|
| gcc supports -ffat-lto-objects and -fno-fat-lto-objects, where the latter would seem to be the "thin" variant. Per info gcc, no-fat is default on targets with linker plugin support. |
|
| Back to top |
|
|
papu
l33t
Joined: 25 Jan 2008
Posts: 746
Location: Sota algun pi o alzina...
|
| Posted: Sun Aug 18, 2024 9:30 pm Post subject: |
|
|
| krumpf wrote: | From GCC flto documentation :
| Quote: | -flto[=n]
If you specify the optional n, the optimization and code generation done at link time is executed in parallel using n parallel jobs by utilizing an installed make program.
[…]
Use -flto=auto to use GNU make’s job server, if available, or otherwise fall back to autodetection of the number of CPU threads present in your system. |
Afaik, there's no thinlto in gcc, it's specific to clang.
If you want to get better lto performance when using gcc, try to install and setup the mold linker. |
ok, thanks!
_________________
~amd64 & openrc --cpu 7700 --ram 2x32GB --gpu RX 6600 |
|
| Back to top |
|
|
Perfect Gentleman
Veteran
Joined: 18 May 2014
Posts: 1259
|
| Posted: Mon Aug 19, 2024 12:15 am Post subject: |
|
|
| afaik, mold doesn't support LTO itself, it translates LTO to bfd/lld. So there is no any speed improvement with mold when using LTO. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 2376
|
| Posted: Mon Aug 19, 2024 12:45 am Post subject: |
|
|
mold has plugin support and can handle gcc LTO by itself. Curiously, the maintainer of mold is the same person who rejected such plugin support for lld a few years ago.
You can easily verify this by running:
| Code: |
echo 'int main() { __builtin_printf("hello\n"); }' | gcc -x c - -flto -fuse-ld=mold -Wl,-v -Wl,--trace
|
|
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 2376
|
| Posted: Mon Aug 19, 2024 12:51 am Post subject: |
|
|
| Hu wrote: | | gcc supports -ffat-lto-objects and -fno-fat-lto-objects, where the latter would seem to be the "thin" variant. Per info gcc, no-fat is default on targets with linker plugin support. |
Yes, this matches my understanding.
Now, one question is whether GCC could implement the same style of partitioning as Clang to speed things up, but there are trade-offs associated with that (namely worse optimisation). There are other differences in how they implement LTO (the amount of information to stream, representing that, and so on) but it's not about thin-vs-not. GCC is also working on incremental LTO, not that it's much use for ebuilds. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 2376
|
| Posted: Mon Jun 02, 2025 8:53 pm Post subject: |
|
|
| sam_ wrote: | | Hu wrote: | | gcc supports -ffat-lto-objects and -fno-fat-lto-objects, where the latter would seem to be the "thin" variant. Per info gcc, no-fat is default on targets with linker plugin support. |
Yes, this matches my understanding.
Now, one question is whether GCC could implement the same style of partitioning as Clang to speed things up, but there are trade-offs associated with that (namely worse optimisation). There are other differences in how they implement LTO (the amount of information to stream, representing that, and so on) but it's not about thin-vs-not. GCC is also working on incremental LTO, not that it's much use for ebuilds. |
This was linked to on reddit, so let me elaborate a little bit, I suppose. The terminology is not consistent between GCC, LLVM, and Rust even!
GCC has the following modes:
- fat LTO (i.e. -flto -ffat-lto-objects, not default) where objects are both GIMPLE (IR) and object code, so at link-time, you can choose if you want to use LTO or not
- non-fat LTO (i.e. "thin LTO", -flto, default) where objects are only GIMPLE (IR)
GCC always partitions in some form but its scheme is controllable by -flto-partition=scheme.
LLVM has the following modes:
- fat LTO (i.e. -flto -ffat-lto-objects) where objects are both IR and object code, so at link-time, you can choose if you want to use LTO or not
- non-fat LTO (i.e. "non-fat, non-thin", -flto) where objects are "thin" (they don't contain object code, only IR) (I think this has no partitioning at all, but I'm not certain)
- thin LTO (i.e "LTO with better partitoning", -flto=thin) where objects are "thin" (they don't contain object code, only IR), but with partitioning of source files that makes it quicker and parallelisable
- fat thin LTO (i.e. -flto=thin -ffat-lto-objects) where objects are both IR and object code, but partitioned differently
In both GCC and LLVM, "fat" means "both IR and object code", but "thin" means something different. In LLVM, it's better to refer to "-flto" (not "-flto=thin") as "non-thin LTO" instead, not "fat". It's unfortunate that LLVM chose to use the term "thinLTO" because the term "thin" was already being used in GCC to discuss changing away from -ffat-lto-objects being the default (many years ago). In Rust, "fat" means something completely different.
Rust has the following modes:
- "thin local LTO" where LTO is only within a crate
- "fat" LTO where it's across all crates
- "thin" LTO where it's across all crates but with better partitioning
The terminology is highly overloaded and confusing.
As a final remark, GCC 15 has incremental LTO (-flto-incremental=/path/to/cache). In Clang, the equivalent is "thinLTO cache". |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
