> Our design principle at TIR level ideally we start with one instance of > possibility, then use probabilistic space of meta-schedule to represent > multiple choices.
For this, would the layout re-flowing occur periodically during optimization? Otherwise, including transformations in the performance benchmarking of candidates would unfairly penalize candidates that add a transformation step, while excluding transformations would unfairly bias toward transformations, even when sequential operators require separate layout transformations. Representing different options as different allowed steps in a search space makes sense to me, so long as the candidates are reasonably exposed to optimizer. > 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) I think I understand. That would effectively be treating the preproc/postproc stages as separate function bodies, but ones which happen to exist within the same TIR PrimFunc for ease of use. With this representation, I think the biggest part would be determining when to fix a previously free parameter, in order to expose it as an assumption to another TIR PrimFunc. Maybe in the "Step 2: Reflowing of Layouts", this isn't used to cancel any statements out, but instead to create a dynamic performance penalty if an assertion is no longer held, with the performance penalty equal to the time required to do the transformation. > As a quick intermediate middle ground. For most intermediate stage(really > like add or exp), we would ideally not insert any layout decisions and allow > decisions from other key ops(conv and matmul) to backprop their decision to > them. I'd agree, though would phrase it somewhat differently. The element-wise operations impose a constraint such that input and output layouts, that the input and output have identical layouts. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/77#issuecomment-1165889831 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/77/c1165889...@github.com>
