Description
We are still missing IR serialization/deserialization. The main obstable here is because we mainly consider a single kernel function, by default the IR of a kernel function is a func.Function or something similar. As a result this will not store the entire call chain in a module but instead embedded in the IR as a Python object, e.g
func.invoke foo(%a, %b)
foo will be an actual ir.Method object. For serialization and deserialization, and possibly codegen to an actual static compiled language (e.g LLVM) we need to dump the functions in the call chain as well and link them as modules. This means instead of a single function, we should have an mlir-like ModuleOp, however, because our scope is more about kernel function this can be more special - we can define a module dialect where ModuleOp has a callable region which is the region inside the entry function.
This leads to another change is to let dialect group own an interpreter so that interpreter can load module/function definitions at construction time, so that we can load the symbol table correctly.