[Bug] [Arith] ConstIntBound excludes zero for a wrapping uint32 left shift
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
The unsound bound comes from InfAwareLeftShift as called in src/arith/const_int_bound.cc around lines 497-508, which ignores the uint32 result width. Start by running the repro script with an LLVM-enabled build, then check how the shift bound is computed for unsigned dtypes. Done means the analyzer's bound for uint32(2) << i with i in [0, 32) includes 0, and the existing arith tests still pass.
由索引模型根据 Issue 内容生成。
描述
Expected behavior
For i in [0, 32), the constant integer bound of uint32(2) << uint32(i) should include zero. At i = 31, the uint32 result wraps modulo 2**32 and is exactly zero. All shift counts are smaller than the 32-bit operand width.
This uses the default analyzer context without allow_uint_as_index or any opt-in no-overflow assumption. A conservative bound covering the uint32 range would be acceptable.
Actual behavior
Analyzer.const_int_bound returns [2, 4294967296], whose lower bound excludes the valid result zero.
The script below also compiles and executes the same expression for all 32 shift counts on LLVM, verifies every output against a Python modulo-2**32 reference, and then shows the contradictory inferred bound:
inferred bound: 2 4294967296
actual uint32(2) << 31: 0
AssertionError: inferred bound [2, 4294967296] excludes 0
The assertion is a check in the reproduction script; TVM returns the incorrect bound without raising an error. The generated kernel returns the expected uint32 results. The demonstrated defect is the unsound bound, rather than an observed uint32 code-generation error.
This exact script reproduced in three fresh Python processes. Controls limiting uint32 shifts to [0, 31), or widening the operand to uint64 while retaining [0, 32), avoid wraparound and give bounds consistent with the computed values.
In the tested source snapshot, src/arith/const_int_bound.cc:497-508 passes the operand bounds to InfAwareLeftShift. That helper accounts for the int64 computation limit but does not account for the uint32 result width. This appears to explain the omitted wraparound value.
Environment
- Apache TVM 0.26.dev0+source.8f328e8 (source snapshot)
- Ubuntu 22.04.5, Linux 6.8.0-52-generic, x86-64
- Python 3.11.16
- LLVM 15.0.7, target llvm
The analyzer example requires no GPU; the compiled LLVM kernel verifies the concrete counterexample.
Steps to reproduce
Save as repro.py and run python repro.py in a TVM build with LLVM enabled:
import numpy as np
import tvm
from tvm import tirx
from tvm.script import ir as I, tirx as T
i = tirx.Var("i", "int32")
analyzer = tvm.arith.Analyzer()
analyzer.bind(i, tvm.ir.Range(0, 32))
expr = tirx.shift_left(tirx.const(2, "uint32"), tirx.Cast("uint32", i))
bound = analyzer.const_int_bound(expr)
print("inferred bound:", bound.min_value, bound.max_value, flush=True)
@I.ir_module
class Module:
@T.prim_func(s_tir=True)
def main(out: T.Buffer((32,), "uint32")):
for j in range(32):
out[j] = T.shift_left(T.uint32(2), T.Cast("uint32", j))
executable = tvm.compile(Module, target="llvm")
out = tvm.runtime.empty((32,), "uint32", tvm.cpu())
executable["main"](out)
actual = out.numpy()
expected = np.array([(2 << j) & 0xffffffff for j in range(32)], dtype="uint32")
np.testing.assert_array_equal(actual, expected)
value = int(actual[31])
print("actual uint32(2) << 31:", value, flush=True)
assert bound.min_value <= value <= bound.max_value, (
f"inferred bound [{bound.min_value}, {bound.max_value}] excludes {value}"
)
Triage
- needs-triage
- type: bug
- 主要语言
- Python
- 星标
- 13.9k
- 派生
- 4k
- 平均合并
- 7 小时 59 分钟
- 30 天内合并 PR
- 159
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南,环境需要你自己搭建:先看它的 README,通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
apache/tvm 的其他 Issue
-
needs-triage type: bug
难度 2/5 1-3 小时 新手友好度 80/100
维护者通常 1 天内回复
-
[Bug] [Relax][ONNX] OneHot does not convert floating-point depth to int64可能已有人在做 @tandede 于 3 天前认领。 未关闭needs-triage type: bug
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
needs-triage type: bug
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
needs-triage type: bug
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
[Bug][Relax] ReorderTakeAfterMatmul fails on vector dot products可能已有人在做 @hiyufan 于 13 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 74/100
维护者通常 1 天内回复
相似的 Issue
-
[BUG]: Compliance rules never see Unity Catalog views as views可能已有人在做 @wagnercsantos 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
databrickslabs/ontos#1348 ·
维护者通常 3 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
ibm-granite/granite.build#649 ·
维护者通常 1 天内回复
-
`forum_pr_poster` action will always return `none` when checking for pre-existing feedback threads, even if a feedback thread already exists.可能已有人在做 @pgmzeta 今天认领。 未关闭E-Verified P-Major
难度 2/5 1-3 小时 新手友好度 79/100
goonstation/goonstation#28259 ·
维护者通常 2 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 65/100
woonstadrotterdam/monumenten#70 ·
维护者通常 15 天内回复
-
binding:python bug
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复