Cleanup: Share DST size/align computation logic between codegen backends (and interpreter)

[RalfJung]

Currently, each codegen backend and the MIR interpreter needs to re-implement this logic:

rust/compiler/rustc_codegen_ssa/src/glue.rs

Line 11 in 50f6a9e

pub fn size_and_align_of_dst<'a, 'tcx, Bx: BuilderMethods<'a, 'tcx>>(

rust/compiler/rustc_codegen_cranelift/src/unsize.rs

Line 190 in e54a13f

pub(crate) fn size_and_align_of_dst<'tcx>(

rust/compiler/rustc_const_eval/src/interpret/eval_context.rs

Line 570 in fd59d44

pub(super) fn size_and_align_of(

Turns out the interpreter version actually has a bug. Ideally we'd only have this logic once so that we don't need the same subtle logic in multiple places.

Cc @bjorn3 @eddyb

[eddyb]

I think the problem is that this is one of those hypothetical "MIR->LIR reusable lowering steps" that IIRC I discussed with @oli-obk before (just like e.g. the codegen for the MIR casts that involve CoerceUnsize and bottom out in "*T/&T built-in unsizing"), that require monomorphic types to fully resolve and we just don't have such a "LIR" concept yet (the closest thing being the builder API of rustc_codegen_ssa).

Maybe if it can be expressed as a post-monomorphization MIR->MIR "simplification" we can ignore the lack of a "LIR"? It would have to be at the level of e.g. statements, and on the fly (like monomorphization itself), not a whole-body pass, if we want to avoid large amounts of wasteful allocations (tho I may be wrong about how much that matters, heh).

[RalfJung]

Alternatively we could do something specific, like a generic function for the logic that invokes callback to do the arithmetic on whatever domain the backend needs (values for Miri, LLVM/cranelift expressions for codegen).

[oli-obk]

It would have to be at the level of e.g. statements, and on the fly (like monomorphization itself), not a whole-body pass, if we want to avoid large amounts of wasteful allocations (tho I may be wrong about how much that matters, heh).

We should probably just try out monomorphizing and optimizing all MIR bodies before codegen processes it and see how bad it is. So far we've only said "probably bad" and never actually collected any numbers