The way vector types work in Thorin current matches LLVM: pointers and primitive types can be widened by setting a length field to a value other than 1. I believe this design is problematic and instead I suggest using vector type constructors (ie: vector_type(prim_type(i32), 4)).
Lots of code in Thorin is written with a questionable attention to flattened vector types, and patterns-match PrimType(i32, ...) as "a signed 32-bit integer" when it could in fact be a vector. By making the vector types use another constructor, there are no more risks of making this mistake. Making our type system syntax-directed prevents such oversights and better matches how the other backends deal with vectors (C, Shady, SPIR-V).
The new VectorType takes a ScalarType as a base. Only PrimType and PtrType inherit from ScalarType, matching the classic Thorin/LLVM behavior. For convenience, I added deconstruct_vector and a few more helper methods to be able to treat ScalarType and VectorType more or less as the old VectorType.
The way vector types work in Thorin current matches LLVM: pointers and primitive types can be widened by setting a
lengthfield to a value other than1. I believe this design is problematic and instead I suggest using vector type constructors (ie:vector_type(prim_type(i32), 4)).Lots of code in Thorin is written with a questionable attention to flattened vector types, and patterns-match
PrimType(i32, ...)as "a signed 32-bit integer" when it could in fact be a vector. By making the vector types use another constructor, there are no more risks of making this mistake. Making our type system syntax-directed prevents such oversights and better matches how the other backends deal with vectors (C, Shady, SPIR-V).The new
VectorTypetakes aScalarTypeas a base. OnlyPrimTypeandPtrTypeinherit fromScalarType, matching the classic Thorin/LLVM behavior. For convenience, I addeddeconstruct_vectorand a few more helper methods to be able to treatScalarTypeandVectorTypemore or less as the oldVectorType.