[BUG]: cuda.lang Array.slice rejects valid integer bounds as non-tile scalars

先从 src/cuda/tile/_ir/ops.py 中共享的 slice 实现及其 require_signed_integer_0d_tile_type 验证器开始，然后比较 experimental/cuda-lang/src/cuda/lang/_ir/type.py 和 _ir/ops.py 中 CUDA Lang 的类型和指针映射。首先运行提供的 compile_simt 复现程序。当带符号字面量和动态 CUDA Lang 边界能够编译并产生文档所述的零拷贝视图行为时，即表示完成。

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:

value = a[start + i]

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.