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

[via flang-commits]

================
@@ -2811,11 +2811,10 @@ class IteratorInfo {
       upperBounds[d] = ub;
       steps[d] = st;
 
-      // trips = ((ub - lb) / step) + 1  (inclusive ub, assume positive step)
-      llvm::Value *diff = builder.CreateSub(ub, lb);
-      llvm::Value *div = builder.CreateSDiv(diff, st);
-      trips[d] = builder.CreateAdd(
-          div, llvm::ConstantInt::get(builder.getInt64Ty(), 1));
+      llvm::Value *tripCount = ompBuilder.calculateCanonicalLoopTripCount(
----------------
MattPD wrote:

Computing the trip count in the range's own type regresses a case that the parent commit 82004b0 handled. Save the following as `range.mlir` and run `mlir-translate --mlir-to-llvmir range.mlir`:

```mlir
llvm.func @full_i8_range(%addr: !llvm.ptr) {
  %lo = llvm.mlir.constant(-128 : i8) : i8
  %hi = llvm.mlir.constant(127 : i8) : i8
  %step = llvm.mlir.constant(1 : i8) : i8
  %it = omp.iterator(%iv: i8) = (%lo to %hi step %step) {
    omp.yield(%addr : !llvm.ptr)
  } inclusive -> !omp.iterated<!llvm.ptr>
  omp.taskwait depend(taskdependin -> %it : !omp.iterated<!llvm.ptr>)
  llvm.return
}
```

At 82004b0 the loop bound and the count passed to `__kmpc_omp_taskwait_deps_51` are 256. At dcc6653 both are 0. `calculateCanonicalLoopTripCount` adds one in `i8`, so 256 wraps before the `zext` to `i64`. The affinity path shows the same change from 256 to 0.

The same helper marks the span `sub nsw`. For a Fortran range with dynamic bounds, 82004b0 emits a wrapping `sub` instead.

A conforming `integer(8)` range can have a span above `INT64_MAX`. Take `iterator(integer(8) :: i = 4611686018427387904_8 : -9223372036854775807_8 : -4611686018427387904_8)`. The expression `i + step` is representable at each of the range's three values: 2^62, 0, and -2^62. With constant bounds the folded subtraction wraps, so dcc6653 emits the correct count of 3. At 82004b0 the count is 0. With the same values in dummy arguments the `sub nsw` is poison at run time.

Would computing the count in a type one bit wider than the range type keep the source-width induction variable and avoid both the wrap and the `nsw` poison? Only the result would need extending to `i64`. `omp_task_depend_iterator_dynamic` in `openmp-iterator.mlir` currently asserts the `sub nsw`.

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