[flang-commits] [flang] [llvm] [mlir] [flang][mlir][OpenMP] Support iterator modifier in declare mapper map clause (PR #215485)

[Urvi Rav via flang-commits]

================
@@ -2046,13 +2046,125 @@ bool ClauseProcessor::processMap(
       }
     }
 
-    if (iterator)
-      TODO(currentLocation,
-           "Support for iterator modifiers is not implemented yet");
     TodoLocators(currentLocation, objects);
 
-    processMapObjects(stmtCtx, clauseLocation,
-                      std::get<omp::ObjectList>(clause.t), mapTypeBits,
+    llvm::SmallVector<IteratorRange> iteratorRanges;
+    llvm::SmallPtrSet<const Fortran::semantics::Symbol *, 4> ivSyms;
+    collectIteratorIVs(clause, converter, stmtCtx, iteratorRanges, ivSyms);
+
+    // Objects that reference an iterator induction variable are expanded at
+    // runtime via `omp.iterator`/`map_iterated`; the rest go through the
+    // regular static map-info path below.
+    omp::ObjectList staticObjects;
+    if (!iterator) {
+      staticObjects = objects;
+    } else {
+      fir::FirOpBuilder &firOpBuilder = converter.getFirOpBuilder();
+      for (const omp::Object &object : objects) {
+        if (!hasIteratorIVReference(object, ivSyms)) {
+          staticObjects.push_back(object);
+          continue;
+        }
+
+        // The per-iteration `omp.map.info` this produces lives inside the
+        // `omp.iterator` body and cannot be attached as a `members` operand
+        // of some other (parent) MapInfoOp built outside that region, since
+        // only the aggregated `!omp.iterated<T>` handle escapes the region.
+        // We still register the parent with `parentMemberIndices` (with no
+        // child attached) so `insertChildMapInfoIntoParent` synthesizes the
+        // usual partial/"storage" map for the parent object (e.g. the
+        // `declare mapper` association variable itself); the iterator-driven
+        // child map is emitted separately into `result.mapIterated`, mirroring
+        // how `map_vars`/`members` (static) and `map_iterated` (runtime
+        // expanded) already coexist as sibling operands on the owning op.
+        bool hasParentObj = object.sym()->owner().IsDerivedType();
+        mlir::Value baseAddr;
+        if (hasParentObj) {
+          omp::ObjectList objectList = gatherObjectsOf(object, semaCtx);
+          assert(!objectList.empty() &&
+                 "could not find parent objects of derived type member");
+          if (isMemberOrParentAllocatableOrPointer(object, semaCtx))
+            TODO(currentLocation,
+                 "Iterator modifier on this derived-type member in a map "
+                 "clause is not implemented yet");
+
+          omp::Object baseObject = objectList[0];
+          parentMemberIndices.emplace(baseObject, OmpMapParentAndMemberData{});
----------------
ravurvi20 wrote:

Fixed in `insertChildMapInfoIntoParent`: the existing-parent branch now only touches `memberMap`/moves the parent op when `memberMap` is non-empty. When a parent has only iterator-driven children (tracked via `mapIterated`, not `memberMap`), that block is skipped entirely, so `memberMap.back()` is never called on an empty vector.

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