Const eval does alignment checks

[oli-obk]

The const eval engine takes quite a few steps to ensure that it bails out of evaluation if any steps would cause unaligned reads. E.g.

#[repr(packed)]
struct Foo {
    a: i32,
}

static A: Foo = Foo { a: 42 };
static B: i32 = {
    let x: &i32 = unsafe { &A.a };
    *x
};

will fail to compile with

error[E0080]: could not evaluate static initializer
 --> src/main.rs:9:5
  |
9 |     *x
  |     ^^ tried to access memory with alignment 1, but alignment 4 is required

The question is, do we need to be this restrictive during const eval. The checks are everywhere, so we may even see perf gains from removing them, but the main gain would be that we can remove the additional code that just exists to ensure we fiddle the right alignment through the pattern-matching-on-constants logic (ConstValue::ByRef's Align field is unused for anything else).

I think there's little use in keeping this restriction in const eval, since it only exists in miri because some hardware platforms actually do UB on unaligned reads, while other platforms are simply slower on unaligned reads.

cc @RalfJung

[RalfJung]

it only exists in miri because some hardware platforms actually do UB on unaligned reads, while other platforms are simply slower on unaligned reads.

That is not correct. It exists in Miri because it is UB in MIR to do unaligned accesses, and we optimize and generate LLVM IR under that assumption. It is wrong and can cause incorrect codegen to do unaligned accesses even on platforms like x86 where they do not trap.

But CTFE does not have to go out of its way to detect UB, IMO.