Add support for vector types

[bcardosolopes]

Add support for vector types

[dkolsen-pgi]

Should new operations be created for vector types? Or should the existing ops be reused?

I am guessing new ops are needed, since the semantics for some operations, especially the relational operators, are quite different for vectors than for scalars.

[dkolsen-pgi]

https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors has some useful information about Clang's support for vector types. There are five different kinds of vector types: GCC, OpenCL, Arm NEON, Arm SVE, and AltiVec. I believe that all except for SVE can share the same ClangIR vector type with an element type and a size. The Arm SVE vector types are different and will need their own ClcangIR type because they don't have a compile-time size.

[dkolsen-pgi]

I am rethinking having separate CIR types for fixed-sized vectors and scalable vectors. Base MLIR has one meta-type for both (which also covers multidimensional arrays). But I'll figure that out later. Right now I'm implementing fixed-sized vector types. Once that is mostly working I'll decide what to do about scalable types.

[dkolsen-pgi]

When PR #531 is merged, I will resolve this issue, since GNU vector types support will be complete. I have created separate issues to implement other kinds of vectors: #532, #533, #534, and #535.

[bcardosolopes]

Should new operations be created for vector types? Or should the existing ops be reused?

This is a very relevant question!

I am guessing new ops are needed, since the semantics for some operations, especially the relational operators, are quite different for vectors than for scalars.

Right, similar to the std::simd drama with == and others. My take here:

• BinOp already exists and isn't constrained to any type just yet (operands are AnyType). I'd say we reuse it for vector types because it only considers arith and logical operations, so at CIR level semantics are probably good enough. If along the way we find reasons to create specific ones, we incrementally work on those.
• CmpOp is where the difference shines, I'd say we create new ops for these. We should also change the operation constraints for CmpOp to disallow types other than scalars.
• All other vector specific relevant things (shuffle, reduce, etc) should have their own ops too (meaning, we could lower intrinsics/builtins directly to them).

[bcardosolopes]

Sounds good, looks like both SVE & RISC-V V have that property. Perhaps when we get there we should generalize the vector types to use ShapedType trait, like memref and tensor do. So we could have a cir.vec<?xf32> type.