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

[via flang-commits]

================
@@ -317,6 +317,48 @@ static mlir::Value buildIteratorOp(Fortran::lower::AbstractConverter &converter,
   return itOp.getResult();
 }
 
+// Build an omp.iterator op that yields a MapInfoOp for a single
+// iterated object.
+static mlir::Value buildIteratedMapEntry(
+    Fortran::lower::AbstractConverter &converter,
+    Fortran::semantics::SemanticsContext &semaCtx, mlir::Location loc,
+    llvm::ArrayRef<IteratorRange> iteratorRanges, const omp::Object &object,
+    llvm::StringRef mapperIdName, mlir::omp::ClauseMapFlags mapTypeBits,
+    llvm::omp::Directive directive) {
+  mlir::Type ptrTy =
+      mlir::LLVM::LLVMPointerType::get(&converter.getMLIRContext());
+  mlir::Type iterTy =
+      mlir::omp::IteratedType::get(&converter.getMLIRContext(), ptrTy);
+
+  return buildIteratorOp(
+      converter, loc, iterTy, iteratorRanges,
+      [&](fir::FirOpBuilder &builder, mlir::Location loc,
+          llvm::ArrayRef<mlir::Value> /*ivs*/) -> mlir::Value {
+        lower::StatementContext iterStmtCtx;
+        std::optional<IteratorMapInfo> mapInfo = genIteratorMapInfo(
+            converter, builder, semaCtx, iterStmtCtx, object, loc);
+        if (!mapInfo)
+          TODO(loc, "object type not supported by iterator modifier");
+
+        // Use the array base as var_ptr with bounds so the runtime can
+        // associate this mapping with whole-array mappings via the base
+        // address.
+        mlir::Value baseAddr = mapInfo->entity.getBase();
+        if (mlir::isa<fir::BaseBoxType>(baseAddr.getType()))
+          baseAddr = fir::BoxAddrOp::create(builder, loc, baseAddr);
----------------
MattPD wrote:

For a descriptor array under `target enter/exit data`, the iterator lowering maps only the array data, unlike the non-iterator baseline. For `integer, allocatable :: a(:)` with `map(iterator(i=1:n), to: a(i))`, the iterator path emits one data-only map:

```mlir
%17 = fir.box_addr %10 : (!fir.box<!fir.heap<!fir.array<?xi32>>>) -> !fir.heap<!fir.array<?xi32>>
%18 = omp.map.info var_ptr(%17 : !fir.heap<!fir.array<?xi32>>, i32) map_clauses(to) ... -> !llvm.ptr {name = ""}
omp.target_enter_data map_iterated(%8 ...)
```

The non-iterator baseline `map(to: a(1:2))` instead emits a descriptor parent, an attach map, and a base-pointer member:

```mlir
%12 = omp.map.info var_ptr(%1#1 ...) map_clauses(to) var_ptr_ptr(%11 ...) ...                         // base-pointer member
%13 = omp.map.info var_ptr(%1#1 ...) map_clauses(always, to) members(%12 : [0] ...) {name = "a(1:2)"} // descriptor parent
%14 = omp.map.info var_ptr(%1#1 ...) map_clauses(attach, ref_ptr, ref_ptee) var_ptr_ptr(%11 ...) {name = "a(1:2)"} // attach
omp.target_enter_data map_entries(%13, %14, %12 ...)
```

For pure data-motion directives, mapping only the data may be intended. The `map_iterated` translation is deferred to #199101, so it cannot affect runtime here. Is the data-only shape the intended contract for iterator maps of descriptor arrays, to be handled and device-tested in #199101?

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