[perf] cache type info for ParamEnv by lukas-code · Pull Request #123058 · rust-...
source link: https://github.com/rust-lang/rust/pull/123058
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
[perf] cache type info for ParamEnv #123058
Conversation
Contributor
This is an attempt to mitigate some of the perf regressions in #122553 (comment), but seems worth to test and land separately, since it is mostly unrelated to that PR.
added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
labels
compiler/rustc_middle/src/ty/list.rs
Outdated
Comment on lines
191 to 214
let data_ptr = ptr::addr_of!(self.skel.data).cast::<T>(); |
||
// SAFETY: `data_ptr` has the same provenance as `self` and can therefore |
||
// access the `self.len` elements stored at `self.data`. |
||
// Note that we specifically don't reborrow `&self.skel.data`, because that |
||
// would give us a pointer with provenance over 0 bytes. |
||
unsafe { slice::from_raw_parts(data_ptr, self.skel.len) } |
Contributor
Author
This was UB before.
Member
This comment has been minimized.
added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label
Contributor
|
💥 Test timed out |
Contributor
Author
|
uuh idk what bors is on about, the artifact looks like it got built? Let's try this: ☀️ Try build successful - checks-actions |
This comment has been minimized.
Contributor
Author
|
well that worked i guess? |
Collaborator
|
Finished benchmarking commit (be2a772): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDBenchmarking 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 may lead 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 Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)Results CyclesResults Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 672.58s -> 671.55s (-0.15%) |
Contributor
Author
|
The regression in  The regressions in r? @lcnr or compiler |
Contributor
|
☔ The latest upstream changes (presumably #123098) made this pull request unmergeable. Please resolve the merge conflicts. |
Contributor
|
☔ The latest upstream changes (presumably #123327) made this pull request unmergeable. Please resolve the merge conflicts. |
compiler/rustc_middle/src/ty/list.rs
Outdated
#[repr(C)] |
||
pub struct ListWithCachedTypeInfo<T> { |
||
skel: ListWithCachedTypeInfoSkeleton<T>, |
||
opaque: OpaqueListContents, |
Contributor
why is that moved out of ListSkeleton?
Contributor
Author
Because accessing a field with an extern type tail will always panic, because we don't know the align of the extern type and therefore the padding before the field. So basically if we just put List as the tail of ListWithCachedTypeInfo, then any attempt to access the list will panic.
Contributor
that does not seem right to me 🤔 it should be totally fine to access an unsized field which contains an extern type as long as you never try to do a place-to-value conversion. I don't think we should ever copy ListSkeleton to the stack. Which use of ListSkeleton causes issues if you keep the current setup of having OpaqueListContents as a field of it?
Contributor
Author
Hmmm apparently there is a special case if the field with an extern type tail is the only field. Which i guess makes sense since there can't be any padding in that case. If you change the outer type to have some extra data, your example will panic: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=92bafecde22b9fd72a3ddb9d9018bc68
I don't think we should ever copy
ListSkeletonto the stack
I agree. If my code does that it's not intended.
r=me after explaining the changes in ty/list.rs to me 🤔
🤔 the panic with extern types is annoying, but I understand the issue now.
Looking at this again, we now duplicate the unsafe code for List which is somewhat intricate and I am a bit worried that it ends up getting out of sync. Could we instead have a single type:
struct RawList<H, T> {
header: H,
length: usize,
data: [T; 0],
opaque: OpaqueListConten,
}This should avoid both the "extern type alignment" issue and aloows us to remove the code duplication.
Sorry for not thinking of that during the first review round 😅
Contributor
|
@bors r+ rollup=never |
added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
labels
Contributor
|
☀️ Test successful - checks-actions |
Collaborator
|
Finished benchmarking commit (087ae97): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)Results CyclesResults Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 669.732s -> 668.846s (-0.13%) |
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Successfully merging this pull request may close these issues.
None yet
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK