[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)
----------------
agozillon wrote:

The "from" is just an arbitrary example, likely a bad one, however, currently it takes whatever mapping the original mapping has, perhaps it should be something different though! As I agree, from indicates we're allowing allocation 
on device, although, I believe that might be something for the semantic stage to call out, as I imagine it's perhaps legal to assign to a "from" target on device, from a host side allocated pointer passed in as a "to", although my spec knowledge is quite lacking on this (and many many other areas, so do please point out when I'm wrong).

However, for the two bullet points:
- You can access a descriptor on the device if it was passed to it via fromto/to, it is currently initialized in the current implementation I have, at least from my understanding. The examples, except the last one (which needs a chunk of work to function at runtime for unrelated reasons, it's an aspirational example for now) allows me to loop over the allocated data and assign values to it then return the updated data. The descriptor and data is currently lowered to the following LLVM-IR structure by default { ptr, i64, i32, i8, i8, i8, i8, [1 x [3 x i64]] }, where the ptr is the data and the rest of the descriptor information is contained in the structure and the kernel generated by the target region currently expects this and treats it as such (using a default LLVM-IR lowering), rather than as raw pointers. I currently map the structure in it's entirety as you would in the OpenMP examples I've provided with the explicit member accesses. However, perhaps this is the wrong way to go about it (and the method I mention in the note where we try to treat it as a naked pointer and discard the descriptor is the right way to go in the first place, although I'm unsure how to get to that stage currently), although it does function reasonably just now, albeit without any extreme tests being done, just simple first step tests.  
- I'm fairly certain you're correct that it won't work, I believe the descriptor would update, but the data would not be mapped back (if the allocation was even possible, which currently it's not). However, pointer/target re-assignment on device should likely be supported from my understanding, and I imagine mapping the descriptor across alongside the pointer + data and updating it may be the easiest method to do so, although I admit it's not something I've tested or dug into deeply yet! 
  
This is just me giving some information from my current experience trying to get this mapping working for OpenMP so far, so perhaps my understanding is flawed/incorrect, so do take it all with a grain of salt, I'll happily defer to you all with more experience!

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