Skip to content

Conversation

@Lunderberg
Copy link
Contributor

Previously, the return value of a PackedFunc was hard-coded as the string "return 0;" in CodeGenCHost, which could cause compilation errors for PrimFunc returning DataType::Void(). This PR removes this explicit return statement from CodeGenCHost, replacing it with tir::ret(Integer(0)) in the MakePackedAPI and MakeUnpackedAPI transforms.

This is related to #15073, which performs an analogous change for the function signature.

Previously, the return value of a PackedFunc was hard-coded as the
string `"return 0;"` in `CodeGenCHost`, which could cause compilation
errors for `PrimFunc` returning `DataType::Void()`.  This PR removes
this explicit return statement from `CodeGenCHost`, replacing it with
`tir::ret(Integer(0))` in the `MakePackedAPI` and `MakeUnpackedAPI`
transforms.

This is related to apache#15073, which
performs an analogous change for the function signature.
@tvm-bot
Copy link
Collaborator

tvm-bot commented Jun 12, 2023

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.

Generated by tvm-bot

Lunderberg added a commit to Lunderberg/tvm that referenced this pull request Jun 13, 2023
Previously, some operations in `tvm.tir.op` required the operand to
already be a `PrimExpr`, and raised an error if the operand was
instead a python object.  This could cause failures round-trip through
TVMScript, as int32 and float32 types are printed as literals in
TVMScript, relying on automatic conversion to convert them back into
`PrimExpr` objects.  For example, `T.expr2(T.int32(0))` is printed as
`T.expr2(0)`, which then passes the python object `0` into
`tvm.tir.op.expr2` when parsing the TVMScript.

This commit updates the operations in `tvm.tir.op` to convert operands
prior to accessing `operand.dtype`, avoiding the error and allowing
these expressions to round-trip.

This issue was first noticed in
apache#15076 for `T.ret(0)`, but applied
to any operator that used the operand's dtype without first
normalizing to `PrimExpr`.
@csullivan csullivan merged commit 0c09547 into apache:main Jun 15, 2023
csullivan pushed a commit that referenced this pull request Jun 15, 2023
Previously, some operations in `tvm.tir.op` required the operand to
already be a `PrimExpr`, and raised an error if the operand was
instead a python object.  This could cause failures round-trip through
TVMScript, as int32 and float32 types are printed as literals in
TVMScript, relying on automatic conversion to convert them back into
`PrimExpr` objects.  For example, `T.expr2(T.int32(0))` is printed as
`T.expr2(0)`, which then passes the python object `0` into
`tvm.tir.op.expr2` when parsing the TVMScript.

This commit updates the operations in `tvm.tir.op` to convert operands
prior to accessing `operand.dtype`, avoiding the error and allowing
these expressions to round-trip.

This issue was first noticed in
#15076 for `T.ret(0)`, but applied
to any operator that used the operand's dtype without first
normalizing to `PrimExpr`.
@Lunderberg Lunderberg deleted the codegen_c_packed_func_return branch June 15, 2023 19:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants