[flang-commits] [flang] [flang][openmp] Support importing module declare target globals (PR #213930)

[Ville-Markus Yli-Suutala via flang-commits]

VeeEM wrote:

Thank you for looking at this. There are definitely some gaps.

The enter clause could be automap, but automap has not been implemented for module files yet. Because of this I have just set automap to false for imported variables in this patch.

I also found that the variable list of a to clause is ignored by the module writer. I opened another pr with a 1 line change to fix this https://github.com/llvm/llvm-project/pull/213936

Another gap I noticed while working on this is how conflicting capture clauses applied to global variables are being handled (or not very handled I guess) in flang right now. A lowered declare target global can only have one capture clause on it, but before lowering it could even have all of them. How it gets lowered depends on the order of things.

If they are part of the same directive they get priority from highest to lowest in the order, enter, link, to, because this is the order the clauses are processed.
```
! var gets capture clause enter
!$omp declare target link(var) enter(var)
```

If there are multiple directives, its the first one that applies
```
! var gets capture clause link
!$omp declare target link(var)
!$omp declare target enter(var)
```
, except if a subsequent directive has a different device_type, in which case it's the last one that counts
```
! var gets capture clause to
!$omp declare target link(var)
!$omp declare target enter(var) device_type(nohost)
!$omp declare target to(var) device_type(nohost)
```

The module writer writes all the clauses to the module file but not which one was actually used. In this patch I check the clauses in the ClauseSet on the symbol in the order, link, to, enter, and select the first one that matches. But if the symbol has more than one capture clause it is not guaranteed the same one is selected as when the exporting module itself was compiled.

But is there even a reason to allow conflicting capture clauses on the same variable at all? Or should there be a semantic check that rejects such programs?

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