[maleadt]

The scan kernels each wrote out the same tile steps, CUB's BlockLoad / BlockScan / BlockStore: a striped load of the tile, a scan of each thread's run, a block-wide scan of the threads' totals, applying the prefix (inclusive or exclusive), and a striped store. The whole-array scan, the scan of tiles along dims and findall each had their own copy, and the serial scan loop appeared four times (threaded scans, and the kernels that give a thread a whole slice). findall also had its own count pass, which staged each tile in local memory, where the scans' tile reduction reads each thread's run straight from memory and uses sub-group scans.

Now the tile steps are device functions in block.jl that all three kernels use, each kernel keeping its own operand and carry order (so floating-point results don't change), one serial_scan! serves the host and the kernels, and findall counts its selections with the scans' tile reduction and only scatters in its own kernel, with Int32 per-thread counts that take half the local memory. Generated code of the scan kernels is identical to before on CUDA and AMD, except for operators without a neutral element, which run at the same speed.

Running whole-array scans through the slice machinery as a single slice was measured too and rejected: 3-27% slower from 10^4 elements up on an RTX 5080 (10^8 Float32s: 1794 vs 1418 µs); a comment says so.

Three older performance problems turned up and are fixed in their own commits:

• The bitonic sort's compare-exchange didn't propagate @inbounds, so it kept its bounds checks: bitonic sorts are 11-13% faster on CUDA and 20-32% on AMD and Apple GPUs.
• Kernels that only pass a function argument on aren't specialized on it by Julia, so CUDA.jl specialized nine reduction kernels and the merge sorts again on every launch (methodinstance re-specializes on every lookup when the dispatch cache holds a widened method instance GPUCompiler.jl#1060). They now name those argument types, which takes 2-6% off small reductions, and a test checks that no kernel's specialization is widened.
• A comment records why the block scan keeps its bounds checks: eliding them raises the register count of the slice carry pass from 64 to 101 and makes a (2, 10^7) scan along dims=2 72% slower.

Performance, as the geometric mean of new over old times (min of interleaved rounds): scans and findall 1.006 on an RTX 5080, 0.954 on an AMD iGPU, 1.005 on PoCL, 0.941 on an M1. Large findalls with many selections are faster everywhere (10^7 elements, 50% selected: 181 → 177 µs on the 5080, 15.2 → 10.7 ms on the iGPU, 4.3 → 3.6 ms on the M1). One cost: on CUDA, findall calls of a few tens of microseconds take 1-2 µs longer, as the second kernel's construction does not infer with KernelAbstractions 0.9, which CUDA.jl still requires; with 0.10 it does, and those calls are faster on the other backends.

Tested on CPU threads, PoCL (also with AK's kernels on the host backend), CUDA (Julia 1.12 and 1.10), AMDGPU and Metal.