Vectors contain their elements tightly packed together without
any padding bytes. If the elements have stricter-than-natural
alignment requirements, then the elements in the vector are smaller
than in for example an array or struct.
This fact was not accounted for when computing byte-offsets of GEPs.
For example, with i16:32 alignment, the byte-offset of the following
GEP was incorrectly computed as 8 bytes, while 4 bytes is correct:
getelementptr <3 x i16>, <3 x i16> *%ptr, i32 0, i32 2
To fix, instead of unconditionally using the elements' AllocSize,
use a new helper getElementSize(..) that returns the inner type's
size if the outer type is a vector, otherwise its AllocSize.
Add a unit test.
Also add an assertion to SROA:
SROA tries to generate "natural" GEPs for a given byte offset if possible,
instead of bitcasting to i8* and applying the offset there.
Add an assertion that such a generated natural GEP results in the correct
byte offset. This assertion would have failed prior to the GEP fix.
Update the LangRef to be more explicit on the layout of vectors of
overaligned elements.
The lit test is new. I'll precommit it if this patch is accepted.
This entire function is unused if opaque pointers are used, so I don't think it makes much sense to add this assertion.