f8153d492a
Critical finding: scan and reduce have fundamentally different SMEM models. Scan uses BlockLoad/BlockStore with WARP_TRANSPOSE which puts tile data through SMEM (threads*items*type_size bytes). Reduce keeps tile data in registers and only uses SMEM for BlockReduce communication (~threads*4 bytes). This means: - Our SMEM constraint is CORRECT for scan (tuning_scan.cuh values are properly bounded) - Our SMEM constraint is WRONG for reduce (tuning_reduce.cuh could use larger items_per_thread, especially for small types) - The same check_smem() function should NOT be used for both algorithms Source: cccl_upstream/cub/cub/agent/agent_scan.cuh _TempStorage union