-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Some LTO fixes. #8349
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Some LTO fixes. #8349
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
.build() | ||
} | ||
|
||
fn verify_lto(output: &Output, krate: &str, krate_info: &str, expected_lto: Lto) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this is really necessary, it's a lot of code to do very little. The main thing is that I want to detect builds that don't pass any flags (Lto::ObjectAndBitcode
), which is difficult to do with the current infrastructure. I could instead use with_stderr_line_without
, or just not bother asserting that condition.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nah I think this is fine, it's just tests anyway so I don't think there's much need to be super strict about style and such.
@bors: r+ All looks great to me, thanks for all the comments! |
📌 Commit 62a61dd has been approved by |
☀️ Test successful - checks-azure |
Update cargo 2 commits in 1ec223effbbbf9fddd3453cdcae3a96a967608eb..79c769c3d7b4c2cf6a93781575b7f592ef974255 2020-06-09 20:03:14 +0000 to 2020-06-11 22:13:37 +0000 - Fix failure with missing readme. (rust-lang/cargo#8353) - Some LTO fixes. (rust-lang/cargo#8349)
This reworks the LTO computation a little to address a few issues:
cargo build
in a project with both a lib and bin would not engage the optimization introduced in Don't force rustc to do codegen for LTO builds #8192 where the lib should be compiled with-C linker-plugin-lto
(bitcode only). This happened because the old code was starting root units asLto::None
. The solution here is to conditionally choose the starting Lto for roots.-C linker-plugin-lto
which is not valid.lto::between_builds
, where the second build the lib is now fresh.lib
target will now support LTO.I scattered some comments throughout, hopefully it's not too difficult to follow.
Closes #8337