[flang-commits] [flang] [Flang][Lower][OpenMP] Add initial lowering of pointers/allocatables/target in map clauses to map_info and entries (PR #68600)

[via flang-commits]

================
@@ -1752,11 +1754,82 @@ bool ClauseProcessor::processMap(
                                        semanticsContext, stmtCtx, ompObject,
                                        clauseLocation, asFortran, bounds);
 
+          auto checkIfStructComponent =
+              [](const Fortran::parser::OmpObject &ompObject) {
+                bool isComponent = false;
+                std::visit(
+                    Fortran::common::visitors{
+                        [&](const Fortran::parser::Designator &designator) {
+                          if (auto *structComp = Fortran::parser::Unwrap<
+                                  Fortran::parser::StructureComponent>(
+                                  designator)) {
+                            if (std::holds_alternative<Fortran::parser::Name>(
+                                    structComp->base.u))
+                              isComponent = true;
+                          }
+                        },
+                        [&](const Fortran::parser::Name &name) {}},
+                    ompObject.u);
+
+                return isComponent;
+              };
+
+          // TODO: Currently, it appears there's missing symbol information
+          // and bounds information for allocatables and pointers inside
+          // of derived types. The latter needs some additional support
+          // added to the bounds generation whereas the former appears
+          // that it could be a problem when referring to pointer members
+          // via an OpenMP map clause, for the moment we do not handle
+          // these cases and must emit an error.
+          if (checkIfStructComponent(ompObject) &&
+              Fortran::semantics::IsAllocatableOrPointer(
+                  *getOmpObjectSymbol(ompObject)))
+            TODO(currentLocation,
+                 "pointer members of derived types are currently unmapped");
+
+          if (Fortran::semantics::IsAllocatableOrPointer(
+                  *getOmpObjectSymbol(ompObject))) {
+            // We mimic what will eventually be a structure containing a
+            // pointer mapping for allocatables/pointers/target e.g.:
+            //
+            // !$omp target map(from:in, in%map_ptr)
+            //
+            // ===>
+            //
+            // map_entry varptr(in) ....
+            // map_entry varptr(map_ptr) varptrptr(in) ...
----------------
agozillon wrote:

Ah, then I misunderstood it then! Thank you for clarifying. Perhaps it'd be better creating a varParentPtr for OpenMP, if we continued down this route then, to seperate the two.

Yes, I thought we could probably ditch the descriptor at some point, but I thought of doing it as more of an optimisation case rather than the default, at least for the moment to get it working initially as it seemed simpler to get working initially whilst maintaining correctness at the trade off of it being slower for the time being. Simpler as the target region when lowered already takes into account the fact that the descriptor and pointer are lowered as a structure, so we simply treat it as such when mapping it. However, perhaps this isn't the best route to go down in the short-term or long-term? I've not yet looked at the complexity of implementing the other solution or the possible downsides, if any.

One case I can perhaps see that descriptors may be of use on the device is the following example:

```
      integer, target :: x(10)
      integer, pointer :: x_d(:)

      do i=1, 10
         x(i)=1
      enddo

      !$omp target map(from:x_d) map(to: x)
       x_d => x;
      !$omp end target
```

Where the descriptor for the pointer may need updated so that the host can appropriately utilise it, but this is just a thought and probably not a very well thought out one at that. 

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