Lunderberg commented on PR #17216:
URL: https://github.com/apache/tvm/pull/17216#issuecomment-2261335693
> Having such explicit argument makes the "intent" clear, with the explicit
sinfo, we can write down the semantics in a clear fashion
Good point on the semantics. This change would add an additional step to
the user-facing semantics of `R.call_tir`.
```python
def call_tir(func, args, out_sinfo):
if out_sinfo is None:
out_sinfo = infer_out_sinfo(func, args) # may throw
out = alloc_outputs(out_sinfo)
func(*args, unpack_outputs(out))
return out
```
I suppose that I'm getting stuck on is the "intent" part. While there are
exceptions, in the majority of cases, there's one and only one correct value
for `out_sinfo`. Since the user doesn't have any choice in it, we can't infer
any intention from the user about it. On the other hand, if the user has the
option of omitting the `out_sinfo`, then we could distinguish between the
intent of "use whichever output is valid" (e.g. `R.call_tir(unary_abs, [x])`)
and "verify and use the output I expect" (e.g. `R.call_tir(unary_abs, [x],
R.Tensor([16],'float16'))`).
> In this particular case, having good well form check about consistency
would help a lot toward that direction
Agreed. I think for now, let's put this PR on hold, and I'll update the
well-formed checker to verify consistent between the `R.call_tir` callee and
the input/output arguments. (Since that's a change that we both agree on, and
covers many of the same error modes.)
--
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: commits-unsubscr...@tvm.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
