-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Reapply "cg_llvm: fewer_names
in uncached_llvm_type
"
#88449
Conversation
This reverts commit 88dc58f.
r? @nagisa (rust-highfive has picked a reviewer for you, use r? to override) |
There was a report of a performance regression in #79246 that was eventually bisected to changes from #76030. Could you verify that this is no longer an issue? It seems to me that issue was not merely incidental, but more fundamentally caused by the use of unnamed types. In terms of LLVM IR linked for LTO, one difference was quite apparent: the unnamed types, unlike named types previously, weren't being unified. EDIT: The original reproducer marmeladema/bitvec-perf-regression@684c72b still shows a regression when compiling with fat LTO. The regression is mostly a result of |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit dc905e4 with merge 71e222956789b7e8cb98a8925927a40b52ad9fe5... |
☀️ Try build successful - checks-actions |
Queued 71e222956789b7e8cb98a8925927a40b52ad9fe5 with parent 757a65b, future comparison URL. |
Finished benchmarking try commit (71e222956789b7e8cb98a8925927a40b52ad9fe5): comparison url. Summary: This change led to very large relevant improvements 🎉 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. @bors rollup=never |
@tmiasko given that the reproducer is a closed-source project, I don't see a good way for us to verify this by ourselves. Could @marmeladema try their project with this PR? |
Is there an easy way for me to try a compiled version of rustc with this PR? |
I think you can use the rustup-toolchain-install-master tool to get the complete toolchain from a bors build. You just need to invoke it like this (where
|
The components are uploaded to an S3 bucket so you could reconstruct a toolchain from these, but its going to be a manual process. The bucket with the artifacts is at https://s3-us-west-1.amazonaws.com/rust-lang-ci2. The file locations are from the build logs:
So for example https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rustc-builds/71e222956789b7e8cb98a8925927a40b52ad9fe5/rust-nightly-x86_64-unknown-linux-gnu.tar.xz should give you the same artifact as described in https://forge.rust-lang.org/infra/other-installation-methods.html#standalone-installers (or what Urgau said ^^) |
One still unfixed issue in LLVM exposed by this change https://bugs.llvm.org/show_bug.cgi?id=51667. |
Ok, so I managed to install the toolchain from that PR:
I managed to compile my reproduction code:
And running it shows this PR re-introduces the regression, and it's even worse than with version 1.48.0:
With current stable version (1.54.0), here is what you get:
I also tried with current nightly rustc 1.56.0-nightly (29ef6cf 2021-08-31):
|
@marmeladema is there any way we could obtain a self-contained reproducer for this problem? |
I cannot really minimized it more and I don't know myself what the exact problem is. |
Ah, I didn't see the edit above from @tmiasko's post. Thank you for taking the time to respond! |
@erikdesjardins With the situation as it is right now, I do not believe we should merge this still. Inlining failing to do its job has potentially far-reaching consequences, which I'm not sure we can afford for the benefits that |
Ah, I was just about to fix it: https://reviews.llvm.org/D109294 ...although I suppose it's not worth backporting, so we'll have to wait for LLVM 14 anyways |
This reapplies #76030, which was reverted by #80122.
The underlying LLVM issue (https://bugs.llvm.org/show_bug.cgi?id=48340, per #79564 (comment)) was fixed in LLVM 13 by https://reviews.llvm.org/D91250 (and related patches), so we should be able to reland the original change.
I successfully ran the repro steps from #79564 (comment) using a rustc built with this change.
We should do another perf run to make sure this still has the same effect.
cc @davidtwco