[llvm-branch-commits] [flang] [mlir] [mlir][flang][OpenMP] Select depend and affinity iterators per locator (PR #227454)

[via llvm-branch-commits]

================
@@ -2899,11 +2899,18 @@ 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));
+      // Use a direction-aware count so an empty range contributes no entries.
+      // Widen before subtracting bounds: valid i64 endpoints can have a span
+      // that does not fit in signed i64.
+      llvm::Type *countTy = builder.getIntNTy(65);
----------------
MattPD wrote:

The MLIR example is fixed, but frontend narrowing now loses required dependences for this Fortran range:

```fortran
subroutine s(a)
  integer :: a(3)
  integer(16) :: lb, ub
  lb = 9223372036854775807_16
  ub = 9223372036854775809_16
  !$omp task depend(iterator(integer(16)::i=lb:ub), in:a(i-lb+1))
  !$omp end task
end
```

With `flang -fc1 -emit-llvm -O2 -fopenmp -fopenmp-version=52 -o - repro.f90`, the baseline emits three entries at `a(1)`, `a(2)`, and `a(3)`. The patched compiler emits zero. The three iterator values and the final increment are representable in `integer(16)`.

`lowerIteratorRange` still converts the bounds to `index`. The new direction check consequently sees a converted upper bound below the lower bound. Do you think you could retain the iterator's width through frontend bound, step, and region-argument construction as well?

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