Historically we have relied on numba execution engine (MCJIT - based) for executing our MLIR code. The main issue here was that Numba uses different llvm version (much older than ours), to handle this we are serializing lvm module to bitcode on our side using our llvm and deserialize it on numba side using theirs. This approach was working reasonably well up until now (although we already have a hack on our side to remove unsupported attributes), but it is going to break as upstream llvm is fully switching to opaque pointers and thus breaking bitcode compatibility.
Better approach would be to have full execution engine on our side and use it compile code on our side. After that we can pass function pointer to the compiled code to the numba side (instead of passing entire IR) and construct simple wrapper there using llvmlite. This will allow to keep most of the existing numba integration as is.
Hardcode84
commented
2 years ago
Historically we have relied on numba execution engine (MCJIT - based) for executing our MLIR code. The main issue here was that Numba uses different llvm version (much older than ours), to handle this we are serializing lvm module to bitcode on our side using our llvm and deserialize it on numba side using theirs. This approach was working reasonably well up until now (although we already have a hack on our side to remove unsupported attributes), but it is going to break as upstream llvm is fully switching to opaque pointers and thus breaking bitcode compatibility.
Better approach would be to have full execution engine on our side and use it compile code on our side. After that we can pass function pointer to the compiled code to the numba side (instead of passing entire IR) and construct simple wrapper there using llvmlite. This will allow to keep most of the existing numba integration as is.