[llvm-branch-commits] [Flang][OpenMP][MLIR] Extend derived (record) type map support in Flang OpenMP by adding some initial support for explicit member mapping (PR #81511)

[via llvm-branch-commits]

================
@@ -1906,8 +2036,22 @@ bool ClauseProcessor::processMap(
 
         for (const Fortran::parser::OmpObject &ompObject :
              std::get<Fortran::parser::OmpObjectList>(mapClause->v.t).v) {
+          llvm::omp::OpenMPOffloadMappingFlags objectsMapTypeBits = mapTypeBits;
+          checkAndApplyDeclTargetMapFlags(converter, objectsMapTypeBits,
+                                          getOmpObjectSymbol(ompObject));
+
           llvm::SmallVector<mlir::Value> bounds;
           std::stringstream asFortran;
+          const Fortran::semantics::Symbol *parentSym = nullptr;
+
+          if (getOmpObjectSymbol(ompObject)->owner().IsDerivedType()) {
+            memberPlacementIndices.push_back(
+                firOpBuilder.getI64IntegerAttr(findComponenetMemberPlacement(
+                    getOmpObjectSymbol(ompObject)->owner().symbol(),
----------------
agozillon wrote:

Ah yes, I recalled a little more of the details behind this choice at the moment after looking into this little segment again, and I'd love for someone with perhaps more knowledge on this to chime in if there's perhaps a better method, perhaps there's something I am not doing correctly.

So another factor is that in the use case above, given the following derived type and its instantiation:

```
 type t0
    integer :: a0, a1
  end type

type(t0) :: a

!$omp target map(a%a1)
   a%a1 = 0
!$omp end target
```

`getOmpObjParentSymbol` will return the symbol:

`a size=8 offset=0: ObjectEntity type: TYPE(t0)`

which is the symbol for the instantiation of the derived type being used within the map clause, whereas if we use `getOmpObjectSymbol(ompObject)->owner().symbol()`, we end up with the following:

`t0: DerivedType components: a0,a1`

Which in this case appears to refer to the derived type. The latter is needed for finding the relevant component indices, as we can check the member symbols, the former is the symbol that will actually be bound and used for the map.

Please do take the above with a grain of salt though, I could be making certain assumptions based on the things I've done so far.

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