[Mlir-commits] [flang] [mlir] Fixing miscompilation with OMP synchronization at higher optimizations (PR #202258)

[Deepak Eachempati]

================

----------------
dreachem wrote:

This is checking for constructs that imply a barrier and some additional constructs that imply synchronization. However, this is missing some additional constructs that can have implicit barriers (namely **scope** and **workshare**). Also, the release/acquire flushes that occur on entry to critical and ordered constructs also occur on various task-generating constructs. 

It would be better to check for (a) worksharing constructs (which imply a barrier) or (b) any other constructs that have implicit flushes on entry/exit. There are many not covered by the constructs here (task-generating constructs, like **task**), including OpenMP routine calls (e.g., *omp_set_lock** and *omp_unset_lock**). 

Could the issue here be reproduced with dependent tasks? Will the load of `tmp` be hoisted out of the **task** construct in the code below at higher optimization levels, or does the lowering at this point prevent that?

```
subroutine sub(tmp)
   real(kind=8) :: tmp
   integer i
   do i = 1, N
      !$omp task depend(inout) shared(tmp)
         tmp = tmp + real(i,8)
      !$omp end task
   end do
end subroutine
```

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