Proposal

Context

Today, the layout code insists that any Scalar in BackendRepr obeys the platform Primitive::align exactly:

https://github.com/rust-lang/rust/blob/b4486cacf58926f02e451d96e71e20882faf5453/compiler/rustc_ty_utils/src/layout/invariant.rs#L85-L263

That means, for example, that a simple type like

#[repr(Rust, packed)]
struct Foo(u32);

Ends up with BackendRepr::Memory (https://rust.godbolt.org/z/T6PWhvWqb) and in codegen we end up memcpying it around instead of just emitting i32 operations with align 1 for it.

LLVM's optimizations will mostly fix that up, but don't necessarily recover things like !range annotations, since as Memory it doesn't get the valid_range that a Scalar carries, so a packed char for example can end up with less information.

Note that codegen already needs to handle Scalars that aren't platform-aligned because you can put a scalar-repr thing into a packed stuct, and field projection thus sees that scalar type with a different alignment from the platform ABI. This is why PlaceValue::align exists in cg_ssa, for example. So in general backends shouldn't be actually coupling themselves to the platform alignment for scalars anyway, as that's already potentially wrong.

Change

I propose that the rule change as follows:

The scalar or scalars are all aligned to at least the smaller of:

• the enclosing type's LayoutData::align
• the size of the scalar

rather needing to be exactly the platform-specific-ABI-level Scalar::aligns.

Implications:

• Note that repr(C) disables Scalar/ScalarPair anyway, so this will only affect repr(Rust).
• The proposed rule doesn't mention the platform ABI alignment at all, as it's fundamentally irrelevant to how we choose to layout a composite type like a struct.
• For BackendRepr::Scalar, this allows (almost?) anything. You can have Scalar(I32) with align 1/2 from packed, align 4 as normal, or even align 8/16/... from align.
• For BackendRepr::ScalarPair, this puts (almost?) no restrictions on homogeneous pairs that don't have any padding anyway. For ScalarPair(I32, I32), any alignment works, giving one field offset 0 and the other field offset 4.
• For BackendRepr::ScalarPair, this does continue to force some packed wrappers to BackendRepr::Memory. Notably if you have a field with align 2 and ScalarPair(u8, u16) (which, TBH, I don't know if it's even possible today), then wrapping it into something with packed(1) will need to become Memory as staying in ScalarPair would change the field offset for the second field from 2 to just 1.

Mentors or Reviewers

The actual code changes here seem quite small -- I was able to tweak the layout code to produce BackendRepr::Scalar with alignment 1 and get seemingly-correct codegen without actually needing to update codegen itself.

I don't have any particular reviewers in mind, but wanted to make the MCP to try and ensure there were extra eyes on the idea in case there's something fundamental I'm missing that will completely fail in edge cases I didn't try yet.

cc #t-compiler > BackendRepr with `repr(packed)`

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.