[llvm-branch-commits] [Flang][OpenMP] Derived type explicit allocatable member mapping (PR #111192)
Kareem Ergawy via llvm-branch-commits
llvm-branch-commits at lists.llvm.org
Tue Oct 8 04:21:16 PDT 2024
================
@@ -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 {
----------------
ergawy wrote:
Could this be something like this:
```suggestion
struct OmpMapParentAndMemberData {
struct MemberMappingData {
llvm::SmallVector<int64_t> placementIndices;
mlir::omp::MapInfo memberMap;
};
llvm::SmallVector<MemberMappingData> allMembersData;
};
```
The reason I think this is better is that it ties all the mapping data for a single member in one structure which makes easier to understand what `OmpMapParentAndMemberData` encapsulates.
https://github.com/llvm/llvm-project/pull/111192
More information about the llvm-branch-commits
mailing list