[Apache TVM Discuss] [Development/pre-RFC] Export TIR to json
We propose to implement an API to TVM that allows users to export the TIR representation of the generated kernels as json. **Motivation** Json is a standard file format and can easily be processed in python, for example. A json interface allows to analyze the generated kernels target agnostic. For example, this works for both llvm and c targets. The goal that we have is to be able to extract the full TIR representation of the host module and all device modules regardless of the specific executor, target or runtime. In the case of the AOT executor pipeline, this would also contain the tvmgen_default___main__ function. This allows to reconstruct the graph topology of the neural network. For Graph executors, the graph can still be accessed via module.graph_json. **Proposed Implementation** We have already conducted some experiments with a JsonScriptPrinter class similar to the TVMScriptPrinter class in src/printer/tvmscript_printer.cc based on the discussion here: https://discuss.tvm.apache.org/t/why-c-unpacked-api-not-work-anymore/11845/19?u=sebastianboblestetas We use it in driver_api.cc in the build function like this:  We make it accessible in python via json = module.lib.get_json() We do not know how to best export the TIR representation of the device modules. We would add a new boolean tir configuration option “tir.tir_export_to_json” to make this export functionality optional. We think we can provide a working prototype within a few weeks but would appreciate feedback already now. @Khoi @MJKlaiber @UlrikHjort @areusch --- [Visit Topic](https://discuss.tvm.apache.org/t/export-tir-to-json/12329/1) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/ad7414c9b68f7bcc27f4bec4ecd3a06bf9c541b3379701916706cd8c6ba59ff0).
[Apache TVM Discuss] [Development/pre-RFC] Export TIR to json
Thanks, @SebastianBoblestETAS. I agree that json is a great format for serializing, but I have a few questions: 1. What are the pros and cons of json format compared with TVMScript (if we have python env) 2. How to design a json format to store all TIR information for all possible nodes? Do you have examples to show it? --- [Visit Topic](https://discuss.tvm.apache.org/t/export-tir-to-json/12329/2) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/fe42af2bb0430158e35ea292347f2f897102c8dcd353c277a5e1991dcac6288b).
Re: [apache/tvm-rfcs] [RFC] UMA Universal Modular Accelerator Interface (PR #60)
> Im wondering whether should we provide an optional partitioning hook as well > -- so then it can be anything (i.e. any Sequential) and let the default be a > Sequential of MergeComposite, AnnotateTarget, MergeCompilerRegions, > ParititionGraph. WDYT ? Considering how partitioning is handled in #62 I would probably prefer a more declarative way of specifying different partitioning patterns. @MichaelJKlaiber @PaulPalomeroBernardo -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/60#issuecomment-1069204741 You are receiving this because you are subscribed to this thread. Message ID:
[Apache TVM Discuss] [Development/pre-RFC] Export TIR to json
Thanks @SebastianBoblestETAS . TVM already have a reflection based mechanism to serialize IR nodes (includin TIR and other functions) as [json format](https://tvm.apache.org/docs/reference/api/python/ir.html?highlight=save_json#tvm.ir.save_json). So it would be great to see if that functionality can be used directly for the usecase you have in mind. --- [Visit Topic](https://discuss.tvm.apache.org/t/export-tir-to-json/12329/3) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/dd7b17a6d25d81eed213360411c8cdf7f6d00b3b823f714d9dccee6c1903a720).
Re: [apache/tvm-rfcs] Collage RFC (PR #62)
@manupa-arm would be great to get your view on this too -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/62#issuecomment-1069262209 You are receiving this because you are subscribed to this thread. Message ID:
[Apache TVM Discuss] [Development] Should we delete NNVM?
It's been deprecated a long time ago. Is it still maintained? If not, I suggest that we delete it. --- [Visit Topic](https://discuss.tvm.apache.org/t/should-we-delete-nnvm/12330/1) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/84c06d3a7aaef7140047988d9996a6e7ba53d89bac2ba39d6dccb72522060f93).
[Apache TVM Discuss] [Development/pre-RFC] Export TIR to json
Hi,
thanks for the reference to this function. I was not aware of it.
However I tried it on a Module(c) and got this:
`{
"root": 1,
"nodes": [
{
"type_key": ""
},
{
"type_key": "runtime.Module"
}
],
"b64ndarrays": [],
"attrs": {"tvm_version": "0.9.dev0"}
}`
This looks like only a very small overview. What we would like to have is
really the full representation that the code generators get to write the code.
Do I miss an option for this function to get more detailed output?
---
[Visit Topic](https://discuss.tvm.apache.org/t/export-tir-to-json/12329/4) to
respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.apache.org/email/unsubscribe/1a2fe36d8136482a9d7d6bbc57d128f5c2f2e7786a8b1ddbe6274231e3ce942d).
[Apache TVM Discuss] [Development/pre-RFC] [RFC] Type-Directed Relay Fuzzing Library
We discussed this at the TVM Community Meeting this morning. A couple of notes: - What is the best reference paper for Relay? Where was the algebra for the type relations used here sourced from? Steven: The [Relay paper](https://arxiv.org/abs/1810.00952) is still the most comprehensive reference. The language has evolved a bit since its introduction, but the type system hasn't changed. - Have you considered how this may apply to Relax? Steven: This approach might prove challenging to use with symbolic shapes. It might be necessary to use ILP with Relax, but this approach also might be sufficient. Need to try this. --- [Visit Topic](https://discuss.tvm.apache.org/t/rfc-type-directed-relay-fuzzing-library/12234/3) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/29e716ba6b7f8060f28e1ff66ccfcdcc4262c55bbe1e18748cfd231b3d21519f).
[Apache TVM Discuss] [Meetup] Next TVM Community Meeting March 16
The recording has been [posted](https://youtu.be/1t2wf-hDjwg). --- [Visit Topic](https://discuss.tvm.apache.org/t/next-tvm-community-meeting-march-16/12298/3) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/32fbaf86415338a188005f863ea3a2cc9d2f9886305c537715d617ff43a851b6).
[Apache TVM Discuss] [Development/pre-RFC] Export TIR to json
runtime.Module itself is a runtime object, which does not yet support full serialization(due to the nature of some module not being able to serialize(e.g. DSO)). There was a discussion about [Artifact class](https://discuss.tvm.apache.org/t/introduce-artifact-a-container-for-generated-code/11099) which could go into this direction. If you take any IR object, say a tir.function or IRModule(that contains a TIR function) we will be able to use save_json to get the fully serialized format --- [Visit Topic](https://discuss.tvm.apache.org/t/export-tir-to-json/12329/5) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/0f7a02b007b0d2659384ca2d9ac600f963d1c1ae8ada1e55603bb4250760faf4).
Re: [apache/tvm-rfcs] Collage RFC (PR #62)
Hey all, heads up I'm taking a close look at the 'pass ordering' problem hiding in this RFC. That is, as written and prototyped, CollageFuseOps runs just before the current FuseOps so that it can 'see' rewrites which guide TVM's native fusion rules. However some of those rewrites are target specific, and some are very oriented towards TVM and would likely interfere with existing BYOC patterns and custom lowering function. So we want CollageFuseOps to run both before and after quite a few passes so somethings got to give. I'll see if I can put a clear strawman in place to address this. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/62#issuecomment-1069524854 You are receiving this because you are subscribed to this thread. Message ID:
