Conversation
This is separated from #1281 to keep the PR small.
This is separated from #1281 to keep the PR small.
This is separated from #1281 to keep the PR small.
|
!build |
|
!build |
1 similar comment
|
!build |
This is separated from #1281 to keep the PR small.
|
Can this be split to two PRs, one for slices and another for reshapes? |
Sure. Found more problems though: apparently, the pointwise scheduler changes the output contiguity, breaking |
This is the apparent root cause: Line 1210 in 2d2a2a4 |
|
!build |
| } | ||
|
|
||
| // Scan through the allocation domain in minor-to-major order. If an | ||
| // IterDomain is sliced, the next non-broadcast IterDomain has to be marked |
There was a problem hiding this comment.
Is it possible to encounter a trivial SliceOp here? Where both left and right pad are zero? We should treat such case as the identity on that axis.
There was a problem hiding this comment.
Agree with Jacob. i.e. if we later decide to merge a trivially sliced dimension, we should recognize that and merge it back I guess.
But this can only be done opportunistically (only handle static trivial slice), I guess?! Since padding value can be a runtime value and we can't know for sure that it'll be a trivial slice or not until runtime.
There was a problem hiding this comment.
Is it possible to encounter a trivial SliceOp here? Where both left and right pad are zero? We should treat such case as the identity on that axis.
Line 792 in 2e2f3c7
Line 772 in 2e2f3c7
| out_layout.contiguity[i] = in_layout.contiguity[i]; | ||
| } | ||
|
|
||
| std::vector<Expr*> dependencies = DependencyCheck::getAllExprsBetween( |
There was a problem hiding this comment.
You can use StmtSort::getExprsBetween.
jacobhinkle
left a comment
There was a problem hiding this comment.
This PR looks good to me. Note that a slice can also be achieved with a PadOp. In that case, we cannot assume the pads are negative, and if any are positive we must materialize. Otherwise we can alias just as you've done here.
Is the reverse also true? I.e. a |
|
Should I review this one or wait until we split the PR into two per Naoya's suggestion? |
Already split |
| } | ||
|
|
||
| // Scan through the allocation domain in minor-to-major order. If an | ||
| // IterDomain is sliced, the next non-broadcast IterDomain has to be marked |
There was a problem hiding this comment.
Agree with Jacob. i.e. if we later decide to merge a trivially sliced dimension, we should recognize that and merge it back I guess.
But this can only be done opportunistically (only handle static trivial slice), I guess?! Since padding value can be a runtime value and we can't know for sure that it'll be a trivial slice or not until runtime.
No. Slice will never pad. See #460. |
61ef979 to
9e8cdd2
Compare
Left a note on |
4dc97e8 to
3e8c98f
Compare
Partially taken from #1281 to keep that PR small.
With slices, the pointer address might not be the same. PointerArithmetic is more accurate.
|
!build |
This reverts commit eef9db8.
This reverts commit 64a21ae.
This reverts commit 64a21ae.
No description provided.