================
@@ -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
_______________________________________________
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
