[flang-commits] [flang] [mlir] [Flang][OpenMP] Privatize descriptors for assumed shape array maps for performance increase (PR #212336)

[via flang-commits]

================
@@ -7424,16 +7437,26 @@ static void processMapWithMembersOf(LLVM::ModuleTranslation &moduleTranslation,
 
   llvm::omp::OpenMPOffloadMappingFlags memberOfFlag =
       ompBuilder.getMemberOfFlag(combinedInfo.Types.size());
-  for (size_t i = 0; i < mapInfoIdx.size(); i++) {
-    // Index == 0 is the parent map and if it gets here it's an unattachable
-    // type and should have OMP_MAP_TARGET_PARAM applied and no MEMBER_OF flag.
-    if (i == 0) {
+
+  // The first index is the parent map, the rest are its members. The parent
+  // normally undergoes the standard parent-with-members mapping, contributing
+  // the MEMBER_OF flag that binds each member to it. The one exception is a
----------------
agozillon wrote:

So, while it is not a map in terms of the usual H2D/D2H transferal, a map still needs emitted in terms of map entry information the same as most other firstprivatization cases. When the comment is speaking about parent mapping in this situation, it is speaking in terms of the function's handling of the parent <-> member relationship between members of a parent map_info containing multiple members, and how we regularly treat this relationship for these cases (e.g. MEMBER_OF flag handling, slicing the parent map into what's required to be transferred, some other bits of handling done by mapParentWithMembers).

The attach privatization mapping doesn't care about MEMBER_OF as far as I am aware as it's specifically pointer privatization, and in the current case this mapping is constrained (by the frontend) to assumed shape arrays which is effectively a pointer mapping, so we can skip the complexity of the usual MEMBER_OF path for the moment. This will have to be revised in a secondary PR though when (hopefully) we extend the pointer privatization to cover more descriptor cases, primarily cases where we have an allocatable/pointer derived type, as there is still some level of parent child relationship required there (desc -> record data -> children).

The individual map wording is just to distinguish between processIndividualMaps vs mapWithParentMembers, the former is an attempt to collate the more generalized map entry generation into an individual function! For the most part it boils down to skipping the secondary map generation that mapWithParentMembers does to avoid extra complexity to this type of mapping for the moment, until we progress to a second pass and extend it.

Please do feel free to recommend alternative wording if you think it's more readable to others.


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