[flang-commits] [flang] [flang][OpenMP] Fix privatization of threadprivate common block (PR #77821)

[via flang-commits]

NimishMishra wrote:

> There was a patch some time back that fixed a similar issue. That patch looked at it from the point of creating the missing symbols. https://reviews.llvm.org/D145684

@kiranchandramohan Which of the two approaches seems better? I think this patch handles it better than explicit symbol creation in https://reviews.llvm.org/D145684. I generated the IR for some tests (including the one in https://reviews.llvm.org/D145684) with this PR. All tests dumped similar IR:

```
fir.global @<module_var>

func.func @<function_name> attributes ... {
    %0 = fir.address_of(module_var)
    %1 = fir.declare %0 ...
    omp.parallel {
          %2 = omp.threadprivate %1
          %3 = fir.declare %2
          fir.load %1
          fir.store %4 to %3
    }
}
```

Even host-association tests in the linked patch (below) works ok. For instance,

```
module tpmod
  real :: val = 2.0
end module

subroutine tptest2
  use tpmod
  call tps()
contains
  subroutine tps()
    !$omp parallel
    !$omp single
      val = 1.0
    !$omp end single
    !$omp end parallel
  end subroutine
end subroutine
```

have the following IR with this PR:

```
fir.global @_QMtpmodEval : f32 {
   %cst = arith.constant 2.000000e+00 : f32
   fir.has_value %cst : f32
}

func.func @_QFtotest2Ptps() attributes : {
   %cst = arith.constant 1.000000e+00 : f32
   %0 = fir.address_of(@_QMtpmodEval)
   %1 = fir.declare %0 
   omp.parallel {
      omp.single {
          fir.store %cst to %1
          omp.terminator
      }
     omp.terminator
   }
   return
}
```
Which seems like the intended behaviour: capturing the globally declared variable, and updating it within single as required. 

So I wonder if we can do with the current approach, and not by creating extraneous symbols.

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