Following a video chat with @csullivan, documenting some of the key points of the conversation.
* Setting the physical layout in a TE-based schedule has two roles. One is the rewrite the buffer itself, and the other is to define the order of iteration when writing to the buffer. In the latter use case, the schedule should have access to the physical axes for use in the schedule. * Setting the physical layout is roughly equivalent to using an inlined `te.compute` to define a re-shaped tensor. However, using `te.compute` requires the compute definition to change, whereas `set_physical_layout` is entirely contained in the schedule. * For a given tensor, either the physical axes or the logical axes may be used in scheduling, not both. We were unable to think of use-cases where you would want to change the physical layout, but still maintain the loop-order of the logical layout. One idea that came of this conversation was to have `set_physical_layout` act similar to `cache_read` and `cache_write`, which introduce a new stage. * If a physical layout is defined for a cache stage, then the generated code should perform the layout transformation as part of generating that cache. -- 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-938057599
