Version
- cuTile Python source commit:
a9ae75fc9a5fb4e4e07ea71da7407dc4c23330ab
cuda-tile: 9.9.99
cuda-lang: 9.9.99
- Installation method: source
- CUDA Toolkit: not required for this reproducer; the failure occurs during front-end HIR-to-IR type checking before CUDA code generation. The reproducing environment does not have
nvcc installed.
- Python: 3.10.12
Describe the bug
cuda.lang.Array.slice() fails type checking for valid signed integer bounds, including integer literals.
The inherited API contract says start and stop may be integer scalars or 0D tiles. However, the shared implementation requires CUDA Tile's concrete TileTy, while CUDA Lang represents rank-zero values as ScalarTy.
This prevents natural zero-copy view construction, including compile-time-expanded code such as splitting a one-dimensional array into four equal views:
parts = tuple(
x.slice(0, i * chunk, (i + 1) * chunk)
for i in cl.static_iter(range(4))
)
Minimum reproducible example
import cuda.lang as cl
from cuda.lang.compilation import KernelSignature
def kernel():
a = cl.shared_array((8,), cl.int32)
a.slice(axis=0, start=1, stop=4)
cl.compile_simt(
kernel,
[KernelSignature(())],
gpu_name="sm_80",
arch="compute_80",
)
Expected behavior
Compilation succeeds. The result is a zero-copy view of a[1:4], with shape (3,), sharing the original storage.
This follows the documented Array.slice contract: start and stop may be integer scalars or 0D tiles. Dynamic bounds such as values derived from x.shape[0] should work as well.
Actual behavior
Compilation raises:
cuda.tile._exception.TypeCheckingError:
Invalid argument "start" of slice(): Expected a scalar or a 0D tile, but given value has type int32
"/tmp/cuda_lang_array_slice_repro.py", line 3, col 5-36, in kernel:
a.slice(axis=0, start=1, stop=4)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The message is contradictory: the value is a valid CUDA Lang int32 scalar, but it is rejected.
Likely cause
cuda.lang.Array subclasses cuda.tile.Array, so it inherits slice:
experimental/cuda-lang/src/cuda/lang/_stub/core_api.py:10-15,32
src/cuda/tile/_stub.py:177-190
CUDA Lang installs CUDA Tile's shared array implementation registry:
experimental/cuda-lang/src/cuda/lang/_ir/ops.py:40-47,176-181
The shared slice implementation validates both bounds with require_signed_integer_0d_tile_type:
src/cuda/tile/_ir/ops.py:782-787
That validator requires the concrete type to be TileTy, while CUDA Lang maps rank-zero values to ScalarTy:
src/cuda/tile/_ir/op_impl.py:553-559,598-602
experimental/cuda-lang/src/cuda/lang/_ir/type.py:43-57,284-295
Consequently, literal and runtime CUDA Lang integer scalars fail before slicing is lowered.
There may be a second representation mismatch after correcting validation: the shared implementation calls CUDA Tile's pointer_offset, while CUDA Lang arrays use PointerTy and their own pointer arithmetic implementation. A complete fix may need a CUDA Lang-specific slice implementation, or a representation-neutral shared implementation.
Workaround
For scalar access, rebase the index manually:
For a contiguous, compile-time-sized view, reconstruct an array from an offset pointer:
ptr = a.get_element_pointer(start)
sub = cl.reinterpret_pointer_as_array(
ptr,
dtype=cl.int32,
shape=(3,),
)
This is not equivalent to the documented slice API: reconstructed shapes must currently be compile-time constants, custom strides are not implemented, and bounds are not checked.
Contributing guidelines
- I agree to follow cuTile Python's contributing guidelines.
- I searched open and closed issues for
Array.slice, CUDA Lang slicing, and the reported error text and found no duplicate.
Version
a9ae75fc9a5fb4e4e07ea71da7407dc4c23330abcuda-tile:9.9.99cuda-lang:9.9.99nvccinstalled.Describe the bug
cuda.lang.Array.slice()fails type checking for valid signed integer bounds, including integer literals.The inherited API contract says
startandstopmay be integer scalars or 0D tiles. However, the shared implementation requires CUDA Tile's concreteTileTy, while CUDA Lang represents rank-zero values asScalarTy.This prevents natural zero-copy view construction, including compile-time-expanded code such as splitting a one-dimensional array into four equal views:
Minimum reproducible example
Expected behavior
Compilation succeeds. The result is a zero-copy view of
a[1:4], with shape(3,), sharing the original storage.This follows the documented
Array.slicecontract:startandstopmay be integer scalars or 0D tiles. Dynamic bounds such as values derived fromx.shape[0]should work as well.Actual behavior
Compilation raises:
The message is contradictory: the value is a valid CUDA Lang
int32scalar, but it is rejected.Likely cause
cuda.lang.Arraysubclassescuda.tile.Array, so it inheritsslice:experimental/cuda-lang/src/cuda/lang/_stub/core_api.py:10-15,32src/cuda/tile/_stub.py:177-190CUDA Lang installs CUDA Tile's shared array implementation registry:
experimental/cuda-lang/src/cuda/lang/_ir/ops.py:40-47,176-181The shared slice implementation validates both bounds with
require_signed_integer_0d_tile_type:src/cuda/tile/_ir/ops.py:782-787That validator requires the concrete type to be
TileTy, while CUDA Lang maps rank-zero values toScalarTy:src/cuda/tile/_ir/op_impl.py:553-559,598-602experimental/cuda-lang/src/cuda/lang/_ir/type.py:43-57,284-295Consequently, literal and runtime CUDA Lang integer scalars fail before slicing is lowered.
There may be a second representation mismatch after correcting validation: the shared implementation calls CUDA Tile's
pointer_offset, while CUDA Lang arrays usePointerTyand their own pointer arithmetic implementation. A complete fix may need a CUDA Lang-specific slice implementation, or a representation-neutral shared implementation.Workaround
For scalar access, rebase the index manually:
For a contiguous, compile-time-sized view, reconstruct an array from an offset pointer:
This is not equivalent to the documented slice API: reconstructed shapes must currently be compile-time constants, custom strides are not implemented, and bounds are not checked.
Contributing guidelines
Array.slice, CUDA Lang slicing, and the reported error text and found no duplicate.