vinx13 commented on pull request #39: URL: https://github.com/apache/tvm-rfcs/pull/39#issuecomment-959796056
Thanks for adding the discussion points. I understand the difficulty implementing it as eager transform in TE, mainly because most other schedule primitives were not done eagerly as in TIR. So adding a rewrite pass for `BufferTransform` makes sense to me. > Should BufferTransform apply only to its body, or apply to the entire graph it is contained in? > Option 2 is preferred. When adding `BufferTransform` as a statement, we will need to make sure the semantic is clear. In the provided example, adding `BufferTransform` immediately after `Allocate` has clear meaning of Option2 that it should be applies to everywhere the buffer appeared. What if `BufferTransform` appear at the middle, e.g. `Allocate -> some buffer accesses -> BufferTransform -> some another buffer accesses`. Since `Option2` suggests the transform is global, shall we consider `BufferTransform` being part of function attribute? > When the transformation is performed, would that include fusing axes together? My thoughts on TIR and `FlattenBuffer` is that `buffer_transform` will return unfused axes, and `FlattenBuffer` should decide how to fuse them according to buffer scope or other auxiliary information. This implies separation between buffer transform and the underlying physical layout requirement (e.g. 1-D by default in most cases). I think the idea here is close to T2. Using `AXIS_SEPARATOR` is also a potential way to specify the behavior of `FlattenBuffer`. On the other hand, we might also need deliberation on whether buffer transform and flattening to physical buffer should be coupled together. -- 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]
