This RFC is for adding the PowerPC vector type support as a language extension.
It has the following syntax:
VECTOR(element-type-spec)
where
element-type-spec
is:
integer-type-spec
or
real-type-spec
or
unsigned-type-spec
A finite set of functionalities are implemented in order to support the PowerPC vector type:
- declare VECTOR type objects.
- declare VECTOR type function result.
- declare VECTOR type dummy arguments.
- intrinsic assignment between VECTOR type objects. (e.g. v1 = v2)
- reference VECTOR functions.
This patch only supports the functionalities mentioned at the above. Others, such as intrinsic operators are not extended to support vectors as all operations on vector types (such as addition, subtraction, construction, ... etc) are done via calls to vector intrinsic functions. The support of constant expressions, derived component, POINTER or ALLOCATABLE attribute, I/O, and etc is not included in this patch.
The purpose of this RFC is to get comments from the community on our implementation approach. We plan to add the LIT tests in this patch as a revision soon. We also plan to add semantic checking in a separate patch in the near future.
Personally, I would not favor making "Vector" a type category: it is a bit orthogonal to the element type (it looks more like a very special shape attribute to me that would create a constant size rank one array of element with special semantic (e.g: cannot be used in intrinsic operators)).
The TypeCategory is also very central to all the type system in the compiler after parsing, I feel it makes this extension very intrusive.
Could the "Vector" aspect be represented as a special attributes that could be added to the vector dummy or result symbols? (It would probably need to be added to the characteristics DummyDataObject and FunctionResult attributes in https://github.com/llvm/llvm-project/blob/main/flang/include/flang/Evaluate/characteristics.h).
I have not thought this in detail, and cannot be sure this would work, but I wonder if you could represent the vector type as a builtin kind parametrized derived type in semantics (inside evaluate:: and semantics::) that would look like:
That way, it would be transparent in semantics (there may be a few places where it would need to be forbidden explicitly in places where a parametrized derived type is allowed (e.g parentheses)). As a funny extension, this would allow you to define the ppc vector intrinsic as type bound procedures for +,-,... operators if you ever wanted to allow the usage of operators for ppc vectors.
In lowering, the builtin type would be recognized and translated to the fir.vector type (some code might expect to get a fir.record type from a semantics Derived, but not many places should be impacted).
In any case, I would wait for more feedback from @klausler here on this point.