perf(codegen): Eliminate size_of_val == 0 for DSTs with Non-zero-sized Prefix via NUW and Assume

[TKanX]

Summary:

Problem:

size_of_val(p) == 0 fails to optimize away for DST types that have a statically-known non-zero-sized prefix:

pub struct Foo<T: ?Sized>(pub [u32; 3], pub T);

pub fn demo(p: &Foo<dyn std::fmt::Debug>) -> bool {
    std::mem::size_of_val(p) == 0  // always false, but LLVM can't prove it
}

Foo has a 12-byte prefix, so its total size is always ≥ 12. Yet the comparison persists as a runtime computation in LLVM IR. This matters because Box<dyn T> drop emits this exact check to guard the deallocation call — for types with a guaranteed non-zero prefix, the branch should vanish but doesn't.

The slice tail variant Foo<[i32]> already optimized correctly; Foo<dyn Trait> and Foo<[u8]> did not.

Root Cause:

In size_and_align_of_dst (the ADT/Tuple branch), the size computation is:

full_size = (offset + unsized_size + (align-1)) & -align

LLVM cannot prove full_size > 0 because:

1. offset + unsized_size used plain add — no NUW flag, so LLVM cannot conclude the result is ≥ offset.
2. (x + addend) & -align — LLVM has no information that alignment rounding never reduces the value below x.

Additionally, the vtable alignment range metadata was [1, u64::MAX] (only non-zero), despite the actual bound being [1, 1 << (ptr_width - 1)] (all alignments are powers of two with a tighter upper bound).

Solution:

Three minimal additions, each grounded in a precise invariant:

1. add nuw on offset + unsized_size — sound because both operands are ≤ isize::MAX for any valid Rust object, so unsigned overflow is impossible. Tells LLVM: unrounded_size ≥ offset.

2. assume(full_size ≥ unrounded_size) — round_up(x, a) ≥ x is a mathematical identity for power-of-two a. Tells LLVM: full_size ≥ unrounded_size ≥ offset. If offset > 0, the chain proves full_size > 0.

3. Tighten vtable alignment range from [1, u64::MAX] to [1, 1 << (ptr_width - 1)] — consistent with Rust's alignment constraints. Applied in both size_of_val.rs and the vtable_align intrinsic in mir/intrinsic.rs.

LLVM IR Comparison:

Foo<dyn Debug> — before (godbolt):

define noundef zeroext i1 @demo(ptr %p.0, ptr %p.1) {
start:
  %0 = getelementptr inbounds nuw i8, ptr %p.1, i64 8
  %1 = load i64, ptr %0, align 8, !range !3, !invariant.load !4
  %2 = getelementptr inbounds nuw i8, ptr %p.1, i64 16
  %3 = load i64, ptr %2, align 8, !range !5, !invariant.load !4
  %4 = tail call i64 @llvm.umax.i64(i64 %3, i64 4)
  %5 = add nuw i64 %1, 11
  %6 = add i64 %5, %4
  %7 = sub i64 0, %4
  %8 = and i64 %6, %7
  %_0 = icmp eq i64 %8, 0
  ret i1 %_0
}

Foo<dyn Debug> — after:

define noundef zeroext i1 @demo(ptr %p.0, ptr %p.1) {
start:
  ret i1 false
}

Foo<[u8]> — before:

define noundef zeroext i1 @demo_lessalignedslice(ptr %p.0, i64 %p.1) {
start:
  %0 = add i64 %p.1, 15
  %_0 = icmp ult i64 %0, 4
  ret i1 %_0
}

Foo<[u8]> — after:

define noundef zeroext i1 @demo_lessalignedslice(ptr %p.0, i64 %p.1) {
start:
  ret i1 false
}

Changes:

• compiler/rustc_codegen_ssa/src/size_of_val.rs: add → unchecked_uadd (NUW) on offset + unsized_size; add assume(full_size ≥ unrounded_size); tighten vtable alignment range.
• compiler/rustc_codegen_ssa/src/mir/intrinsic.rs: tighten alignment range on the vtable_align intrinsic, consistent with the above.
• tests/codegen-llvm/dst-vtable-align-nonzero.rs: update FileCheck metadata expectation to match the new tighter range.
• tests/codegen-llvm/dst-size-of-val-not-zst.rs: new codegen test verifying size_of_val == 0 folds to ret i1 false for Foo<dyn Debug>, Foo<[u8]>, and Foo<[i32]>.

Fixes #152788.

[TKanX]

@rustbot label +A-LLVM +A-codegen +C-optimization +T-compiler

[fmease]

r? codegen

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[TKanX]

@rustbot ready

[scottmcm]

Can you elaborate on which things you tried and why this is the best one? Was it not enough to say that the alignment is a power-of-two? Or...

[scottmcm]

I ask because most of the text in the OP is just useless LLM slop, and the updates to the tests make me suspicious.

[dianqk]

r? scottmcm