Lunderberg commented on PR #15916:
URL: https://github.com/apache/tvm/pull/15916#issuecomment-1781157045
This does increase the complexity of passes that interact with `call_tir`,
but it also decreases the complexity of all other passes. If we require an
in-line tuple for `call_tir`, then every other pass must be aware of this
restriction and preserve it. Any `ExprMutator` class that implements `Expr
VisitExpr_(const TupleNode*) override` must also check the context of the
`Tuple` in order to know what mutations are allowed, and similar checks would
be required in `VisitBinding`. This is complexity that is inherent to
interactions with a `call_tir` node, and a IR restriction not exposed through
the C++ type system moves that complexity to passes that shouldn't be aware of
`call_tir` at all.
I think there are ways we could ensure that all `call_tir` has immediate
access to its arguments, working within the C++ type system instead of running
a well-formed check
* Provide an explicit IR node for `CallTIR` and variants. Instead of
`R.call_tir(tir_gvar, [arg1, ..., argN])` expanding into
`R.Call(tvm.ir.Op("relax.call_tir"), [tir_gvar, R.tuple(arg1, ..., argN)])`, it
would expand into `R.CallTIR(tir_gvar, [arg1, ..., argN])`.
* Move the GlobalVar target into a member variable of the `call_tir`
operator. Instead of `R.call_tir(tir_gvar, [arg1, ..., argN])` expanding into
`R.Call(tvm.ir.Op("relax.call_tir"), [tir_gvar, R.tuple(arg1, ..., argN)])`, it
would expand into `R.Call(R.TIRFunc(tir_gvar), [arg1, ..., argN])`. This would
be analogous to how `R.ExternFunc` is currently handled.longer require a tuple,
so it couldn't be indirect.
With either option, the arguments would be immediately accessible by passes
that interact with `call_tir`, but this would be enforced at the type system,
so other passes wouldn't be required to explicitly check for it at runtime.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
