Lunderberg commented on PR #16068:
URL: https://github.com/apache/tvm/pull/16068#issuecomment-1808472413
> This seems to be reasonable. I would request a similar normalizer be added
for `call_tir_inplace` and `call_tir_with_grad`, as they all expect a tuple of
arguments.
Sounds good, and updated. This also included moving the validity checks
from `InferStructInfoCallTIRInplace` to `NormalizeCallTIRInplace`, since the
shape inference is done before normalization.
> Is this a case we would unequivocally prohibit?
My personal preference would be to allow it, though I can understand the
reasons @tqchen laid out in the #15916 discussion for wanting it to be
prohibited.
That said, I think we still can provide a normalized form of `call_tir`, so
we don't need to throw an error back at the user. Because all relax tuples
have a fixed size, we could still normalize it to an in-line tuple, but one
whose contents were populated by `TupleGetItem` instances.
```python
@R.function
def func(x: R.Tuple([...])):
...
R.call_tir(some_primfunc, R.tuple(x[0], x[1], ..., x[n]), ...)
...
```
It's not the cleanest of normalized forms, but it's semantically equivalent
and preserves the in-line tuple of arguments. If a later pass (e.g.
`BindParams` or a `ExpandTupleParams` pass I'm putting together) updates the
function arguments, then this form can be simplified with the existing
`CanonicalizeBindings`.
--
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]
