Hi Francesco, did you think about adding the attribute instead of the pragma? It is a common way to express such constructs as function attributes in clang/GCC rather than as pragma.
Best regards,
Alexey Bataev
Hi Francesco, did you think about adding the attribute instead of the pragma? It is a common way to express such constructs as function attributes in clang/GCC rather than as pragma.
Yes, I thought about it, I believe that GCC plans to use attributes.
In Common Function Attributes (Using the GNU Compiler Collection (GCC)) there is a description of the “simd” attribute, but I couldn’t find an example of how it is used.
Also, I cannot find an attribute that is equivalent to the “declare variant” directive. Maybe it is planned for future releases.
The idea of using a `clang` equivalent of the `omp` directive was to avoid duplication in terms of handling both the attribute and the omp directive, as both directive will share much of the infrastructure.
Francesco, there won't be any duplication. Most of the declarative OpenMP directives are represented as attributes internally, so, I think, it will be natural to use an attribute here rather than pragma.
Best regards,
Alexey Bataev
Francesco, there won't be any duplication. Most of the declarative OpenMP directives are represented as attributes internally, so, I think, it will be natural to use an attribute here rather than pragma.
Very nice. I am open to get rid of the `clang` based directive in favor of the attribute one.
At the moment there is no “declare variant” attribute in the list of common function attributes at Common Function Attributes (Using the GNU Compiler Collection (GCC)). What should we do? Define our own, or wait for GCC to publish the attribute?
If we decide to do what GCC does, shall we actively participate in the discussion with the GCC community to shape the attribute itself? Am I right thinking that the GCC solution is preferred given that system header files are more likely to follow whatever GCC comes up with?
You can define clang specific attribute and later add GCC alias for it.
Best regards,
Alexey Bataev
You can define clang specific attribute and later add GCC alias for it.
This sounds very much equivalent to defining a clang specific directive and later add the GCC attributes? Should be less risky, because the GCC attributes will very likely represent what is in OpenMP? So doing the clang directive would guarantee more compatibility?
Or am I missing something about the two possible implementations?
Francesco
Yes, this is very similar, but only expressed in terms of clang attributes, which may have different spellings for clang, GCC, c++11 etc. I don't think GCC will implement this as pragma. They added simd attribute instead of pragma.
Best regards,
Alexey Bataev
Yes, this is very similar, but only expressed in terms of clang attributes, which may have different spellings for clang, GCC, c++11 etc. I don't think GCC will implement this as pragma. They added simd attribute instead of pragma.
OK, I think I didn’t make myself clear. Let me try make my view explicit.
SOLUTION 1: we use clang specific attributes, to represent the info provided via OpenMP `declare variant`
SOLUTION 2: we duplicate `declare variant` in the `omp` namespace into the `clang` namespace.
Independently of whether or not we do SOLUTION 1 or 2, GCC will come up with a set of attributes that they will use to represent `declare variant in OpenMP.
Once GCC does that, the next steps for each solutions will be:
SOLUTION 1: we will have to create aliases that map the clang-specific attributes to the GCC ones.
SOLUTION 2: we will have to implement handling of the gcc attribues
Now, the two solutions look equivalent, but what if there is no 1:1 mapping between the set of clang-specific attributes and the GCC ones? There might be little risk for that, but it is non zero.
If we opt for duplicating the `omp` directive in the `clang` namespace, we reduce the risk of incompatibility to zero, because GCC will do what OpenMP asks to do.
So, I think I’d prefer to go for the solution of the `declare variant` in the `clang` namespace, which also have the advantage of reducing the documentation describing it along the lines of:
`#pragma clang declare variant …`: Please refer to section X of OpenMP 5.0.
How nice is that, compared to listing the clang specific attributes and explaining their behavior? 
I'd suggest to use the same attribute for omp declare vatiant and clang-specific variant attribute internally. Initially, clang attribute may have the same properties, the omp version of the directive has (expressed as clauses). Later, if GCC will add their own version with their set of properties, we could try to reuse the existing internal attribute representation or introduce the new, gcc-compatible, one.
Best regards,
Alexey Bataev
Yes, VectorABI from ICC, ARM, GCC are base for extending it for declare variant ABI. The direction to have a unified ABI and set of attributes.
Xinmin
In this case, we can reuse the same attribute for both, omp directive and clang variant attribute.
Best regards,
Alexey Bataev
In this case, we can reuse the same attribute for both, omp directive and clang variant attribute.
Let me summarize what we seem to be converging towards:
FRONTEND
#pragma omp declare variant(vector_foo) match(context-matchers)
double foo(double);
Vector_double vector_foo(vector_double)
Equivalent to a clang specific attribute
double foo(double) __attribute__(declare_variant(vector_foo, context-matchers));
The content-matchers will be the same, and the parsing mechanisms shared among the function attribute in C and the omp directive.
For now, we teach clang only about the variant in a `context=simd()`.
MIDEND (IR)
We use an attribute, vector-variant, to represent the information that the frontend will be handling:
#attribute #0 = {vector-variants=“_ZGV…_foo(vector_foo), …."}
The same attribute is used by both `declare variant` and `declare simd`, the only difference being that for `declare simd` there is no custom name redirection via the `(vector_foo)` token.
NAME MANGLING
We live with the name mangling of the vector function ABI of the target. If OpenMP comes up with a new name mangling convention, we will discuss whether we want to support that too.
EXTENDING TO FUL SUPPORT OF `declare variant`
That is not part of this RFC. With this RFCm the frontent will generate the `vector-variant` attribute that is limited only for auto-vectorization in a SIMD context. Other aspect of `declare variant` will be handled in a separate RFC.