[flang-commits] [flang] [Flang][OpenMP] Support iterator modifier in map and motion clauses (PR #197757)

[via flang-commits]

================
@@ -1870,6 +1912,53 @@ void ClauseProcessor::processMapObjects(
   }
 }
 
+// Process objects in map/motion clauses, lowering iterator-dependent
+// locators into `result.mapIterated` and all others through the regular
+// map-lowering path. A null `ivSyms` indicates that no iterator modifier
+// is present.
+void ClauseProcessor::processMapObjectsWithIterator(
+    lower::StatementContext &stmtCtx, mlir::Location clauseLocation,
+    const omp::ObjectList &objects,
+    llvm::ArrayRef<IteratorRange> iteratorRanges,
+    const llvm::SmallPtrSetImpl<const semantics::Symbol *> *ivSyms,
+    mlir::omp::ClauseMapFlags mapTypeBits,
+    std::map<Object, OmpMapParentAndMemberData> &parentMemberIndices,
+    mlir::omp::MapClauseOps &result, llvm::SmallVectorImpl<Object> &mapObjects,
+    llvm::StringRef mapperIdNameRef, bool isMotionModifier,
+    llvm::omp::Directive directive) const {
+  if (!ivSyms) {
+    processMapObjects(stmtCtx, clauseLocation, objects, mapTypeBits,
+                      parentMemberIndices, result.mapVars, mapObjects,
+                      mapperIdNameRef, isMotionModifier, directive);
+    return;
+  }
+
+  // Inside a declare mapper, the mapper variable's components are mapped
+  // directly, allowing member locators such as v%a(i). Mapping a derived-type
+  // member outside a declare mapper requires parent/member handling that
+  // iterator modifiers do not support yet.
+  bool inDeclareMapper = mlir::isa_and_present<mlir::omp::DeclareMapperOp>(
+      converter.getFirOpBuilder().getRegion().getParentOp());
+
+  // Objects in an iterator-modified clause may independently reference
+  // iterator variables, so handle each object separately.
+  for (const omp::Object &object : objects) {
+    if (hasIteratorIVReference(object, *ivSyms)) {
+      if (!inDeclareMapper && getBaseObject(object, semaCtx))
+        TODO(clauseLocation, "iterator modifier with derived type member map");
+      result.mapIterated.push_back(buildIteratedMapEntry(
+          converter, semaCtx, clauseLocation, iteratorRanges, object,
+          mapperIdNameRef, mapTypeBits, directive));
+      continue;
----------------
MattPD wrote:

An executable `!$omp target` region emits a whole-array implicit map of the iterated array, on top of the element map. Compiling `map(iterator(i=1:8), to: a(i))` with this patch (`flang -fc1 -emit-hlfir -fopenmp -fopenmp-version=52`), with `a` used in the body, emits both maps:

```mlir
%16 = omp.map.info var_ptr(%2#0 : !fir.ref<!fir.array<16xi32>>, ...) map_clauses(to) ... -> !llvm.ptr {name = ""}                     // element map, i = 1:8
%10 = omp.map.info var_ptr(%2#1 : !fir.ref<!fir.array<16xi32>>, ...) map_clauses(implicit, tofrom) ... -> !fir.ref<...> {name = "a"}  // whole array a(1:16)
omp.target map_iterated(%7 : !omp.iterated<!llvm.ptr>) map_entries(%10 -> %arg1 ...)
```

The iterated object is added to `mapIterated` but not `mapObjects`. So [`captureImplicitMap`](https://github.com/llvm/llvm-project/blob/f2cdab4c2e8bce895a78f9f00c27b902400c4923/flang/lib/Lower/OpenMP/OpenMP.cpp#L3107) treats `a` as unmapped. It then adds the whole-array `tofrom` map ([`OpenMP.cpp:3226-3227`](https://github.com/llvm/llvm-project/blob/f2cdab4c2e8bce895a78f9f00c27b902400c4923/flang/lib/Lower/OpenMP/OpenMP.cpp#L3226-L3227)). This changes the extent: the whole array is mapped, not the iterated elements. It also changes the direction: `to` gains a copy-back. The extra map is present in the generated IR today and has no test. It is not yet observable at runtime, because `map_iterated` translation is deferred to #199101. Would it be worth suppressing the implicit whole-array map for a symbol already mapped via an iterator, so #199101 does not inherit it?

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