[TVMScript] Distinguish between void* and handle

[Lunderberg]

Prior to this PR, the type annotations PrimType(DataType::Handle()) and PointerType(PrimType(DataType::Void())) are both represented as T.handle in TVMScript, which can cause failures to round-trip between TIR and TVMScript. This PR keeps PrimType(DataType::Handle()) as T.handle, but updates the representation of PointerType(PrimType(DataType::Void())) to T.handle("void") in order to distinguish between these two cases.

This is part of changes described in #14486, to improve round-trip failures that occur in lowering.

[tvm-bot]

Thanks for contributing to TVM! Please refer to the contributing guidelines https://tvm.apache.org/docs/contribute/ for useful information and tips. Please request code reviews from Reviewers by @-ing them in a comment.

• cc @Hzfengsy, @junrushao, @shingjan _{See #10317 for details}

_{Generated by tvm-bot}

[Lunderberg]

At some point, it may make sense to have PointerType require that its value is not a DataType::Handle(), to prevent this ambiguity from occurring in the first place. However, introducing that TIR requirement was a larger change than the parser.

[junrushao]

Yeah I made the change a while ago to unify T.Ptr and T.handle, and at that time i don't actually know a case where void* are different, so I decided to unify them anyways. I probably don't have much context. Perhaps would you like to give an example? Thanks a lot!!

[Lunderberg]

Certainly! This occurs in any PrimFunc that is after tir.MakePackedAPI in the lowering flow, as the out_ret_value is annotated with a PointerType(PrimType(DataType::Void())) (link). I don't think this has an impact on the generated code, but it does mean that we're producing TIR that can't be expressed in TVMScript, and can't use TVMScript for writing unit tests for this pass.

[tqchen]

The original intention there is to make the v_out_ret_value an opaque ptr. Perhaps we could simply mark it as handle as well? This would simplify our overall possibility without introducing void*

[junrushao]

I do think allow possibility to express two different handle types will give developers more opportunities, so I would prefer merging this PR in, as well as updating MakePackedAPI. That would be nice if we could document a bit more about in Handle the difference between PrimType and PointerType of void :-)

[Lunderberg]

From some quick tests, either representation could be removed without much difficulty. If we were getting rid of one of the two representations, I'd lean toward keeping the PointerType(...) version, since it is also needed to express a non-global scope.

That said, having a distinction between a pointer to a value and an opaque handle is probably a good one to keep around, so I'd lean toward @junrushao's suggestion.

[tqchen]

happy to go with @junrushao @Lunderberg what you suggest

[kparzysz-quic]

Void is defined as DataType(kHandle, 0, 0), while a legitimate handle has non-zero bits and lanes. Do we need an additional parameter here instead of passing the right thing in dtype?

[Lunderberg]

I believe so, because the dtype is providing the type of the pointed-to object, not the type of the pointer itself. While we could special-case passing of a DataType(kHandle, 0, 0) to produce PrimType(DataType::Handle()), that would give unexpected results if somebody tries to write a pointer-to-pointer as T.handle("handle") and accidentally hits the special-case.

[Lunderberg]

@tvm-bot rerun

[junrushao]

Let's get it in!