Ailing Zhang

We currently support it in python frontend (via a hack which will be removed by #5819), C-API need to support that as well.

Although we currently support specifying target arch when creating a `ti.aot.Module` it's no-op and can be misleading.. Properly supporting that requires a refactor to separrate compilation and runtime, so practically...

Current our C-API is tightly coupled with AOT data structures (due to serialization & deserialization), we should record when - an old python saved aot module stop working for capi...

This is a tracking issue since there seems to be a dependency chain according to @PENGUINLIONG : - [ ] error reporting - [ ] queue support - [ ]...

This is a long-wanted feature, printing is currently only supported on LLVM-based backends and generally useful for debugging.

This should walkthrough the AOT process using a few simple compute kernel: - save it in python using cgraph - load using C-API and run

Then we can potentially generate some boilerplate code and save users from writing repetitive code in C manually. This boilerplate may include runtime setup as well as ndarray allocation to...

This should include motivation, usage and its limitations

It's too verbose to have to create symbols manually and match shape/dtypes with the corresponding runtime ndarray. Let's having something like `from_ndarray` helper to do this for users.

This way API might look much cleaner.