[llvm] [GISel] Add support for scalable vectors in getLCMType (PR #80306)

[Michael Maitland via llvm-commits]

michaelmaitland wrote:

> This looks odd. In your examples, you try to unmerge a scalable vector. In how many register do want to unmerge the scalable vector. From the documentation:
> 
> ```
> %bits_0_7:(s8), %bits_8_15:(s8),
>     %bits_16_23:(s8), %bits_24_31:(s8) = G_UNMERGE_VALUES %0:(s32)
> ```
> 
> We unmerge 32 bits into 4 registers of 8 bits. For scalable vectors, the number of output registers is unknown.

In the shufflevector example above, we know how many virtual registers we would like to unmerge into: One `(<vscale x 16 x s64>)` gets unmerged into two `(<vscale x 8 x s64>)`. We know this works because the minimum number of vector elements is correctly supported. In the original vector, the minimum is 16. In the two new vectors, the minimum is `8+8=16`. vscale is a compile time constant which will obviously result in the pre-unmerge vector having the same number of actual elements as the two unmerged vectors.

Now that there are two `(<vscale x 8 x s64>)` virtual registers, the same logic on how to map physical vectors onto scalable virtual registers follows the same process for any other instruction and is backend specific. This has nothing to do with G_MERGE/UNMERGE.

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