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: commits-unsubscr...@tvm.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org