Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's on by default for Rust release builds, so at least the codepaths in LLVM for it are well-exercised.


I don't think that's right unless the docs are stale:

    [profile.release]
    lto = false
https://doc.rust-lang.org/cargo/reference/profiles.html#rele...


So the thing is that false means thinlto is used depending on other settings, see https://doc.rust-lang.org/cargo/reference/profiles.html#lto

> false: Performs “thin local LTO” which performs “thin” LTO on the local crate only across its codegen units.

I think this is kind of confusing but whatever. I should have been more clear.


There is no cross-crate LTO with 'lto = false', but there is cross-crate thin LTO with 'lto = "thin"'. The codepaths might still be getting hit, but individual CGUs within a crate are generally invisible to the user, which can create the impression that LTO doesn't occur. (That is, if you operate under the mental model of the crate being the basic compilation unit, then 'lto = false' means you'll never see LTO.)


Oh I hadn’t realized Rust does that. Really cool.


That must have been changed sometime in the last year then. When I enable LTO for one of my projects on a Rust compiler from 2024 the compilation time more than doubles.


I should have been more clear: thin LTO is, not full “fat” LTO, for exactly that reason.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: