[CIR] shufflevector and convertvector built-ins

[dkolsen-pgi]

Implement __builtin_shufflevector and __builtin_convertvector in ClangIR. This change contributes to the implemention of issue #284.

__builtin_convertvector is implemented as a cast. LLVM IR uses the same instructions for arithmetic conversions of both individual scalars and entire vectors. So ClangIR does the same. The code for handling conversions, in both CodeGen and Lowering, is cleaned up to correctly handle vector types. To simplify the lowering code and avoid if (type.isa<VectorType>()) statements everywhere, the utility function elementTypeIfVector was added to LowerToLLVM.cpp.

__builtin_shufflevector has two forms, only one of which appears to be documented.

The documented form, which takes a variable-sized list of integer constants for the indices, is implemented with the new ClangIR operation cir.vec.shuffle.ints. This operation is lowered to the llvm.shufflevector op.

The undocumented form, which gets the indices from a vector operand, is implemented with the new ClangIR operation cir.vec.shuffle.vec. LLVM IR does not have an instruction for this, so it gets lowered to a long series of llvm.extractelement and llvm.insertelement operations.

[bcardosolopes]

Thanks for adding shuffle support David.

Feels like the fundamental difference in these shuffles is static indicies vs dynamic ones, with the caveat that the dynamic one operates on a single vector source. My concern with adding two CIR operations for shuffles is passes having to know about more than one. However, unifying both in one doesn't also feel great (e.g. it would require making second vector optional and tricks to differentiate attribute vs value for indicies).

I suggest we keep the CIR operations separate but make them share a ShuffleLikeInterface. Passes (including LLVM lowering) should use the interface when handling shuffles. The interface can be initially designed with the LLVM lowering use case so it could answer queries like "shuffle indicies dynamic?", "give me the input vectors", etc. Wdyt?

For naming, perhaps we can incorporate the semantic, I suggest:
vec.shuffle.ints -> vec.shuffle.static
vec.shuffle.vec -> ``vec.shuffle.dynamicAlternatively, the most common used one could bevec.shuffle` and the other suffixed with static or dynamic.

[dkolsen-pgi]

I think that creating ShuffleLikeInterface now is a case of designing for reuse too early. The lowering for the two vec.shuffle operations are so completely different (1 LLVM dialect operation vs. 26 LLVM dialect operations in the test case in this PR) that the interface would not enable any shared code.

I do like your naming suggestions for the operations. That was the part of this PR I was least sure about. I will rename vec.shuffle.ints to vec.shuffle (since I think that will be the more common one) and rename vec.shuffle.vec to vec.shuffle.dynamic.

[bcardosolopes]

I think that creating ShuffleLikeInterface now is a case of designing for reuse too early. The lowering for the two vec.shuffle operations are so completely different (1 LLVM dialect operation vs. 26 LLVM dialect operations in the test case in this PR) that the interface would not enable any shared code.

I'm not too worried about the lowering, but more on the consistency when looking at shuffles, the more operations the more passes need to be thought about and it becomes easier to miss things. I'm fine with this getting added later though, it's indeed some early design, can you add a TODO/FIXME comment to one of the operations to highlight the future intent?

[dkolsen-pgi]

I pushed a new commit that renames cir.vec.shuffle.ints and cir.vec.shuffle.vec to cir.vec.shuffle and cir.vec.shuffle.dynamic respectively. The only other changes are slight improvements to the descriptions of the operations and a TODO comment to create a vector-shuffle interface.