Conversation
|
r? @cuviper rustbot has assigned @cuviper. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
|
||
| ModulePassManager MPM; | ||
| bool NeedThinLTOBufferPasses = EmitThinLTO; | ||
| bool NeedThinLTOBufferPasses = true; |
There was a problem hiding this comment.
This used to be true when fat LTO is not used, so I ensured all fat LTO phases do NeedThinLTOBufferPasses = false below.
| MPM.addPass(BitcodeWriterPass(ThinLTODataOS)); | ||
| } | ||
| MPM.addPass(ThinLTOBitcodeWriterPass( | ||
| ThinLTODataOS, EmitThinLTOSummary ? &ThinLinkDataOS : nullptr)); |
There was a problem hiding this comment.
PreLinkNoLTO is never used when fat LTO is enabled.
| if (EmitThinLTO) { | ||
| // thin lto summaries prevent fat lto, so do not emit them if fat | ||
| // lto is requested. See PR #136840 for background information. | ||
| if (OptStage != LLVMRustOptStage::PreLinkFatLTO) { |
There was a problem hiding this comment.
This doesn't need to check LLVMRustOptStage::FatLTO as ThinLTOBufferRef is NULL in that case.
There was a problem hiding this comment.
Then, how is this block "For ... LTO" at all?
(per the existing comment, assuming unqualified means full)
There was a problem hiding this comment.
LTO runs this function twice. Once on each individual module (PreLinkFatLTO or PreLinkThinLTO). In this case ThinBufferRef is a valid pointer to write the bitcode to after optimizing. And a second time after doing module linking (FatLTO) or cross-module function importing (ThinLTO). In this case ThinBufferRef is NULL as we will emit object file(s) rather thaj bitcode.
There was a problem hiding this comment.
I see, then perhaps the "For" comment can mention that this is only expected in the prelink phase.
df6f555 to
3a1c7d4
Compare
This comment has been minimized.
This comment has been minimized.
3a1c7d4 to
e93ee27
Compare
This comment has been minimized.
This comment has been minimized.
7bb4fe1 to
6dab8fa
Compare
This comment has been minimized.
This comment has been minimized.
|
LGTM @bors r+ |
…uviper Remove -Zemit-thin-lto flag As far as I can tell it was introduced in rust-lang#98162 to allow fat LTO with `-Clinker-plugin-lto`. In rust-lang#136840 a change was made to automatically disable ThinLTO summary generation when `-Clinker-plugin-lto -Clto=fat` is used, so we can safely remove it. Fixes rust-lang#152490
Rollup of 8 pull requests Successful merges: - #152057 (bootstrap: respect POSIX jobserver) - #152527 (Remove -Zemit-thin-lto flag) - #152818 (DOC: do not link to "nightly" in Iterator::by_ref() docstring) - #152840 (Add bootstrap snapshot tests for {`install`, `install src`}) - #152846 (Clarify some variable names in the query proc-macro) - #152858 (Fix typo in doc for core::mem::type_info::Struct) - #152861 (resolve: do not suggest `_` for unresolved imports) - #152873 (std::ops::ControlFlow - use "a" before `Result`)
|
@bors r- Failed in #152886 (comment) |
|
@bors try jobs=aarch64-gnu-debug |
This comment has been minimized.
This comment has been minimized.
Remove -Zemit-thin-lto flag try-job: aarch64-gnu-debug
As far as I can tell it was introduced to allow fat LTO with -Clinker-plugin-lto. Later a change was made to automatically disable ThinLTO summary generation when -Clinker-plugin-lto -Clto=fat is used, so we can safely remove it.
953103a to
c51cd0e
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
@bors r=cuviper Only change since review is an adjusted test. |
As far as I can tell it was introduced in #98162 to allow fat LTO with
-Clinker-plugin-lto. In #136840 a change was made to automatically disable ThinLTO summary generation when-Clinker-plugin-lto -Clto=fatis used, so we can safely remove it.Fixes #152490