-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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.
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
Mark drop calls in landing pads cold
instead of noinline
#92419
Conversation
Now that deferred inlining has been disabled in LLVM, this shouldn't cause catastrophic size blowup.
Some changes occured to rustc_codegen_gcc cc @antoyo |
|
||
// In LLVM versions with deferred inlining (currently, system LLVM < 14), | ||
// inlining drop glue can lead to exponential size blowup, see #41696 and #92110. | ||
if !llvm_util::is_rust_llvm() && llvm_util::get_version() < (14, 0, 0) { |
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.
Checking for non-system llvm feels a bit hacky, not sure if I should just wait for the LLVM 14 release.
(this code is also assuming that https://reviews.llvm.org/D115497 won't be reverted upstream before then)
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.
This seems sufficiently reasonable thing to do to me if this does in fact yield any significant benefits. I wouldn't want to land changes that potentially significantly affect performance at some time in the future as it would make those other changes non-representative on their own merits.
This comment has been minimized.
This comment has been minimized.
800dc6f
to
e4463b2
Compare
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 64da730 with merge 40a35d7d35511ad25b80d1201e4c95c862e1a59b... |
☀️ Try build successful - checks-actions |
Queued 40a35d7d35511ad25b80d1201e4c95c862e1a59b with parent e670844, future comparison URL. |
Finished benchmarking commit (40a35d7d35511ad25b80d1201e4c95c862e1a59b): comparison url. Summary: This change led to very large relevant mixed results 🤷 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never |
Looks like where there are benefits they are both in the LLVM spending less time optimizing the IR (i.e. the IR is simpler) as well as rustc itself running faster (e.g. spending less time in typeck when checking keccak crate). Naturally the first class of changes have mean some regressions such as the beforementioned ripgrep. The overall shape is very positive though. @bors r+ |
📌 Commit 64da730 has been approved by |
⌛ Testing commit 64da730 with merge f13cfdc16b312612a0b9ac8a8cf79a9119778ed2... |
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
Mark drop calls in landing pads `cold` instead of `noinline` Now that deferred inlining has been disabled in LLVM (rust-lang#92110), this shouldn't cause catastrophic size blowup. I confirmed that the test cases from rust-lang#41696 (comment) still compile quickly (<1s) after this change. ~Although note that I wasn't able to reproduce the original issue using a recent rustc/llvm with deferred inlining enabled, so those tests may no longer be representative. I was also unable to create a modified test case that reproduced the original issue.~ (edit: I reproduced it on CI by accident--the first commit timed out on the LLVM 12 builder, because I forgot to make it conditional on LLVM version) r? `@nagisa` cc `@arielb1` (this effectively reverts rust-lang#42771 "mark calls in the unwind path as !noinline") cc `@RalfJung` (fixes rust-lang#46515) edit: also fixes rust-lang#87055
Revert "Auto merge of rust-lang#92419 - erikdesjardins:coldland, r=nagisa" Should fix (untested) rust-lang#94390 Reopens rust-lang#46515, rust-lang#87055 r? `@ehuss`
…=nikic Rebased: Mark drop calls in landing pads cold instead of noinline I noticed that certain inlining optimizations were missing while staring at some compiled code output. I'd like to see this relanded, so I rebased the PR from ``@erikdesjardins`` (PR rust-lang#94823). This PR reapplies rust-lang#92419, which was reverted in rust-lang#94402 due to rust-lang#94390. Fixes rust-lang#46515, fixes rust-lang#87055. Update: fixes rust-lang#97217.
…ikic Rebased: Mark drop calls in landing pads cold instead of noinline I noticed that certain inlining optimizations were missing while staring at some compiled code output. I'd like to see this relanded, so I rebased the PR from `@erikdesjardins` (PR rust-lang#94823). This PR reapplies rust-lang#92419, which was reverted in rust-lang#94402 due to rust-lang#94390. Fixes rust-lang#46515, fixes rust-lang#87055. Update: fixes rust-lang#97217.
…ikic Rebased: Mark drop calls in landing pads cold instead of noinline I noticed that certain inlining optimizations were missing while staring at some compiled code output. I'd like to see this relanded, so I rebased the PR from `@erikdesjardins` (PR rust-lang#94823). This PR reapplies rust-lang#92419, which was reverted in rust-lang#94402 due to rust-lang#94390. Fixes rust-lang#46515, fixes rust-lang#87055. Update: fixes rust-lang#97217.
Rebased: Mark drop calls in landing pads cold instead of noinline I noticed that certain inlining optimizations were missing while staring at some compiled code output. I'd like to see this relanded, so I rebased the PR from `@erikdesjardins` (PR #94823). This PR reapplies rust-lang/rust#92419, which was reverted in rust-lang/rust#94402 due to rust-lang/rust#94390. Fixes rust-lang/rust#46515, fixes rust-lang/rust#87055. Update: fixes #97217.
Now that deferred inlining has been disabled in LLVM (#92110), this shouldn't cause catastrophic size blowup.
I confirmed that the test cases from #41696 (comment) still compile quickly (<1s) after this change.
Although note that I wasn't able to reproduce the original issue using a recent rustc/llvm with deferred inlining enabled, so those tests may no longer be representative. I was also unable to create a modified test case that reproduced the original issue.(edit: I reproduced it on CI by accident--the first commit timed out on the LLVM 12 builder, because I forgot to make it conditional on LLVM version)r? @nagisa
cc @arielb1 (this effectively reverts #42771 "mark calls in the unwind path as !noinline")
cc @RalfJung (fixes #46515)
edit: also fixes #87055