Conversation
…n int64 With no `dtype` argument torch accumulates every integral and bool input of `cumsum` / `cumprod` in int64. The converters passed `dtype=None` through, so the running sum kept the input dtype and wrapped: uint8 [200, 100, 50].cumsum(1) torch int64 [200, 300, 350] before uint8 [200, 44, 94] int8 [100, 100, 50].cumsum(1) torch int64 [100, 200, 250] before int8 [100, -56, -6] int32 [2^30, 2^30, 5].cumsum(1) torch int64 [.., 2147483653] before int32 [.., -2147483643] bool [T, T, F].cumsum(0) torch int64 [1, 1, 0, ...] before InternalError An explicit `dtype=` was already honoured and is unchanged; float inputs keep their dtype, as in torch. The two converters share the rule through `_cumulative_dtype`. Swept cumsum / cumprod along both axes plus cumsum(dtype=float32) over bool, uint8, int8, int16, int32, int64, float16, float32 and float64 inputs chosen to overflow the narrow types, built with relax.build(llvm) and compared with torch on dtype and values: 25 matched / 16 wrong / 4 raised before, 45 / 0 / 0 after. Tests: an IR-level check that a uint8 cumsum emits `R.cumsum(..., dtype="int64")`, and numeric checks of cumsum, cumprod and cumsum(dtype=float32) over bool, uint8, int8, int32 and int64 inputs. The bool, uint8, int8 and int32 cases fail against the previous head; int64 passes there and pins that it is untouched.
This was referenced Sep 17, 2026
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
1 participant
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.
Problem
With no
dtypeargument,torch.cumsum/torch.cumprodaccumulate every integral and bool input in int64. The converters passeddtype=Nonethrough torelax.op.cumsum/cumprod, so the running sum kept the input dtype — and wrapped:mainuint8 [200, 100, 50].cumsum(1)[200, 300, 350][200, 44, 94]int8 [100, 100, 50].cumsum(1)[100, 200, 250][100, -56, -6]int32 [2³⁰, 2³⁰, 5].cumsum(1)[…, 2147483653][…, -2147483643]uint8 [200, 100, 50].cumprod(1)[200, 20000, 1000000][200, 32, 64]bool [T, T, F].cumsum(0)InternalError(relax cumsum on bool)Not a dtype-label difference: the values are wrong as soon as the sum leaves the narrow range, which for uint8/int8 is the second element.
Fix
_cumulative_dtypereturns the explicitdtype=if given, otherwiseint64for an integral or bool input andNone(keep) for floats — torch's rule. Both converters use it.Verification
cumsumandcumprodalong both axes pluscumsum(dtype=float32), over bool, uint8, int8, int16, int32, int64, float16, float32 and float64 inputs chosen to overflow the narrow types, each built withrelax.build(llvm)and compared with torch on dtype and values:mainThe explicit-
dtypevariant and every float input were already correct and are unchanged.test_frontend_from_exported_program.pyandtest_frontend_from_fx.py: failure sets identical before and after apart from the new tests.ruff check/ruff format --check(v0.12.3, the version CI pins) clean.Tests
test_cumsum_integer_input_accumulates_in_int64— IR-level: a uint8 input emitsR.cumsum(x, axis=1, dtype="int64").test_cumsum_cumprod_integer_values—cumsum,cumprodandcumsum(dtype=float32)over bool, uint8, int8, int32 and int64, asserting dtype and values.Against the previous head the bool, uint8, int8 and int32 rows fail (
assert 'uint8' == 'int64'and the IR mismatch); int64 passes there and pins that it is untouched.Independent of #20372 / #20373 (branched from
main).This change was prepared with AI assistance (Claude). I have reviewed and verified it, and can speak to it in review.