Let me elaborated a bit. While #2546 decides on most details about the pass manager internals, I would like us to think a bit more about the API design itself. In particular, how to learn from deep learning frameworks(pytorch, keras, gluon) to build an API that is intuitive, friendly and requires the users to write a minimum amount of code.
During a conversation with @MarisaKirisame and others, we try to mock up what the usage of the code looks like, and we try to model it relatively similar to pytorch (see updated example). I think we should iterate on the API designs. At the current moment, we have quite a few boiler-plate in relay.build_module etc. that I hope eventually we can simplify with just the consistent elegant code. The transform namespace arises from the idea to be consistent with MLIR. MLIR tries to separate pass into two categories(transforms: Module->Module, analysis; Module->AnalysisResult). I think it is a good separation that we could learn from. It also avoids the problem of ```pass``` being a keyword in python. We could use ```transform``` namespace could be a new namespace to implement such change, we keep the original API, and migrate over after we fully support the transform API and remove the original ir_pass.py -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/3202#issuecomment-493274401
