Lunderberg commented on issue #17235:
URL: https://github.com/apache/tvm/issues/17235#issuecomment-2266148722
Well, I've got good news and bad news. The good news is that bug can be
boiled down to even simpler minimal case, and can be resolved by #16183.
```python
import tvm
from tvm.script import ir as I, relax as R
@I.ir_module
class Module:
@R.function
def main():
return (42,)
built = tvm.relax.build(Module, target="llvm")
vm = tvm.relax.VirtualMachine(built, tvm.cpu())
output = vm["main"]()
# With https://github.com/apache/tvm/pull/16183, these asserts pass.
assert len(output) == 1
assert isinstance(output[0], int)
assert output[0] == 42
```
The downside is that #16183 is an absolute beast of a PR, touches pretty
much every single part of TVM, caused and resolved breakage in unit tests
across the board, and comes with my sincere apologies to code reviewers. (But
still a worthwhile change to make.)
The root cause is that there are two distinct ways to represent an integer
in the TVM. It can be stored in the `TVMRetValue` type, with the `kDLInt` type
code, or as part of the `tvm::Object`/`tvm::ObjectRef` hierarchy. There are
some parts of the codebase that require a `kDLInt`, such as passing an integer
to a native func. There are other parts of the codebase that require an
`ObjectRef`, such as storing an integer in a `tvm.runtime.Container`. There
are some automatic conversions applied in the FFI (e.g. converting from
`kDLInt` to a `tvm.tir.IntImm`), but extending them would continue a trend of
using compile-time types as part of the runtime library, and wouldn't be a good
long-term plan. In part, PR #16183 is so large because it re-establishes the
division between the compile-time and runtime types, and then needed to update
every location that relied on no-longer-present automatic conversions.
I'm going to merge `main` into the #16183 branch, to make sure the CI
results aren't stale, and will see next week if I can get somebody to tackle
the code review of it.
--
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]
