[VTA] IR Pass Infra limitations?

Hi @thierry,

I hope you don’t mind me explicitly tagging you, but I had some questions and I think you are the best person to answer them.

The way I see it, many interested parties will look at the VTA part of the code base in order to retarget TVM for novel architectures. Obviously there are other documentations like Bring your own codegen, Adding a Compiler Pass to Relay and Relay Pass Infrastructure and for me it is important to know if VTA’s code base reflects the same patterns which are exemplified in those guides. Also if not, the reasons why.

  1. When is it save to assume that if we parse a framework NN description, we will get a relay module with keyword 'main'? also why was this even necessary? Example here:
  1. Why was the graph_pack relay optimization not implemented as a function decorated using @relay.transform.module_pass ?

  2. What kind of relay.transform would be more adecuate for get_subgraph? (i.e. either ModulePass or FunctionPass?

  3. What is the intuition behind requiring the ANF representation of the relay program for the _recursion function?

  4. Why was the _recursion function not implemented as a relay.analysisy.post_order_visit or an ExprVisitor ?

  5. What exactly is the GraphNormalForm?

  6. Why in run_opt_pass there is a need to transform the tvm.expr into a tvm.module to call the opt_pass?

  7. What is the need to run the relay.transform.InferType before the return?

  8. Why is there still a difference of IR Pass Infra between the relay variant and the tvm (I think it’s now going to be named tir) ? (i.e. for tvm we need to create a list of passes and add them in the call tvm.build_config(add_lower_pass=...) and in relay we have the relay.transform.sequential construct )

Thanks for the time and sorry for the long post