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

[via flang-commits]

================
@@ -337,6 +337,50 @@ 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. Iterator maps represent selected data directly and do not
+        // include the descriptor parent or attachment entries used by ordinary
+        // descriptor maps.
+        mlir::Value baseAddr = mapInfo->entity.getBase();
+        if (mlir::isa<fir::BaseBoxType>(baseAddr.getType()))
+          baseAddr = fir::BoxAddrOp::create(builder, loc, baseAddr);
+        mlir::FlatSymbolRefAttr mapperId =
+            resolveMapperId(converter, loc, object, mapperIdName, mapTypeBits,
+                            directive, /*hasParentObj=*/false);
+        mlir::omp::MapInfoOp mapOp = utils::openmp::createMapInfoOp(
----------------
MattPD wrote:

Taking `fir.box_addr` here drops the descriptor, but the `ref_*` and `attach` flag bits are still set on the resulting map. For `map(ref_ptr, iterator(i=1:n), to: a(i))` on `integer, pointer :: a(:)`, the emitted entry uses the pointee data as `var_ptr`. It has neither `var_ptr_ptr` nor an attach entry, while the non-iterator spelling emits the descriptor entry plus an attach entry. `ref_ptr` requests mapping the pointer, but this IR maps the pointee. All six spellings are accepted with no diagnostic: `ref_ptr`, `ref_ptee`, `ref_ptr_ptee`, and `attach` with `always`, `never`, or `auto`. This is new-path behaviour rather than a regression, and it reaches `target enter data`, `target exit data`, and `target data`.

Would rejecting these modifiers with a not-yet-implemented diagnostic, alongside the existing ones for optional and derived-type-member locators, be reasonable until the descriptor entries can be carried through?

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