[Mlir-commits] [flang] [llvm] [mlir] [Flang][OpenMP][MLIR] Fix common block mapping for regular and declare target link (PR #91829)

[llvmlistbot at llvm.org]

agozillon wrote:

> > I am wondering if it is reasonable for me to generate common block member accesses within the target region and then bind the symbol for the common block members to them for the duration of the target region lowering. This or something very similar is currently done for another piece of OpenMP code related to privatization, so it's borrowing a similar concept. It results in the appropriate member accesses to the mapped common block as well as the correct usage of the newly generated local member accesses throughout the target operation.
> 
> For common blocks the OpenMP 5.2 standard in Section 3.2.1 Page 61 and Section 5.4 Page 108 has the following. I think privatization uses this description to privatize each member and hence have separate binding.
> 
> ```
> When a named commonblock appears in an OpenMP argument list,it has the same meaning and restrictions as if every
> explicit member of the commonblock appeared in the list.
> ```
> 
> ```
> If individual members of a commonblock appear in a data-sharing attribute clause other than the shared clause, the variables no longer have a Fortran storage association with the commonblock.
> ```

> In your proposal, when mapping the commonblock I am assuming each member get mapped separately. This is alrite as per the first point above. There could be a performance issue. Also assuming lowering to LLVM IR ensure that while each member is mapped separately, it is actually mapped offsets of the original commonblock.

 However, in the case where you perform using a common block symbol e.g. map(tofrom: /commonblock/) the mapping will be as if you map the entire block of memory, not as if you map each individually in this PR. You can see this in the tests e.g.: https://github.com/llvm/llvm-project/pull/91829/files#diff-0b2da1d2f88526ca7701608cd4b7478ea4a4c067abe549e90f04b798947498c4R236 

This was simpler from the perspective of how the IR in the target region is currently generated when the common block symbol is provided as well as with the eventual lowering to LLVM-IR with the way common blocks are implemented as a block of bytes that is indexed into per member.

However, in effect 

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