Thanks for the RFC! I do agree that it would be great to create an additional path to improve the flexibility, especially now we have auto_scheduler to schedule a TE graph from scratch (cc @merrymercy).
Meanwhile, I think tightly-coupled the selection of schedule and compute is intentional because an advance schedule needs a specialized compute (e.g., NCHWc, Winograd), and that’s why Relay op strategy was design in this way to select both compute and schedule at one place (cc @haichen). Could you elaborate a bit more about this part? IIUC from your WIP PR, it seems you need to call lower_call twice (one in TETranslator and another in ScheduleGetter). In this case, seems like you still select the schedule in TETranslator (https://github.com/apache/incubator-tvm/blob/ed4cedce02a6ff608626bc61dfff6fc6f98004c9/src/relay/backend/compile_engine.cc#L259), and you perform the same process when visiting the primiary funciton (https://github.com/apache/incubator-tvm/blob/ed4cedce02a6ff608626bc61dfff6fc6f98004c9/src/relay/backend/compile_engine.cc#L266)?
A follow-up question is that since you still call lower_call in TETranslator, Relay op strategy is still required to register the mapping from Relay ops to TE computes. Accordingly, the logic of selecting a compute is still based on the schedule quality (or plevel by default), which seems not improve the flexibility but just lets you apply another schedule to the select compute. Although it seems to me that this is the main purpose of this RFC, we should have another mechanism to determine computes in TETranslator; otherwise it sounds weird to select a compute by referring to the quality of its corresponding TOPI schedule which you won’t apply.
Also cc @zhiics