determine when we can use preferred alignment instead of ABI alignment

[andrewrk]

Currently, when we specify the alignment for a load or a store, we look at the pointer type to determine the alignment. This means that even if there is a discrepancy between the preferred alignment and the ABI alignment, we have to use the ABI alignment, because we don't know whether a given &u32 is referring to a uint32_t * in C, and we need the alignments to agree.

Essentially, pointers have a hidden "alignment" field which is determined when you take the address of something, but we don't want it to be possible to have pointers which differ only in alignment, so we have to do the lowest common denominator sort of thing.

For types that only exist in Zig-land, such as %T or an enum with payloads, we should be able to use preferred alignment. However, if you get a pointer to a struct field which is one of these types, it will be laid out according to LLVM's Data Layout setup, which appears to use ABI alignment for fields.

So this limits everything back to ABI alignment. I think this is not important - in practice it seems that ABI alignment is nearly always equal to preferred alignment. But zig is about being optimal, dammit.

Question sent to LLVM-dev mailing list: http://lists.llvm.org/pipermail/llvm-dev/2017-August/116897.html

This plays into a limitation of LLVM which is that the optimizer does not have a way to detect and remove unused fields from structs, which would then make room to re-arrange the remaining fields for better alignment. And we would want to remove fields from structs after other advanced optimizations that LLVM offers, since they might cause a field to become unused. See #168

An advanced analysis could deal with pointers with hidden "alignment" fields and without making trouble for the programmer, choose the best alignment possible while always making sure that pointers agree with each other, because everywhere that we specify for something to have preferred alignment, we could have specified for it to have ABI alignment. This is a similar problem as #105.

For now I'm going to revert back to only having @alignOf which is ABI alignment, and we'll just not expose this detail to the programmer.

[andrewrk]

We can use max(preferred, abi) for everything, and then the new aligned pointer proposal (see #37) gives us the solution to this problem.