Codegen of `declare simd`

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Codegen of `declare simd`

Fangrui Song via cfe-dev
Hi all,

I have started working on modifying the codegeneration of `declare simd` to produce the `vector-function-abi-variant` attribute [0].

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 [2],

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 [3], where the vector function classification is done by mapping the scalar name to the vector name using a VFShape (vector function shape)n [4] (VFShape knows about the different vector  parameter types [5] 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 [3] and modify the codegen to use such class instead of a vector of `ParamAttrTy`.
B. modify `CGOpenMPRuntime::emitDeclareSimdFunction` to generate the attribute in [0].

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?

Kind regards,

Francesco

[0] https://llvm.org/docs/LangRef.html#call-site-attributes
[1] https://reviews.llvm.org/D72734
[2] http://lists.llvm.org/pipermail/llvm-dev/2019-June/133484.html
[3] https://llvm.org/doxygen/structllvm_1_1VFInfo.html
[4] https://llvm.org/doxygen/structllvm_1_1VFShape.html
[5] https://llvm.org/doxygen/structllvm_1_1VFParameter.html and https://llvm.org/doxygen/namespacellvm.html#add480f2ed87faa59c16d4c01ffb4bf39

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev