> 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 perf
> 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/outpu
> Talking about “constraints”, it is also useful to talk about categories of
> them, roughly we can divide them into three categories.
I like this breakdown, and agree. In this categorization, what I've been
calling "constraints" would be "assumptions". Double-checking in `builtin.h`,
it look
