-
-
Notifications
You must be signed in to change notification settings - Fork 14.9k
Collapse trailing padding #17027
Copy link
Copy link
Closed as not planned
Labels
A-codegenArea: Code generationArea: Code generationC-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.T-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.WG-llvmWorking group: LLVM backend code generationWorking group: LLVM backend code generation
Metadata
Metadata
Assignees
Labels
A-codegenArea: Code generationArea: Code generationC-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.T-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.WG-llvmWorking group: LLVM backend code generationWorking group: LLVM backend code generation
Type
Fields
Give feedbackNo fields configured for issues without a type.
Since we don't have to worry about FFI interop for types that are not
#[repr(C)], this means we can perform certain optimizations with regards to padding. One such optimization is collapsing trailing padding. For examplestd::mem::size_of::<((u16, u8), u8)>()returns 6, but ideally it would be 4.To implement this size optimization would require keeping track of two separate sizes, one being the actual size not including trailing padding, and the other being the array element size or aligned size. For example
(u16, u8)would have an actual size of 3, but an array size of 4.As an added benefit, this would allow for enums to use that extra space at the end to store the discriminant.
This likely depends on teaching LLVM to support this sort of stuff.