[llvm-branch-commits] [Flang][OpenMP] Derived type explicit allocatable member mapping (PR #111192)

[via llvm-branch-commits]

================
@@ -49,38 +51,95 @@ using DeclareTargetCapturePair =
 // and index data when lowering OpenMP map clauses. Keeps track of the
 // placement of the component in the derived type hierarchy it rests within,
 // alongside the generated mlir::omp::MapInfoOp for the mapped component.
-struct OmpMapMemberIndicesData {
+//
+// As an example of what the contents of this data structure may be like,
+// when provided the following derived type and map of that type:
+//
+// type :: bottom_layer
+//   real(8) :: i2
+//   real(4) :: array_i2(10)
+//   real(4) :: array_j2(10)
+// end type bottom_layer
+//
+// type :: top_layer
+//   real(4) :: i
+//   integer(4) :: array_i(10)
+//   real(4) :: j
+//   type(bottom_layer) :: nested
+//   integer, allocatable :: array_j(:)
+//   integer(4) :: k
+// end type top_layer
+//
+// type(top_layer) :: top_dtype
+//
+// map(tofrom: top_dtype%nested%i2, top_dtype%k, top_dtype%nested%array_i2)
+//
+// We would end up with an OmpMapParentAndMemberData populated like below:
+//
+// memberPlacementIndices:
+//  Vector 1: 3, 0
+//  Vector 2: 5
+//  Vector 3: 3, 1
+//
+// memberMap:
+// Entry 1: omp.map.info for "top_dtype%nested%i2"
+// Entry 2: omp.map.info for "top_dtype%k"
+// Entry 3: omp.map.info for "top_dtype%nested%array_i2"
+//
+// And this OmpMapParentAndMemberData would be accessed via the parent
+// symbol for top_dtype. Other parent derived type instances that have
+// members mapped would have there own OmpMapParentAndMemberData entry
+// accessed via their own symbol.
+struct OmpMapParentAndMemberData {
----------------
agozillon wrote:

I would prefer to keep it the way it is (at least for this iteration), as a structure of arrays as opposed to an array of structures, I had it as the latter originally, but it makes the functions for transforming from this structure to the array attributes that the map holds and vice versa more complicated and accessing and storing the data is a little bit more cumbersome. I believe the rather large description above also helps describe the intent of the structure, or I would hope at least or I could have skipped writing it :-)

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