I'm not sure why the FIXME was there, since the ABI size of the vector
shouldn't matter for the element offset.
Fixes bug 42304.
Aren't vectors (of non-bytesized elements) packed when stored to memory?
I know that there is code that assumes a packed layout, but also code that does not assume a packed layout. So I don't think that LLVM is consistent.
Most of the time my impression is that vector elements with irregular sizes isn't handled well (when it comes to loads/stores/bitcast) and vectorizers try to avoid creating such vectors (in combination with load/store/bitcast). Without having looked at the details here, I figure that the extractelement is lowered into doing the extract by first storing the vector to memory and then doing a read using the dynamic index. So basically extract/insert element with a dynamic index results in store of the vector, so such operations does not work well for irregular types either.
Any vector with elements < 8-bits that touches memory is broken. I don't think there's a consistent interpretation between targets, although I think there's a general desire to move towards treating them as packed
So the removed assert, that kind of said that this piece of code only works correctly for byte-sized elements, should probably still be there (asserting that "EltVT.getSizeInBits() == EltVT.getStoreSizeInBits()" ).