[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:

> Sorry about using "attach" terminology - after looking through OpenMP spec, it does not seem to be the common use of the semantics I meant. https://www.openmp.org/spec-html/5.2/openmpsu6.html#x13-120001.2.6 look for "attached pointer". Anyway, attach in my use of it, means, that if you have something like: struct S { double * p; } s; map(tofrom:s,s.p) Then in device memory, s is slightly different. Its field `p` points to the device memory. The concept of changing device `s`'s p field is called `attach` in OpenACC terms.

No need to apologies, even if you used the OpenMP terminology I wouldn't have understood in this case, so thank you for looking it up for me and teaching me in this case. 

To perhaps give a bit more information to hopefully aid discussion, I believe it works as I do some cheating to recreate the GEP for the final segment in this example: https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CGOpenMPRuntime.cpp#L6989 that likely only works in this specific case and I'd love to be able to fix it as it's on my TODO list! On the off chance that you're interested in looking at the lowering to LLVM-IR that I have in place currently, here's the little blob of code that I've currently managed to put together to generate the relevant runtime components to do the initial offload of the allocatables/pointers as a special case of a structure (sorry it's downstream and a tad messy, you can ignore effectively everything outside of this function):  https://github.com/ROCm-Developer-Tools/llvm-project/pull/225/files#diff-2cbb5651f4570d81d55ac4198deda0f6f7341b2503479752ef2295da3774c586R1983

The varPtrPtr being the parent in this perhaps terrible use-case is primarily to indicate that something is part of another object and to then sort it into groupings of parent + children so they can be mapped as such. Using the varPtrPtr for this is likely not the best way to do things and is as you've stated a misuse of the field (hence the suggestion of a parent field, but that in itself is perhaps misguided thinking). 

This is initial/WIP work as someone new to a lot of OpenMP/OpenACC and Fortran concepts, so I am more than happy to adjust/change things based on suggestions and look into other directions if there's better avenues! e.g. perhaps as I think you've said mapping the descriptor is not the way to go long term (although, for initial functionality it could be nice to treat them as such, with descriptor removal being a later step and more optimal approach).

Thank you for your input on this patch as well as @jeanPerier it's very appreciated. 


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