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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/39#issuecomment-959796056
