[PATCH] D103881: [ValueTypes] Define MVTs for v6i32, v6f32, v7i32, v7f32

[Steven Johnson via Phabricator via llvm-commits]

srj added a comment.

Debugging into this a little further, it's unclear to me how `EVT::changeVectorElementType()` can be expected to work reliably: it assumes that if `EltVT.isSimple() == true`, then `MVT::changeVectorElementType(EltVT)` will be legal, but this is clearly not the case, since there aren't equivalent widths of MVTs for all element types. (In this case, v6i32 -> v6i16 isn't possible since v6i16 doesn't exist).

But what really puzzles me is why this never broke before, since even before this change, this wasn't a valid assumption (e.g. v3i32 -> v3i8 would have failed similarly before) -- is there logic upstream of this call that intends to guard against this somehow?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103881/new/

https://reviews.llvm.org/D103881