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
f8153d492a