kparzysz-quic commented on PR #18:
URL: https://github.com/apache/tvm-rfcs/pull/18#issuecomment-1175064079

   > 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...
   


-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to