[llvm] [LegalizeTypes] Handle non byte-sized elt types when splitting INSERT/EXTRACT_VECTOR_ELT (PR #93357)

[Björn Pettersson via llvm-commits]

bjope wrote:

> > > Is the nearest byte really what we want here? We can widen to any type we want, and on most targets, storing an `<N x i32>` is going to be a lot more efficient than storing an `<N x i24>`.
> > 
> > 
> > It is a bit hard to understand what is best for every target (unless perhaps scanning for some legal type, if such a type exists). Some reasons for not picking a larger element type would be:
> 
> Using the next legal element type would be a reasonable default. Maybe you want next legal store memory type
> 
> > * Our downstream target can store things like i24, so using getRoundIntegerType would both introduce an unneeded extend, but also wasting stack space.
> 
> As in i24 is a legal type, or truncating store i32->i24 is legal?

As in i24 being a legal type. And by saying that I realize that it would be an uncommon thing for in-tree targets as such an MVT doens't exist in-tree.

So it seems to make more sense in-tree (given by what ValueTypes.td currently looks like) to make use of getRoundIntegerType here. Or alternatively we should do something slightly more complicated by trying to find a legal type for ISD::STORE. But I don't know if there already exist some helper for that or if we would need to invent it.

I'll try to update this PR to use getRoundIntegerType instead of the getStoreSizedIntegerVectorElementType. And then we will deal with it downstream, if we want special handling for types like i24.

(Maybe getRoundIntegerType should be described as rounding up to next simple value type, rather than rounding to nearest power of two. Then we could let it round to other non-power-of-two sizes depending on what ValueTypes.td looks like. But that is ofcourse a totally different story.)

https://github.com/llvm/llvm-project/pull/93357