[flang-commits] [flang] [flang][OpenMP] Lowering support for declare variant. (PR #206988)

[via flang-commits]

================
@@ -0,0 +1,200 @@
+! RUN: %flang_fc1 -emit-fir -fopenmp -fopenmp-version=51 %s -o - | FileCheck %s
+! RUN: %flang_fc1 -emit-hlfir -fopenmp -fopenmp-version=51 %s -o - | FileCheck %s
+
+! Lowering tests for DECLARE VARIANT callee resolution at call sites.
+! The declarative directive is not lowered; variant selection rewrites
+! procedure calls inside matching OpenMP regions.
+
+subroutine test_sequential_vs_parallel
+  call base()
+  !$omp parallel
+  call base()
+  !$omp end parallel
+end subroutine test_sequential_vs_parallel
+
+subroutine base
+  !$omp declare variant (base:vsub) match (construct={parallel})
+contains
+  subroutine vsub
+  end subroutine
+end subroutine base
----------------
jeanPerier wrote:

In most of your examples, you are using internal procedures to define variants of the host. Is this a common OpenMP pattern for this feature?

I do not think this should be allowed because that means that calls from an external context could call the internal procedure directly which could lead to a lot of bugs because internal procedure usually requires a host link to the context of variables from the host which does not exits in this case.

In other words, this is opening the doors to a lot of bugs. For instance in the following code, calling vsub directlty from `test_teams_vs_parallel` would lead to bugs since `local` belongs to `base` stack frame that does not exists here.

```
subroutine base
  !$omp declare variant (base:vsub) match (construct={parallel})
  integer :: local
  local = 1
contains
  subroutine vsub
     print *, local
  end subroutine
end subroutine base
```


If anything, I think the OpenMP standard may be under defined here as it only says that:

```
The characteristic of the function variant must be compatible with the characteristic of the
base function after the implementation defined transformation for its OpenMP context.
```

Your code is not violating this constraint, base and vsub have the same charactersitic (it is for instance allowed to assign both of them to the same procedure pointer), but vsub only exists within the context of `base` and it should not be possible to call it from outside any `base` context.

https://github.com/llvm/llvm-project/pull/206988