I do believe using python AST is useful, as we can view it(and build features around) in several ways:
- V0: Faithful text format for the TIR. In this case, there is some value to embed things in python:
- User can directly write AST rather than strings in python to construct these IRs.
- The code works with the python syntax highlighter.
- V1: Enhanced syntax sugars: After we achieved the goal of V0, we can then bring some enhanced syntax sugars that are more concise. The code below shows an hypothetical example:
@tvm.hybrid.script
def myfunc(a, b):
A = tir.buffer_bind(a, (100, 100), "float32")
B = tir.buffer_bind(a, (100, 100), "float32")
for i, j in grid(100, 100):
B[i, j] = A[i, j] + 1
Notably, the grid
construct is a sugar that expands to two for loops, and we might omit other things like realize etc.
The syntax of V1 is intended to make things easy for developers to concisely construct TIRs. There is a fixed rule to lower these sugars to a well-defined TIR program. Importantly, V1 needs to be consistent with V0 – any V0 program is also a valid V1 program. We can also developer smart printers to potentially print out sugared versions which are more concise.
- V2: potential meta programming. We might want to develop meta-programming models to construct a collection of hybrid scripts, and use of some the python features for macro expansion.
So to sum up, while the text repr is one of the goals of the hybrid script and serves as an anchor for the design. Our ultimate goal should be building a single, unified infrastructure that serves as:
- An text repr for the IR.
- Sugars(DSLs) to construct the IR and compute themselves
- Potential user interface for specifying the program.