Make pointer::align_offset exploit allocation alignment

[RalfJung]

Miri's implementation of align_offset currently always says "nope, can't do that". We could do better than that in case the alignment of the allocation of the argument pointer is at least the requested alignment. In that case, we can basically run the real implementation of align_offset from libcore.

Testcase by @shepmaster:

use std::mem;

#[derive(Debug, Default)]
#[repr(align(8))]
struct AlignToU64<T>(T);

const BYTE_LEN: usize = mem::size_of::<[u64; 4]>();
type Data = AlignToU64<[u8; BYTE_LEN]>;

fn example(data: &Data) {
    let (head, u64_arrays, tail) = unsafe { data.0.align_to::<[u64; 4]>() };

    assert!(head.is_empty(), "buffer was not aligned for 64-bit numbers");
    assert_eq!(u64_arrays.len(), 1, "buffer was not long enough");
    assert!(tail.is_empty(), "buffer was too long");

    let u64_array = &u64_arrays[0];
    let _val = u64_array[0]; // make sure we can actually load this
}

fn main() {
    example(&Data::default());
}

There should also be another testcase where the modulo stuff becomes more interesting (align_offset returns an offset in units of size_of::<T>(), not bytes).

[RalfJung]

One potential complication here is that this might make code run SSE where it did not before, because the aligned part is using SSE instructions. We should add test cases at least for libstd uses for align_to that, with this change, execute the inner loops -- to see if that runs anything Miri doesn't like (or catches any bugs).

[RalfJung]

Also see rust-lang/rust#62420 for a detailed discussion about the benefits of making align_offset fail even though it could succeed.

[pvdrz]

I think this was solved (at least partially) by #945

[RalfJung]

Yes this is solved; the only thing that's missing is adding the testcase to our test suite. :)