[llvm] Scalarizer : Fix vector shuffle issue when can't aligned to customized minBits. (PR #163912)

[via llvm-commits]

ShchchowAMD wrote:

> Can you give more context as for what this is trying to achieve? The LLVM IR that the pass produces for your test looks pretty reasonable to me, except as noted in the comment.
> 
> Naively, I'd think that a long sequence of extractelement/insertelement seems inherently worse than a pair of shufflevectors.

Hi, sorry I didn't make it clear and make a wrong test,
In conclusion, when **last split boolen vector's fragment has a size <= minBits/2**, it will report invalid operand of above shufflevector(Fragment, Fragment) call.

**Details found through debugging:**

As an example, in new test file, when
**minbits=8, and vector size is 11,**
it will be two fragments after split:
vector1 is **<8 x i1>** and vector2 is **<3 x i1>**.
And in this case, **extendMask** is [0, 1, 2, 3, 4, 5, 6, 7, -1, -1, -1].

When processing last fragment in concratenate call as shufflevector(Fragment, Fragment, extendMask),
extendMask doesn't change and it will trigger invalid shuffle operands assertion for shuffle(Fragment, Fragment, extendMask) because:
extendMask[6] >= v1Size * 2, which is equal to : 6 >= 3 * 2.

So, this issue should be reproduced when last fragment size <= (numPacked / 2).
That's my mistake to set wrong parameter in first version of test.

I agree that add those insert/extract call here is ugly as I'm not sure which is the best way to solve this issue.

NumPacked seems come from minBits.

And if only resize extendMask, in final shuffle at the end of concatenate, it will also trigger invalid operand when shuffle (Res, Fragment), because Res has 11 elements, and last Fragment only has 3 in this test as an example.

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