================
@@ -156,9 +156,9 @@ extern "C" void body(...) {}
// IR-EMPTY:
// IR-NEXT: [[FOR_INC]]:
// IR-NEXT: %[[TMP34:.+]] = load i32, ptr %[[DOTTILE_0_IV_I]], align 4
-// IR-NEXT: %[[INC:.+]] = add nsw i32 %[[TMP34]], 1
+// IR-NEXT: %[[INC:.+]] = add i32 %[[TMP34]], 1
----------------
Meinersbur wrote:
This is due to the change of using the type of `LoopHelper.NumIterations` (an
unsigned integer) as the new loop's induction variable (instead of the original
loop's iteration variable type). In iterator-based loops that type would be
incompatible with `LoopHelper.NumIterations` which remains an integer.
Even if the original loop variable is a signed integer (it could be a
(`std::iota_view`)[https://en.cppreference.com/w/cpp/ranges/iota_view] over the
same range), using and unsigned type is more correct as long as we start
counting at 0. For instance, the loop
```
#pragma omp tile sizes(2)
for (int i = INT_MIN; i < INT_MAX; ++i)
```
would overflow the `nsw` flag.
The "most correct" fix would be to add the `nuw` flag. Unfortunately there is
no AST expression we could create that would make CodeGen generate one.
Alternatively, I could make generated loops start counting at `INT_MIN`.
https://github.com/llvm/llvm-project/pull/91459
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
