Repository navigation
[Ascend] Fix tl.sum over an i1 mask returning 1 instead of the count - #1402
Merged
Merged
Conversation
zhzhcookie
reviewed
Oct 19, 2026
togepro
force-pushed
the
issue1220
branch
2 times, most recently
from
October 20, 2026 14:02
7c164a2 to
24ee7b2
Compare
togepro
requested review from
i3wanna2,
kateyijian,
menchunlei and
sunnycase
as code owners
October 20, 2026 14:02
`a + b` on i1 is a 1-bit add, which is a logical or, so any non-zero number of set lanes saturates to 1. The extui after the reduce cannot recover the count. Restore the promotion for i1 only, leaving int8/int16 at their native width.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
tl.sumover an i1 mask only ever returns 0 or 1: 1 if any lane is set, 0 if none. The actual count is lost. No error, no warning, just silently wrong results at runtime.Upstream Triton is unaffected because
_pick_sum_dtypepromotes first.int1has a bit width of 1 and is classified inUINT_TYPES, so upstream picksuint32and accumulates there. The Ascend spec override has that promotion commented out, from the triton 3.5 sync commit8c30adb6c9; the comment only claims it is not needed and gives no reason.cumsumin the same file kept its promotion call, and that inconsistency is itself the clue.Changes
_pick_sum_dtypeand promotes i1 to int32 and nothing else.After the fix the
extuimoves ahead of the reduce and the accumulation happens in i32.Related