[TIR][Fix] Buffer slicing using index dtype as extent#13788
[TIR][Fix] Buffer slicing using index dtype as extent#13788tqchen merged 1 commit intoapache:mainfrom
Conversation
|
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 |
MasterJH5574
changed the title
MasterJH5574
force-pushed
the
tvm-dev/2023-01-15-tir-parser-extent
branch
from
f7e7528 to
84a9f8c
Compare
cyx-6
left a comment
cyx-6
left a comment
There was a problem hiding this comment.
LGTM. Thanks for reporting and fixing this bug.
junrushao
left a comment
junrushao
left a comment
There was a problem hiding this comment.
LGTM, and would you like to revert the change to 3rdparty/cutlass? Seems like irrelevant
@junrushao Sorry my bad. I didn’t notice that... Will do later. |
MasterJH5574
force-pushed
the
tvm-dev/2023-01-15-tir-parser-extent
branch
from
84a9f8c to
f951dcc
Compare
junrushao
changed the title
| test_different_dtype_assignment_to_var() | ||
| b = 1 | ||
| test_var_capturing_order() | ||
| tvm.testing.main() |
There was a problem hiding this comment.
a = numpy.zeros((10, 10), dtype="int8") here is to test var capturing in #13640. I appreciate it if you could revert it and add a comment here.
[Fix] Buffer slicing using index dtype as extent
6 participants
This PR fixes a bug of TIR Buffer
__getitem__on Python side.Whenever the
__getitem__parameter is a multi-dim slice, on non-slice dimension a Range will be created. Prior to this PR, that range will have int32 dtype in regardless of thestart, while the proper behavior is to generate the extent according to the dtype ofstartwhenstartis a PrimExpr.This PR fixes the issue and provides a regression test.