I have a Halide pipeline on which I would like to try a couple of schedules. I'd like to do this by creating a separate file with the optimizations and then apply these to a given Func at runtime so I can automatically try them out to find the fastest.
I started writing my own function to do this, but for some optimizations such as compute_at this is getting rather complex. compute_at Takes a Func as first argument. Is there a way to access the Funcs in the pipeline without me having to keep a list of all functions and then passing this list to my function? I understand this might not at all be possible due to the way Halide is designed.
The IR can be walked to find Func's by name, or they can be stashed in a map for future reference. However this simply solves the low-level mechanism of naming. The issue is that the names themselves become part of the interface and scheduling remains specific to the low-level details of the code structure. (And the Var names are also needed, those these are usually easier to work with.)
At this point it becomes better to define a struct that contains the information the scheduling routine(s) can depend on and fill it in when building the IR. Then this struct can be passed to C++ functions to do scheduling. Common parts of scheduling can be abstracted out, etc. For complex cases we often use C++ loops and such to apply a chunk of scheduling to a set of Funcs even if all of the IR is built and scheduled in a single routine. In effect the struct encapsulates the interface between the algorithm and schedule.
We are working on better serialization and deserialization which provides another slicing on this if you want to write schedules into files separate from the C++ code. But once again, you still have to know the details of the code being scheduled in order for it to work. It also involves either using a serialization format as the programming language for scheduling or developing another language.
The most promising avenue at present is automated heuristic scheduling. There is a paper by Ravi Teja Mullapudi et al being presented at SIGGRAPH.