The GitHub Actions job "CI" on tvm.git/fix/relax-torch-cumsum-int64 has succeeded. Run started by GitHub user hiyufan (triggered by hiyufan).
Head commit for run: edf54723cbeaeddda7d8b8414a59f5d6137de8d4 / Chen Yufan <[email protected]> [Fix][Relax][Frontend][Torch] Accumulate integer cumsum and cumprod in 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. Report URL: https://github.com/apache/tvm/actions/runs/35199800268 With regards, GitHub Actions via GitBox --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
