[RFC] [Hybrid Script] IR Dump

[were]

Because HalideIR now can be fully mapped to Hybrid Script and vice versa, I want to support IR dump to Hybrid Script so that users can play with IR body directly.

Which one do you guys prefer?

1. mode=tvm.build(sch, args, target='hybrid'); mode.save('a.py')
2. tvm.hybrid.emit(stmt, file_name)

I personally like the 2nd one better. I do not want touch too much build module thing. I want to make it as standalone as possible.

@tqchen @eqy @yzhliu @kevinthesun @yidawang

[xqdan]

What's purpose of IR dump for, debugging or some transformation?

[were]

@xqdan You can dump HalideIR to this script format and play with the IR directly.
Isn't it useful, when there are some bugs (and you just need a quick fix) or some schedule not supported yet?

[junrushao]

🎉Glad to see the IR dump thing in Hybrid scripts! This enables direct manipulation of Halide IR in text mode. Very meaningful work!

[junrushao]

Slightly off the topic, I would say it could be better if we explicitly claim which syntactic sugar of Python is supported, and which is not. You might be interested in writing it in accordance with Python's official AST document, Green Tree Snake. @were @kevinthesun

[kevinthesun]

Personally I prefer the second method, to keep this under hybrid script. @junrushao1994 It's helpful to have such a doc for developer to check whether their code syntax is supported. We can start with adding something we don't think will support in the long term, such as break/continue.

[xqdan]

@were yes, looks cool, can we do this for each pass?

[junrushao]

@kevinthesun complicated jumps like break/continue is not possible in Halide, because it break all analysis conducted. Hence, it is not quite meaningful to add it to the hybrid script. Do you have specific use cases for break/continue?

[kevinthesun]

@junrushao1994 I don't think we need to support those.

[were]

@xqdan I do not want to aggressively modify the codegen backend.
I believe dumping each pass requires this.
I just want to dump the normalized schedule, the highest level (maybe with canonical simplification).
Also, which one do you prefer?

[xqdan]

@were I see. 2nd is better for me.

[xqdan]

@kevinthesun totally agree with @were and @junrushao1994, to support continue and break, the whole TVM stack would need lots of stuff in traditional compilers, which will make things complicated. if any operators don't fit into abstraction of TVM, maybe it's better to support it with low level languages, such as CUDA c. Also it's interesting to see what's the real requirements look like.