You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To figure out if we can index some dimensions contiguously we look at the operations that created a particular IterDomain. For example if we have:
tv0 = 3DContigTensor
tv0->merge(1)
tv0->merge(0)
We can look back at the merges in order, map them back to the root domain, and figure out they're both contiguous because they operate on consecutive root domains that are also contiguous. This approach works well no matter the order for merge operations:
tv0 = 3DContigTensor
tv0->merge(1)
tv0->merge(0)
However, this approach can not under split operations, because it's hard to track the order in the split, i.e.
This still results in a fully contiguous access, but it's hard to track the ordering of that split.
We could track the ordering of these operations ignoring reduction to do this analysis, or we could create a "get inputs of" function that would return inputs in an order preserving manner so get inputs of the final domain would return the root domains in their correct ordering of the domain.
The nice thing about doing this is that a merge could appear reversible (from the perspective of indexing).
The text was updated successfully, but these errors were encountered:
To figure out if we can index some dimensions contiguously we look at the operations that created a particular IterDomain. For example if we have:
We can look back at the merges in order, map them back to the root domain, and figure out they're both contiguous because they operate on consecutive root domains that are also contiguous. This approach works well no matter the order for merge operations:
However, this approach can not under split operations, because it's hard to track the order in the split, i.e.
This still results in a fully contiguous access, but it's hard to track the ordering of that split.
We could track the ordering of these operations ignoring reduction to do this analysis, or we could create a "get inputs of" function that would return inputs in an order preserving manner so get inputs of the final domain would return the root domains in their correct ordering of the domain.
The nice thing about doing this is that a merge could appear reversible (from the perspective of indexing).
The text was updated successfully, but these errors were encountered: