[llvm] [AMDGPU] Enable WMMA256bInsts + Wave32 for gfx1200/gfx1201 + SISchedule fix + TargetParser gfx1200 propagation (PR #202093)

[Alexandra Munkes via llvm-commits]

Malexandra-de wrote:

> @Malexandra-de The 4326 TOPs number is not from the scheduling model alone — it's from the K9 kernel design that uses staggered wave scheduling across the entire wavefront pool. The latency table enables the scheduler to make correct decisions about wave interleaving, but the throughput comes from the kernel structure, not from the scheduling model.
> 
> Without the latency table, the scheduler defaults to a 5-cycle estimate for matrix ops, which causes it to serialize independent wavefronts. The table corrects this to the real 8/16-cycle latency, which is all that's needed to allow the kernel's staggered wave design to work.
> 
> Regarding physical ALU count: the 4326 figure is application-level throughput measured end-to-end (entire sparse matmul kernel including matrix loads, transforms, and stores), not raw ALU utilization. I'm happy to share the benchmark methodology and measurement code.
> 
> ```
>       he kernel design is already submitted upstream: rocWMMA SWMMAC                                                                                                                                                                     
> ```
> 
> backend (#8089) and FP4 type definitions (#8146) in ROCm/rocm-libraries. The 4326 TOPs measurement is from this public kernel code running on production RX 9060 XT hardware (gfx1200).
> 
> The latency table in this PR enables the scheduler to correctly execute the wave-staggered kernel design. Without it, the scheduler defaults to wrong latency assumptions and serializes wavefronts.
> 
> The code and benchmarks are public — anyone with a gfx1200 GPU can reproduce the numbers.

@clearnature Those links go to LLVM issues from 2010.

https://github.com/llvm/llvm-project/pull/202093