Skip to content

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

Description

@robobryce

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions