What
QDP defines a shared Rust MAX_QUBITS policy, but some amplitude encoding paths do not apply the
shared validate_qubit_count check before computing 2^num_qubits:
- float32 host batch encoding
- float32 and float64 GPU-pointer encoding
- single-state and batch GPU-pointer variants
At the same time, qdp-kernels/src/kernel_config.h contains a second MAX_QUBITS definition that
is not used by any CUDA kernel.
Centralize the current static policy by making the Rust constant the single effective source and
applying its validator consistently at every amplitude encoder boundary.
Why
Missing validation allows excessive values to reach 1 << num_qubits, which can panic on shift
overflow or continue into an impractical allocation instead of returning the established
MahoutError::InvalidInput. The unused CUDA definition also creates a maintenance risk because it
can drift from the Rust policy without affecting kernel behavior.
Consistent validation gives CPU-data and GPU-pointer callers the same predictable error behavior
without changing valid encoding requests.
How
- Call
validate_qubit_count(num_qubits) before state-length calculations in every uncovered
amplitude f32 batch and GPU-pointer path.
- Keep
qdp_core::gpu::encodings::MAX_QUBITS as the shared static policy.
- Remove the unused CUDA preprocessor definition and its stale synchronization comment.
- Extend the existing validation tests and GPU-pointer tests to cover the missing paths.
- Leave the AMD Triton 32-qubit phase-kernel restriction and pipeline
MAX_DEPTH unchanged because
they represent separate implementation constraints.
Runtime capacity planning based on device memory, precision, and batch footprint is intentionally
out of scope for this cleanup and should be tracked in a follow-up issue.
This issue is complete when all amplitude encoding entry points reject zero or above-limit qubit
counts through the shared validator before shifts or GPU work, the duplicate CUDA definition is
removed, and focused CUDA plus no-CUDA verification passes.
What
QDP defines a shared Rust
MAX_QUBITSpolicy, but some amplitude encoding paths do not apply theshared
validate_qubit_countcheck before computing2^num_qubits:At the same time,
qdp-kernels/src/kernel_config.hcontains a secondMAX_QUBITSdefinition thatis not used by any CUDA kernel.
Centralize the current static policy by making the Rust constant the single effective source and
applying its validator consistently at every amplitude encoder boundary.
Why
Missing validation allows excessive values to reach
1 << num_qubits, which can panic on shiftoverflow or continue into an impractical allocation instead of returning the established
MahoutError::InvalidInput. The unused CUDA definition also creates a maintenance risk because itcan drift from the Rust policy without affecting kernel behavior.
Consistent validation gives CPU-data and GPU-pointer callers the same predictable error behavior
without changing valid encoding requests.
How
validate_qubit_count(num_qubits)before state-length calculations in every uncoveredamplitude f32 batch and GPU-pointer path.
qdp_core::gpu::encodings::MAX_QUBITSas the shared static policy.MAX_DEPTHunchanged becausethey represent separate implementation constraints.
Runtime capacity planning based on device memory, precision, and batch footprint is intentionally
out of scope for this cleanup and should be tracked in a follow-up issue.
This issue is complete when all amplitude encoding entry points reject zero or above-limit qubit
counts through the shared validator before shifts or GPU work, the duplicate CUDA definition is
removed, and focused CUDA plus no-CUDA verification passes.