[Perf] Add portable subgroup reduce_add and reduce_all_add

[hughperkins]

Portable subgroup reduce_add / reduce_all_add (replaces SPIR-V-only no-arg reductions)

Builds on hp/shuffle-down's portable subgroup.shuffle_down to add cross-platform
sum reductions, and removes the SPIR-V-only no-arg subgroup reductions for
consistency.

What's in this PR

New API: portable sized sum reductions

• subgroup.reduce_add(value, log2_size) — sums value across 2**log2_size
  consecutive lanes via a shuffle_down tree. Result valid in lane 0 of each
  group; other lanes hold partial sums.
• subgroup.reduce_all_add(value, log2_size) — same sum, broadcast to every
  lane via a shuffle butterfly (lane ^ mask).
• Both are decorated with @qd.func and inlined; log2_size is a
  qd.template() (compile-time constant) so the body unrolls into exactly
  log2_size shuffle+add pairs in the calling kernel's IR.
• Caller contract: 2**log2_size must not exceed the active subgroup size
  (32 on CUDA / Metal / RDNA, 64 on CDNA).
• Works on i32 / u32 / f32 / f64 / i64 / u64 across CUDA, AMDGPU, and SPIR-V.
  Removed: SPIR-V-only no-arg reductions
• subgroup.reduce_add(value) (no log2_size), reduce_mul, reduce_min,
  reduce_max, reduce_and, reduce_or, reduce_xor — all gone.
• C++ side: dropped the subgroupAdd / subgroupMul / ... ops from
  internal_ops.inc.h, their POLY_OP signatures in type_system.cpp, and
  the reduction_ops set in spirv_codegen.cpp (the dispatch branch now
  handles inclusive_scan_ops only, with group_op fixed to
  InclusiveScan).
• Inclusive scans (subgroup.inclusive_*) are intentionally untouched — they
  are a different primitive (prefix scan, not reduction) and remain
  SPIR-V-only pending their own portable replacement.
  Tests
• Removed the old Vulkan-only test_subgroup_reduction_* tests and the
  _test_subgroup_reduce helper.
• Added parametrised test_subgroup_reduce_add and
  test_subgroup_reduce_all_add covering log2_size ∈ {1, 2, 3, 4, 5} and
  dtypes {i32, f32, f64} on arch=qd.gpu (so all backends).
  Docs
• Extended docs/source/user_guide/subgroup.md (renamed page title to
  "Subgroup primitives") with: support-matrix rows for both new ops,
  semantics sections covering the log2_size template + size-cap contract
  and the lane-0-only vs all-lanes guarantees, worked sum32 / normalize32
  / partial-subgroup examples, performance notes, and a note explaining that
  the SPIR-V-only no-arg reductions have been removed.
• Build-time housekeeping: replaced the blanket # type: ignore on
  subgroup.py with a targeted # pyright: reportInvalidTypeForm=false
  (needed for the template() annotation form, mirroring _tile16.py).

Good points

• Single portable API for the by-far most common reduction (sum). No
  more arch=qd.vulkan carve-outs in callers — reduce_add runs on CUDA,
  AMDGPU, and SPIR-V from the same source.
• Zero kernel-launch / linkage overhead. @qd.func inlining + static
  range unrolling means the generated IR is byte-equivalent to a
  hand-written shuffle tree — no extra calls, no runtime loop.
• Better than the old SPIR-V API in two ways: the caller chooses the
  reduction width via log2_size, and reduce_all_add (butterfly) saves a
  follow-up broadcast when every lane needs the result.
• Strictly fewer C++ surfaces to maintain: 7 ops removed from the
  internal ops table, the SPIR-V reduction_ops set, and the type system.
• Type-checking is tightened — blanket # type: ignore on subgroup.py
  is gone; only the one template()-related warning is suppressed.
• Tests are parametrised across log2_size and dtypes, replacing two
  Vulkan-only tests with portable coverage.

Bad points / caveats

• Breaking change. subgroup.reduce_add(value) (no second arg) and
  reduce_mul / min / max / and / or / xor are gone — any
  caller has to switch to either reduce_add(value, log2_size) or build
  their own sized helper on top of shuffle_down / shuffle. (Codebase
  audit showed no in-tree callers; external users will need to adapt.)
• No portable replacement for reduce_mul/min/max/and/or/xor yet. This
  PR removes the SPIR-V-only path for consistency but only ships the add
  variants. If you need product/min/max reductions on CUDA or AMDGPU
  today, you have to write the shuffle tree yourself for now.
• AMDGPU reduce_add performance is currently middling. It rides on
  shuffle_down, which on AMDGPU goes through ds_bpermute (LDS-routed,
  tens of cycles). A native DPP fast path is a future PR.
  reduce_all_add is unaffected — it only uses shuffle, which is native
  on AMDGPU.
• No size-cap enforcement at trace time. Passing log2_size=6 on a
  32-lane subgroup compiles fine and silently produces wrong results in the
  lanes that read past the end — only documented in the docstring, not
  asserted. Could add a compile-time check later.
• Tests don't cover i64 / u64. Parametrisation is {i32, f32, f64};
  64-bit integer reductions go through the same shuffle path but are
  untested in this PR. [fixed]
• inclusive_* scans are still SPIR-V-only — they are out of scope here
  but the inconsistency is now more visible (sum reduction is portable,
  sum prefix-scan is not).

Risk

• Low-risk on the C++ side: deletions only, plus a one-line group_op
  simplification in spirv_codegen.cpp. Full tests/python/test_simt.py
  passes (69 passed, 1 skipped) and pyright is clean (0/0/0) on
  subgroup.py.
• Higher risk for downstream callers using the removed no-arg API; expect
  to break out-of-tree consumers.

Follow-ups

• Add portable reduce_mul / reduce_min / reduce_max (and integer
  reduce_and / or / xor) using the same log2_size template
  pattern, when needed.
• AMD DPP ROW_SHR fast path for shuffle_down (will accelerate
  reduce_add on AMDGPU automatically).
• Cover i64 / u64 in the parametrised tests.

Issue: #

Brief Summary

copilot:summary

Walkthrough

copilot:walkthrough

[duburcqa]

Scalar i64 types and arithmetic (long, ulong, int64_t, uint64_t): Available on every M-series chip from M1 onward. MSL has had them since 2.2, and all Apple-silicon Macs meet that. But Apple GPUs have no native 64-bit integer ALU — the compiler lowers these to sequences of 32-bit ops. Typical costs are roughly 2× for add/sub, ~4× for multiply, and noticeably worse for division. Fine for address math, hashing, bit-packing, and any code where i64 is a small fraction of the work. Painful if i64 is in your hot inner loop.

64-bit buffer addressing: All M-series have it; pointers into buffers are effectively 64-bit. This is what lets you cast buffer arguments to device ulong* and index past 4 GB.

[erizmr]

Approving on the basis that I have reviewed the design and the public facing API, tests, and they look reasonable to me.