[Openmp-commits] [openmp] [flang] [mlir] [Flang][OpenMP] Initial mapping of Fortran pointers and allocatables for target devices (PR #71766)

[via Openmp-commits]

================
@@ -1759,6 +1760,183 @@ void collectMapDataFromMapOperands(MapInfoData &mapData,
       mapData.DevicePointers.push_back(
           llvm::OpenMPIRBuilder::DeviceInfoTy::None);
     }
+  };
+
+  // In the case of Fortran descriptors some members get added implicitly
+  // after the target region has been generated during CodeGen lowering
+  // which prevents them from being added trivially to the target region
+  // as map arguments, we must handle this case here by generating
+  // MapInfoData for them.
+  // TODO: Revisit this when implementing derived types explicit member
+  // mapping, we likely want to represent these identically to simplify
+  // the overall lowering
----------------
agozillon wrote:

The alternative is to add them earlier, but this would require keeping a mapping of BlockArgs <-> MapOperands as @TIFitis originally wished. There's a lot of code that expects a map operand to have a corresponding BlockArg at the exact same index in the BlockArg list (e.g. without the mapping it'd break pretty printing and another piece of mapping related code currently). And the mapping of descriptor elements do not have a corresponding IR symbol to have each map bound to a block argument (and neither will derived types from cursory initial exploration, their symbol in the IR appears to be their parent), so it's not possible to maintain a 1:1 mapping of map operands to block arguments, which then requires tracking the MapOperands <-> BlockArgs. 

I discussed adding this with @TIFitis but I believe we landed on leaving it out of this patch currently and revisit it in a subsequent derived type PR, but if it's something we wish to add now, then I am happy to do so. So, do please let me know. 

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