[Bug] [TIRx][CUDA] MergeSharedMemoryAllocations hoists a dynamic allocation above its size binding
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 22/100
Línea de trabajo
Start with the reproducer script, which shows the buffer extent size being hoisted above its T.let definition by MergeSharedMemoryAllocations. The use-before-definition check is the assertion at src/tirx/analysis/var_use_def_analysis.cc:127, reached through SplitHostDevice. Done means the merged module keeps size defined before its use and the script runs to passed.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Expected behavior
s_tir.transform.MergeSharedMemoryAllocations() should preserve the scope and definition order of variables used in the merged buffer extent. The resulting module should be accepted by tirx.transform.SplitHostDevice().
The example below has two dynamic shared-memory buffers. The second buffer uses a local size binding. The input passes both verify_ssa and verify_well_formed. The intended runtime domain is 1 <= n <= 128.
Actual behavior
The merge pass moves the combined buffer allocation before the definition of size. The transformed IR contains this ordering:
size = T.int64() # Variable declaration, not a value binding.
buf_dyn_shmem = T.alloc_buffer(
(T.int64(512) + T.max(T.int64(0), size * T.int64(4)),),
"uint8",
scope="shared.dyn",
)
# Buffer declarations omitted.
size = T.min(n, T.int64(128))
SplitHostDevice then fails:
src/tirx/analysis/var_use_def_analysis.cc:127
TVM_FFI_ICHECK(!use_count_.count(v))
tvm.error.InternalError: Check failed: (!use_count_.count(v)) is false:
variable size has been used before definition!
The script below reproduced the same assertion in three fresh processes. Replacing only the second buffer's extent (size,) with the equivalent inline expression (T.min(n, T.int64(128)),) allowed the merge and host/device split to pass in three fresh processes.
This small example does not invoke CSE or Relax compilation. In an FP16 symbolic matmul compiled for CUDA, the same ordering problem was observed between the IR immediately before and after MergeSharedMemoryAllocations, followed by a use-before-definition assertion for cse_v46 in SplitHostDevice.
Environment
- Apache TVM
0.26.dev0+source.8f328e8(source snapshot; no.gitdirectory) - Ubuntu 22.04.5, Linux
6.8.0-52-generic, x86-64 - Python
3.11.16, LLVM15.0.7 - NVIDIA RTX A6000, driver
550.120 - CUDA toolkit
12.4, targetsm_86, LLVM host targetgeneric
The reproducer only transforms IR; it does not allocate GPU tensors or execute a kernel.
Steps to reproduce
Save the following script as repro_merge_shared.py and run:
python repro_merge_shared.py
For a passing control, change this line:
C = T.alloc_buffer((size,), "float32", scope="shared.dyn")
to:
C = T.alloc_buffer((T.min(n, T.int64(128)),), "float32", scope="shared.dyn")
import tvm
from tvm import s_tir
from tvm.script import ir as I, tirx as T
@I.ir_module
class Module:
@T.prim_func(s_tir=True)
def main(A: T.Buffer((128,), "float32"), n: T.int64):
T.func_attr({
"target": T.target({
"kind": "cuda", "arch": "sm_86",
"host": {"kind": "llvm", "mcpu": "generic"},
}),
"tirx.noalias": True,
})
bx = T.launch_thread("blockIdx.x", T.int64(1))
B = T.alloc_buffer((128,), "float32", scope="shared.dyn")
size: T.let[T.int64] = T.min(n, T.int64(128))
C = T.alloc_buffer((size,), "float32", scope="shared.dyn")
tx = T.launch_thread("threadIdx.x", T.int64(128))
B[tx] = A[tx]
if tx < size:
C[tx] = B[tx]
A[tx] = C[tx] + T.float32(1)
assert tvm.tirx.analysis.verify_ssa(Module["main"])
assert tvm.tirx.analysis.verify_well_formed(Module["main"])
print("input validation passed", flush=True)
merged = s_tir.transform.MergeSharedMemoryAllocations()(Module)
print(merged.script(), flush=True)
tvm.tirx.transform.SplitHostDevice()(merged)
print("passed", flush=True)
Triage
- needs-triage
- type: bug
- backend:cuda
- Lenguaje dominante
- Python
- Estrellas
- 13.9k
- Forks
- 4k
- Merge medio
- 7 h 59 min
- PR fusionados (30 d)
- 159
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de apache/tvm
-
needs-triage type: bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 80/100
Los mantenedores suelen responder en 1 día
-
[Bug] [Relax][ONNX] OneHot does not convert floating-point depth to int64Posiblemente ocupada @tandede la tomó hace 2 días. Abiertoneeds-triage type: bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
needs-triage type: bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
needs-triage type: bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
[Bug][Relax] ReorderTakeAfterMatmul fails on vector dot productsPosiblemente ocupada @hiyufan la tomó hace 12 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
apache/tvm#20595 · 1 comentario ·
Los mantenedores suelen responder en 1 día
Todos los issues de apache/tvm
Issues similares
-
docs size:S
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
strawberry-graphql/strawberry#4794 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
dataforgoodfr/cetolog#21 ·
-
security_citations_test fails against ecc 2026.11.6: SECURITY.md quotes ecc v2026.11.2's linesAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
btclib-org/btclib#2932 ·
Los mantenedores suelen responder en 1 día