Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[TVMScript] Fix mismatched dtype of IterVar in T.thread_binding #16041

Merged
merged 1 commit into from Nov 3, 2023

Conversation

Hzfengsy
Copy link
Member

@Hzfengsy Hzfengsy commented Nov 2, 2023

As reported by the community, the dtype of IterVar in T.thread_binding is not consistent with the dtype of the corresponding value. This PR fixes this issue.

@Johnson9009
Copy link
Contributor

look good to me, Thanks.

@Hzfengsy Hzfengsy force-pushed the fix_tvmscript_thread_binding_dtype branch from 29a8df7 to a6eb0dd Compare November 2, 2023 12:23
As reported by the [community](https://discuss.tvm.apache.org/t/int32-int64-issue-when-codegen-into-llvm-function/15915),
the dtype of IterVar in `T.thread_binding` is not consistent with the dtype of the corresponding
IterVar. This PR fixes this issue.
@Hzfengsy Hzfengsy force-pushed the fix_tvmscript_thread_binding_dtype branch from a6eb0dd to 4345e32 Compare November 2, 2023 14:46
@tqchen tqchen merged commit 4b29f25 into apache:main Nov 3, 2023
17 checks passed
@Hzfengsy Hzfengsy deleted the fix_tvmscript_thread_binding_dtype branch November 3, 2023 06:17
Hzfengsy added a commit to Hzfengsy/tvm that referenced this pull request Nov 5, 2023
As a follow up PR of apache#16041, this PR fixes the iter_var dtype generated
by the schedule primitive `bind`. Now the iter_var dtype is the same as
the loop_var.

Note that this PR changes the internal interface (tir interface) of the
bind primitive. But it does not change the user interface (python side,
and concrete_schedule.cc side).
Hzfengsy added a commit to Hzfengsy/tvm that referenced this pull request Nov 5, 2023
As a follow up PR of apache#16041, this PR fixes the iter_var dtype generated
by the schedule primitive `bind`. Now the iter_var dtype is the same as
the loop_var.

Note that this PR changes the internal interface (tir interface) of the
bind primitive. But it does not change the user interface (python side,
and concrete_schedule.cc side).
junrushao pushed a commit that referenced this pull request Nov 5, 2023
As a follow up PR of #16041, this PR fixes the iter_var dtype generated
by the schedule primitive `bind`. Now the iter_var dtype is the same as
the loop_var.

Note that this PR changes the internal interface (tir interface) of the
bind primitive. But it does not change the user interface (python side,
and concrete_schedule.cc side).
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.

None yet

3 participants