[Runtime][PipelineExecutor] Move graph_split into relay testing.

[huajsj]

RFC: https://github.com/apache/tvm-rfcs/blob/main/rfcs/0014-pipeline-executor.md
Issue: #8596

Currently the helper function of pipeline executor unit test like 'graph_slit' stay in the unit test file, and such function not directly related the testing logic.

moving such helper function into tvm.relay.testing folder.

[masahi]

I think it's better to keep this function in a pipeline executor test file. Things under relay.testing are supposed to be generally useful. And you need to add documentation and improve code quality if you want others to use this code.

[huajsj]

I think it's better to keep this function in a pipeline executor test file. Things under relay.testing are supposed to be generally useful. And you need to add documentation and improve code quality if you want others to use this code.

@masahi, thanks for the follow up, I do see some requirement for a solution to handle graph splitting for example in this discussion(https://discuss.tvm.apache.org/t/relay-generate-sub-graphs-from-existing-graph/11594), as a short term solution, this graph_split function can serve as an example and a python level support, I think that should be useful to separate this function into 'relay.testing' to let others use it, for sure I will add documentation and polish the code, please kindly let me know how you think.

[rebel-shshin]

Hi, @huajsj. Thanks for your contribution on TVM. I have a simple question for the graph_split func. In many real use case, the relay function can be existed in the module['main'] (i.e. OP fusion or BYOC cases). How can we handle these cases to split the graph?

[huajsj]

Hi, @huajsj. Thanks for your contribution on TVM. I have a simple question for the graph_split func. In many real use case, the relay function can be existed in the module['main'] (i.e. OP fusion or BYOC cases). How can we handle these cases to split the graph?

As line 116 shown, graph_split only parse the top level function and treat the internal "relay.function" as a "relay.expr.let", that means the operator inside the function will not get involved by the graph split, and not impact the result. then either fuse or byoc logic will not get broken.
And if there is a requirement to split the internal function of like BYOC, then the order should be that do the graph split first then do the BYOC annotation.

[rebel-shshin]

Thanks.

Hi, @huajsj. Thanks for your contribution on TVM. I have a simple question for the graph_split func. In many real use case, the relay function can be existed in the module['main'] (i.e. OP fusion or BYOC cases). How can we handle these cases to split the graph?

As line 116 shown, graph_split only parse the top level function and treat the internal "relay.function" as a "relay.expr.let", that means the operator inside the function will not get involved by the graph split, and not impact the result. then either fuse or byoc logic will not get broken. And if there is a requirement to split the internal function of like BYOC, then the order should be that do the graph split first then do the BYOC annotation.

Thanks :-) 👍

[huajsj]

@masahi , the document adding and code polish already done, please take a look.

[masahi]

I think this way of specifying only works for a graph that is a linear-chain. Being limited is ok for a one-off function in a test code, but for more general utilities I think we want a better implementation. So I still don't support moving this function under relay/testing.

[huajsj]

sure, I will close this PR and work for a more complete solution.