wrongtest commented on PR #11287:
URL: https://github.com/apache/tvm/pull/11287#issuecomment-1135062872
> usage of `DetectIterMapPadded` in our analysis
Try merge `DetectIterMapPadded` and `DetectIterMap` into the same interface,
and replace option `require_bijective` with a new enum `IterMapLevel` with
three alternatives:
- Bijective
for original behavior on `require_bijective=true`
- Surjective
for original behavior on `require_bijective=false`
- Injective
for behavior of `DetectIterMapPadded`
The https://github.com/apache/tvm/pull/11235 brings great way to analyze
iteration form like `(x + 7) // 16` with padding. The surjective checking of
`DetectIterMap` is used many where (like region cover check after schedule
step), however, it can not leverage this analysis now, it is checked to take no
padding predicate.
I think actually, as an example, though `(x + 7) // 16` is rewritten into a
"padded" iteration form, we could still prove the mapping is surjective, since
the left and right padding is no more than the largest divisor by how we pad
it. If we extent `CheckMapping` rules carefully, we may be able to distinguish
that
- `(x + 7) // 16` -> surjective
- this is the access index form in my original failed case
- `(x + 7) % 16` -> surjective [0, 16) if x's extent is larger than 16
- (`(x + 7) // 16`, `(x + 7) % 16`) -> non-surjective
So from my perspective it would be great if we have a uniform interface and
share same padding based analysis. Ideally `padding_predicate` is not affected
for IndexMap functionalities, and it should not introduce false positives in
bijective/surjective checking.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@tvm.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
