> In general, a PrimFunc's interface could only be changed when calls into the > PrimFunc are also modified to remain compatible.
Agreed, that is what I originally intended to say > Is there a better term than "scheduling primitive" to describe layout > transformations that impact input/output buffers? I think the difference is > between context-independent transformations that may be performed on a > PrimFunc without changing, as opposed to context-dependent transformations > that may only be performed as part of a graph-level transformation. There are a few things, one approach would be to allow schedule primitive to modify multiple functions(including callers), we might need this for more complicated cases. In our particular example, however, the idea is that the schedule primitive do not modify the input/output buffer, but introduce preproc and postproc stages with clear hint that they should be lifted out (aka we are doing the same thing in two steps) -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/77#issuecomment-1165724403 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/77/c1165724...@github.com>
