-
Notifications
You must be signed in to change notification settings - Fork 13k
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
#94107
Conversation
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit ed18309adaeeeab3a85a45b74d2627bfefbb719d with merge f12f59345fd5621cd34aea2915fff165082cd5d0... |
☀️ Try build successful - checks-actions |
Queued f12f59345fd5621cd34aea2915fff165082cd5d0 with parent 30b3f35, future comparison URL. |
Thanks for bringing this back! For posterity, previous attempts: #76030, #88449 This should now be viable to merge because the LLVM issue discovered during the last attempt (#88449 (comment)) was fixed in LLVM 14 (#93577). |
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.
Thanks for reviving this. You don't need to, but I'd appreciate it if you added myself and @erikdesjardins as co-authors to the commit.
Finished benchmarking commit (f12f59345fd5621cd34aea2915fff165082cd5d0): comparison url. Summary: This benchmark run shows 63 relevant improvements 🎉 but 14 relevant regressions 😿 to instruction counts.
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 |
I rerun my tests and the problem appears indeed to have been fixed:
Against f12f59345fd5621cd34aea2915fff165082cd5d0
Since the problem has been fixed by LLVM 14 should this change be gated by the LLVM version or postponed until LLVM 14 becomes the oldest supported version? Otherwise people compiling rustc manually with LLVM version < 14 will hit the performance regression right? |
I would rather avoid including this in next beta, and if I am reading Rust forge correctly, the next promotion is on Monday, so I am marking this as blocked at least until then. |
☔ The latest upstream changes (presumably #94062) made this pull request unmergeable. Please resolve the merge conflicts. |
r=me when you're ready to land this |
Co-authored-by: Erik Desjardins <[email protected]> Co-authored-by: Tomasz Miąsko <[email protected]>
@bors r=davidtwco |
📌 Commit 4e41a46 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (e780264): comparison url. Summary: This benchmark run shows 59 relevant improvements 🎉 to instruction counts.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
cg_llvm: stop identifying ADTs in LLVM IR This is an extension of rust-lang#94107. It may be a minor perf win. Fixes rust-lang#96242. Now that we use opaque pointers, ADTs can no longer be recursive, so we do not need to name them. Previously, this would be necessary if you had a struct like ```rs struct Foo(Box<Foo>, u64, u64); ``` which would be represented with something like ```ll %Foo = type { %Foo*, i64, i64 } ``` which is now just ```ll { ptr, i64, i64 } ``` r? `@tmiasko`
cg_llvm: stop identifying ADTs in LLVM IR This is an extension of rust-lang/rust#94107. It may be a minor perf win. Fixes #96242. Now that we use opaque pointers, ADTs can no longer be recursive, so we do not need to name them. Previously, this would be necessary if you had a struct like ```rs struct Foo(Box<Foo>, u64, u64); ``` which would be represented with something like ```ll %Foo = type { %Foo*, i64, i64 } ``` which is now just ```ll { ptr, i64, i64 } ``` r? `@tmiasko`
r? @davidtwco @erikdesjardins