History

[MLIR][SCF] Fix loopUnrollByFactor for unsigned loops with narrow integer types (#189001 )

`loopUnrollByFactor` used `getConstantIntValue()` to read loop bounds,
which sign-extends the constant to `int64_t`. For unsigned `scf.for`
loops with narrow integer types (e.g. i1, i2, i3), this produces wrong
results: a bound such as `1 : i1` has `getSExtValue() == -1` but should
be treated as `1` (unsigned).

Two bugs were introduced by this:

1. **Wrong epilogue detection**: the comparison `upperBoundUnrolledCst <
ubCst` used signed int64, so e.g. `0 < -1` (where ubCst is the
sign-extended i1 value 1) evaluated to false, suppressing the epilogue
that should execute the remaining iterations.

2. **Zero step after overflow**: when `tripCountEvenMultiple == 0` (all
iterations go to the epilogue), `stepUnrolledCst = stepCst *
unrollFactor` can overflow the bound type's bitwidth and wrap to 0. A
zero step causes `constantTripCount` to return `nullopt`, preventing the
zero-trip main loop from being elided.

Fix:
- Use zero-extension (`getZExtValue`) instead of sign-extension when
reading bounds for unsigned loops.
- When `tripCountEvenMultiple == 0`, keep the original step for the main
loop to avoid the zero-step issue (the step value is irrelevant for a
zero-trip loop anyway).

Fixes #163743

Assisted-by: Claude Code

2026-03-27 18:36:51 +01:00

benchmark/python

…

cmake/modules

[mlir-python] Fix duplicate EnumAttr builder registration across dialects. (#187191 )

2026-03-19 21:02:23 -07:00

docs

[mlir][ods] Document and test DefaultValuedProp elision in prop-dict format (#189045 )

2026-03-27 16:31:09 +00:00

examples

[MLIR] Add missing dialects to C API (#82190 )

2026-01-07 12:51:33 -08:00