[llvm-dev] Codegen of `declare simd`
Francesco Petrogalli via llvm-dev
llvm-dev at lists.llvm.org
Fri Apr 17 17:42:18 PDT 2020
I have started working on modifying the codegeneration of `declare simd` to produce the `vector-function-abi-variant` attribute .
Given that the `vector-function-abi-variant` attribute is supposed to be used in multiple codegen cases:
1. `declare simd`
2. `declare variant` for `simd` context,
3. and in the C attribute that we have agreed in ,
I propose, as a first step, to come up with a unified way to handle such code-generation, so that most of the code will be shared among the three cases.
As a matter of fact, each of 1 2 and 3 will have their own clang attribute in clang/Basic/Attr.td. We can create a layer that translate each of these attributes into a shared representation of the scalar-to-vector mappings, so that we can have a single implementation that perform code generation for such attributes.
In LLVM there is already a layer that maps scalar functions to vector function, the VFInfo class defined in llvm/Analysis/VectorUtils.h , where the vector function classification is done by mapping the scalar name to the vector name using a VFShape (vector function shape)n  (VFShape knows about the different vector parameter types  inferred by the OpenMP clauses).
With this in mind, I propose to modify codegen of `declare simd` as follow:
A. translate the attribute `OMPDeclareSimdDeclAttr` used by `CGOpenMPRuntime::emitDeclareSimdFunction` VFInfo  and modify the codegen to use such class instead of a vector of `ParamAttrTy`.
B. modify `CGOpenMPRuntime::emitDeclareSimdFunction` to generate the attribute in .
An alternative to A. could be to modify the `ParamAttrTy` to handle all cases that we need to support (linear, linear ref, uniform, align...), and then use it for all 1.2.3. cases listed, but it seem quite handy to reuse the classification of vector functions that is already available in VFShape/VFInfo.
Any thoughts? Does this make sense?
 https://llvm.org/doxygen/structllvm_1_1VFParameter.html and https://llvm.org/doxygen/namespacellvm.html#add480f2ed87faa59c16d4c01ffb4bf39
More information about the llvm-dev