IR serialization and deserialization #291
Labels
dialect
general dialect framework related issues
enhancement
New feature or request
interpreter
interpreter related issues
IR node
issue related to IR data structure
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.gfoo
will be an actualir.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-likeModuleOp
, however, because our scope is more about kernel function this can be more special - we can define a module dialect whereModuleOp
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.
The text was updated successfully, but these errors were encountered: