For big endian targets that need a node such as this:
v2i8 = bitcast i16:tN
legalized by:
- Promoting the i16 input type
- Widening the v2i32 result type
The result will be incorrect because the legalizer will promote the input type and then produce a scalar_to_vector from that wider type to a vector of N elements of that type. That puts the desired bits into the low order bytes of element zero and they need to be in the high order bytes on big endian systems.
I'd prefer EVT OrigInVT = N->getOperand(0).getValueType();, or something like that.
Can we avoid explicitly forking on endianness here? We should be able to use the same vector type for little-endian, I think. Keeping the DAG as close as possible should make it easier to generate optimal code for targets that have both little-endian and big-endian variants.
I'm a little concerned we could end up producing a weird vector type here; the result of promotion is always going to be a nice type, but the original type could be something less nice. I guess we end up using the CreateStackStoreLoad codepath if we end up choosing an illegal vector type, so maybe we can ignore that for now.