[cfe-dev] Implementing OpenMP function variants

[Doerfert, Johannes via cfe-dev]

Background:

The prototype for OpenMPs 5.1 feature `begin/end declare variant` caused
a discussion that seems to be stuck. I'll briefly outline the semantics
of the OpenMP 5.0 `declare variant` and the `begin/end declare variant`
here before I present the two competing designs on a very high level. If
there is a need for more information, a summary of what was said, or
anything else, please feel free to ask for it.

---

OpenMP 5.0 `declare variant` allows you to define a variant of a base
function that is called instead of the base function if the context
specified with the variant matches at a call site.

As an example, the call to base below is replaced by a call to special
if the code is compiled with a compiler that identifies as "llvm".

```
void special();

#pragma omp declare variant(special) match(implementation={vendor(llvm)})
void base();

void test() {
  base();
}
```

Context selectors for the match clause can be specific to the target,
the implementation, or the context in which the call is executed, e.g.,
syntactic inside a #omp parallel.

---

OpenMP 5.1 `begin/end declare variant` is an extension of the 5.0
version that (1) makes the user specific mangling obsolete, and (2)
guards the code in between the begin/end if the context selector does
not match at compile time. The use case can be simplified to the code
below in which we want the `sin` call to resolve to the NVIDIA specific
version if we are compiling for nvptx and to the one in math.h
otherwise. Note that the variant in the begin/end range has the same
name as the base it overloads.

```
#include "math.h"

#pragma omp begin declare variant match(device={arch(nvptx)})
double sin(double s) { return __nv_sin(s); }
#pragma omp end declare variant

double calc(double s) {
  return sin(sin(sin(s)));
}
```

---

Now that we are all OpenMP experts, we need to decide how/where to
implement this. Oversimplified, these are the options being discussed:

Proposal 1, CodeGen:
  Introduce aliases that redirect from one function to the other or
  replace the callee in the CodeGen.

Proposal 2), SemaOverload:
  Use the multi-version overloading for the 5.1 feature and introduce
  another level of overload resolution for the 5.0 feature.

---

Thanks in advance for your time and input,
  Johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20191213/ca0ba744/attachment.sig>