Skip to content

Reorder lto options in profiles.md #15841

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Aug 17, 2025
Merged

Reorder lto options in profiles.md #15841

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0b34dd3
Reorder `lto` options in profiles.md
smoelius Aug 15, 2025
396f8c6
Mention ordering rationale in profiles.md
smoelius Aug 17, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions src/doc/src/reference/profiles.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -166,16 +166,16 @@ The `lto` setting controls `rustc`'s [`-C lto`], [`-C linker-plugin-lto`], and
LTO can produce better optimized code, using whole-program analysis, at the cost
of longer linking time.

The valid options are:
The valid options from most to least optimizing are:
Copy link
Member

@bjorn3 bjorn3 Aug 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I understand it, this is not true in the general case. fat LTO can produce faster executables than ThinLTO and even if it doesn't, it is often very close. ThinLTO just generally produces a bit bigger executables.

Copy link
Member

@weihanglo weihanglo Aug 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So in terms of executable performance,

is it fat >= ThinLTO or ThinLTO >= fat, or hard to say?

Copy link
Member

@bjorn3 bjorn3 Aug 17, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I understand it, it could be either way nowadays. There is probably still some bias for fat LTO producing faster executables than ThinLTO though.

Copy link
Member

@weihanglo weihanglo Aug 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Thanks for pointing it out!

There is another similar ongoing in rust-lang/rust rust-lang/rust#145533. Do you think we should r- that, and revert this PR as well?

Copy link
Member

@bjorn3 bjorn3 Aug 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the order makes sense. I just think we should not explicitly say "from most to least optimizing" here.


* `false`: Performs "thin local LTO" which performs "thin" LTO on the local
crate only across its [codegen units](#codegen-units). No LTO is performed
if codegen units is 1 or [opt-level](#opt-level) is 0.
* `true` or `"fat"`: Performs "fat" LTO which attempts to perform
optimizations across all crates within the dependency graph.
* `"thin"`: Performs ["thin" LTO]. This is similar to "fat", but takes
substantially less time to run while still achieving performance gains
similar to "fat".
* `false`: Performs "thin local LTO" which performs "thin" LTO on the local
crate only across its [codegen units](#codegen-units). No LTO is performed
if codegen units is 1 or [opt-level](#opt-level) is 0.
* `"off"`: Disables LTO.

See the [linker-plugin-lto chapter] if you are interested in cross-language LTO.
Expand Down
Loading