[flang-commits] [flang] [flang][OpenMP] Fix detecting nested OpenMP constructs (PR #143383)

[Krzysztof Parzyszek via flang-commits]

kparzysz wrote:

This issue was exposed by https://github.com/llvm/llvm-project/pull/137852

With the PR in place, the atomic construct contains a nested evaluation (an assignment), which causes the code to exclude variables defined in it.  This, in turn, caused the `prv` variable (from the testcase) to not be privatized at all.

The PFT tree with the new atomic code:
```
1 Function fred: integer function fred
  1 AssignmentStmt: prv=1
  2 <<OpenMPConstruct>>
    3 <<OpenMPConstruct>>
      4 <<OpenMPConstruct>>
        5 AssignmentStmt: prv = prv + 1
      <<End OpenMPConstruct>>
    <<End OpenMPConstruct>>
  <<End OpenMPConstruct>>
  6 AssignmentStmt: fred = prv
  7 EndFunctionStmt: end
End Function fred
```

The generated MLIR for the OpenMP constructs:
```
    omp.parallel {
      omp.task {
         %c1_i32_0 = arith.constant 1 : i32
        omp.atomic.update %4#0 : !fir.ref<i32> {
        ^bb0(%arg0: i32):
          %7 = arith.addi %arg0, %c1_i32_0 : i32
          omp.yield(%7 : i32)
        }
        omp.terminator
      }
      omp.terminator
    }
```

The expected MLIR is (note the "private" clause on the "omp.task" construct):
```
    omp.parallel {
      omp.task private(@_QFfredEprv_firstprivate_i32 %4#0 -> %arg0 : !fir.ref<i32>) {
        %7:2 = hlfir.declare %arg0 {uniq_name = "_QFfredEprv"} : (!fir.ref<i32>) -> (!fir.ref<i32>, !fir.ref<i32>)
        %c1_i32_0 = arith.constant 1 : i32
        omp.atomic.update %7#0 : !fir.ref<i32> {
        ^bb0(%arg1: i32):
          %8 = arith.addi %arg1, %c1_i32_0 : i32
          omp.yield(%8 : i32)
        }
        omp.terminator
      }
      omp.terminator
    }
```

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