The schedule folder has proper schedules that call transforms, including HW specific ones. But it also has general infrastructure, example builder.py, func.py and debug.py. The transform folder has a similar divide, with schedules like cleanup.py but also core infra like foreach and matchers.py. The main separation between them is that files in schedule return an ir.Module that contains a schedule, while files in transform receive intermediate state (structured objects) and just complement the existing schedule.
While the distinction is fine, this is problematic in some ways:
- Repetition. Packing schedule calls a pass, while packing transform calls some upstream transforms. Same for vectorization.
- Shallow wrapping. Hoisting schedule calls hoisting transform that just calls an upstream transform and a cleanup. Same for tiling.
- It's hard to generalize the appending semantics on the callee side, when you can't guarantee the state which the schedule is on the caller side.
As we move to compose schedules with passes and descriptors, we don't need to append transforms to a schedule this way, we can just create a new sub-schedule and append it to an existing pipeline. For that, the logic in the schedule folder is more than sufficient.
This issue proposes two things:
- Move the sub-schedules in
transform to their callers in schedule and use the latter in the existing examples and tools instead of composing them in existing pipelines.
- Keep only core infrastructure in
transform like foreach, match_op, schedule_boilerplate, create_schedule, and create_named_sequence.
The transform folder should not need a HW-specific sub-folder.
The
schedulefolder has proper schedules that call transforms, including HW specific ones. But it also has general infrastructure, examplebuilder.py,func.pyanddebug.py. Thetransformfolder has a similar divide, with schedules likecleanup.pybut also core infra likeforeachandmatchers.py. The main separation between them is that files inschedulereturn anir.Modulethat contains a schedule, while files intransformreceive intermediate state (structured objects) and just complement the existing schedule.While the distinction is fine, this is problematic in some ways:
As we move to compose schedules with passes and descriptors, we don't need to append transforms to a schedule this way, we can just create a new sub-schedule and append it to an existing pipeline. For that, the logic in the
schedulefolder is more than sufficient.This issue proposes two things:
transformto their callers inscheduleand use the latter in the existing examples and tools instead of composing them in existing pipelines.transformlikeforeach,match_op,schedule_boilerplate,create_schedule, andcreate_named_sequence.The
transformfolder should not need a HW-specific sub-folder.