@thesamesam@social.treehouse.systems
Post #1997175
2026-05-03 00:25 UTC
Away from kernelposting finally..
I find Rust's LTO implementation curious in a few ways.
First, there's the very unfortunate term collisions with both LLVM and GCC [0].
But I find it interesting that they both somewhat advertise, and projects make use of, -C codegen-units [1], because you then don't get consistent results with LTO.
As far as I know, in LLVMland, nobody encourages you to mess with partitioning, and it seems like it'd be a better idea for Rust to work on partitioning instead so nobody would need to set it.
I see people recommend =1 quite often but needing to do that in GCC is basically unheard of (seen some very rare cases where it might have been useful), and I don't know if LLVM even has a strict equivalent.
[0] https://wiki.gentoo.org/wiki/LTO#Terminology
[1] https://doc.rust-lang.org/cargo/reference/profiles.html#codegen-units
Replies (2)
-
@lenary@types.pl 2026-05-03 01:37
@thesamesam ThinLTO in LLVM does some partitioning. Full LTO does a single Partition. Unified I think can do either.
-
@pinskia@hachyderm.io 2026-05-03 02:14
@thesamesam gcc internals uses slim rather than thin https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html I also cant remember when gcc switched from full lto to WHOPR by default but it was about the same time hjl linux binutils went away. And the bfd linker got plug-in support. That was so long ago too; maybe 15 years ago. The original whorp mode was gold only as plug-in support was gold only.