Thanks for the comments.
> May I ask how the graph ends up with a `nn.conv2d + nn.relu + nn.conv2d + > nn.relu` ? Is the graph going through a BYOC kind of partitioning (sorry if > the question is naive)? There is nothing to do with BYOC. My point is that Ansor opens the door to subgraph-level scheduling, but the current Relay fusion mechanism limits a task to a subgraph with a single reduce op. With this RFC, people can investigate fusion strategies without any limitations. For example, one of our talk in the upcoming TVM conference (title: Graph-Level Scheduling Optimization with Polyhedral Analysis for Tensor Programs) will introduce our initial efforts on investigating the opportunities of fusing reduce ops. This kind of researches will be hard to proceed without this RFC. > As for S1 vs S2, could we do both? Use an heuristic like “ignore the task > without any call node” and then let the task scheduler judge if it needs to > spend time on the task? Yes we could. This issue is actually about the flexibility vs. user experience. If we filter tasks during extraction process, users will see fewer tasks (and may feel more comfortable), but advance users may want to see all tasks to perform other things such as improving the task scheduler, etc. --- [Visit Topic](https://discuss.tvm.apache.org/t/rfc-a-general-task-extraction-mechanism-for-auto-scheduler/8444/3) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/dfb458c2c796a3e0936fdbb165c337772de6f2860f8a0402f23c113dce7ab993).