-
-
Notifications
You must be signed in to change notification settings - Fork 17.4k
Missed enum layout optimization depending on enum variant field reordering #125630
Copy link
Copy link
Closed
Closed
Copy link
Labels
A-layoutArea: Memory layout of typesArea: Memory layout of typesC-optimizationCategory: An issue highlighting optimization opportunities or PRs implementing suchCategory: An issue highlighting optimization opportunities or PRs implementing suchT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
Activity
Metadata
Metadata
Assignees
Labels
A-layoutArea: Memory layout of typesArea: Memory layout of typesC-optimizationCategory: An issue highlighting optimization opportunities or PRs implementing suchCategory: An issue highlighting optimization opportunities or PRs implementing suchT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
rustc fails to optimize the enum Layout of
V1andV2of the (real world) example typeLazyRwLockGuardto 24 bytes.In case of
V1, this might be be due to #101567.But the case of
V2seems to be a separate issue, as it is identical toV3(which is optimized correctly), except for the ordering of the fields inside theReadenum variant.(For clarity,
RwLockReadGuardandRwLockWriteGuardeach use 16 bytes and contain a niche).godbolt repro
stackoverflow question