> Hi~ here are my two questions :) cc @kparzysz-quic > What is the different between > > * `sch[C].vectorize(v, vector_length=32)` and > * `vo, vi = sch[C].split(v, 32)` then `sch[C].vectorize(vi)` > > It seems that we could also choose to properly lower the split's > predicate to reach the same goal as proposed below. For example, weapons > introduced in RFC [[RFC] Buffer Layout Padding > #77](https://github.com/apache/tvm-rfcs/pull/77) may help?
Yes. The padding proposed in the padding RFC could be utilized for this. What I wrote didn't take that into account. > Our team also get confused on how to represent predicated ld/st, when > several months ago the upstream upgrade `T.load`/`T.store` (who have 1D > predicate field) to `BufferLoad`/`BufferStore`. Now since > `BufferLoad`/`BufferStore` are multi-dimensional, the predicate seems to also > be multi-dimensional field? I suppose it could be multi-dimensional, but effectively it would be the conjunction of all the per-dimension predicates. > Another concern is whether embedding predicate into > `BufferLoad`/`BufferStore` increase the complexity (or break) buffer region > related analysis in existing implementations. Could we leverage > `T.select(pred, A[...], undef)` to represent `A[..., pred]`, or just match > the predicated memory access pattern like `if (pred) C[...] = ...`? The region analysis could simply ignore the predicate (assume that it's true for all lanes). This is presumably what would happen with the `select`. For stores, we'd have to have an `if` statement that accepts a vector of booleans to properly emulate the store predicate. Adding a predicate to `BufferLoadNode` and `BufferStoreNode` is a feature that could have some value on its own, so perhaps it deserves its own RFC... -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/18#issuecomment-1175064079 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/18/c1175064...@github.com>
