Tvm: [RFC][Relay] Pass API Discussion

[MarisaKirisame]

In #2512 , we had decided on the API on Pass Manager. However, in personal communication with @tqchen , he suggested that we think on the name a bit (what namespace, what is the name of class and function, etc).

Example Code

python

from tvm import relay

x = relay.var("x")
y = relay.add(x, x)
f = relay.Function([x], y)

mod = relay.Module({"main": f})
# NOTE: infer type will be automatically populated in the future
seq = relay.transform.Sequential(
    relay.transform.InferType(),
    relay.transform.DebugPrintText(),
    relay.transform.FoldConstant(),
    relay.transform.AlterOpLayout(),
)
with relay.build_config(opt_level=3):
     mod = seq(mod)

C++

relay::Module Transform(relay::Module mod) {
  auto seq = relay::transform::Sequential({
    relay::transform::InferType(),
    relay::transform::DebugPrintText(),
    relay::transform::FoldConstant(),
        relay::transform::AlterOpLayout()});

   { 
     relay::BuildConfigContext bctx(relay.BuildConfig(opt_level=3));
      return seq(mod);
  }
}

[zhiics]

Why transform is better than pass? I am fine with Sequential as it is also used by Pytorch.

[tqchen]

Let me elaborated a bit. While #2546 has decided 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 as 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

[tqchen]

Things to discuss:

• API mock-up example, syntax
• namespace convention
• keyword for the entry function in Module(main?)

[tqchen]

Possible incremental migration plan:

• Introduce transform.py transform.h
• Migrate build_module to use a new pipeline
• Remove old ir_pass/pass until we fully
• Use main for the entry function

[zhiics]

Sounds like a good plan. I think main is currently used as the entry function by default, right?