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

[llvmlistbot at llvm.org]

================
@@ -533,6 +533,34 @@ static LogicalResult checkImplementationStatus(Operation &op) {
       result = todo("map/motion clause with iterator modifier");
   };
 
+  // `declare_mapper.info` supports the simple case emitted by Flang's
+  // lowering: a single-dimension iterator whose body directly yields one
+  // bounds-free, member-free omp.map.info. Anything else still falls back to
+  // the generic (not yet implemented) diagnostic above.
+  auto checkDeclareMapperMap = [&todo](omp::DeclareMapperInfoOp op,
+                                       LogicalResult &result) {
+    for (Value iterVal : op.getMapIterated()) {
+      auto itersOp = iterVal.getDefiningOp<omp::IteratorOp>();
+      bool supported = itersOp && itersOp.getLoopLowerBounds().size() == 1;
+      if (supported) {
+        auto yieldOp =
----------------
chichunchen wrote:

Could we use the iterator region’s unique yield rather than assuming its first block ends in `omp.yield`, both here and in mapper emission?

A scalar subscript can introduce multiple blocks during lowering. For example:

```fortran
subroutine f(x)
  type :: t
    integer :: a(20)
    character(10) :: text
  end type
  type(t) :: x

  !$omp declare mapper(m: t :: v) &
  !$omp& map(iterator(i=1:2): v%a(i+len_trim(v%text)))
  !$omp target data map(mapper(m): x)
  !$omp end target data
end
```

With offload code generation enabled, this passes HLFIR lowering but fails LLVM emission with the generic “Unhandled clause map/motion clause with iterator modifier” diagnostic. Lowering `LEN_TRIM` introduces control flow inside the iterator, so its yield is no longer in the first block.

#227454 already added multi-block iterator support to the shared conversion path. Could we use that support here, locating the unique yield in both the implementation-status check and mapper emission?

Please also add a Fortran-to-LLVM regression test for a locator like this. An HLFIR-only test would miss the control flow introduced by later lowering passes.

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