[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 SWMMAC and VALU share the same issue slot — that much is correct per the ISA documentation. However, our scheduling model does not assume VALU instructions execute concurrently with SWMMAC. It describes the total occupancy of the ALU pipeline while a SWMMAC instruction is in flight.
> 
> The key distinction:
> 
> Instruction-level overlap (wrong): SWMMAC + VALU execute in parallel Wave-level staggering (correct): SWMMAC occupies XDL for N cycles; other wavefronts fill ALU slots during that window
> 
> Our latency table assigns HWVALU occupancy to WMMA instructions because the ALU issue slot is blocked for the duration of the SWMMAC — it cannot issue another VALU in the same wave. The scheduler uses this information to stagger wavefronts: while wave A's SWMMAC holds the XDL pipeline, wave B's independent VALU work fills the otherwise-idle ALU slots.
> 
> This is why K9 achieves 4326 TOPs vs the baseline 518 TOPs — not from instruction-level parallelism, but from the scheduler knowing how long the ALU slot is unavailable per wave and filling it with work from other waves.
> 
> The HWXDL entries alone (which gfx1250 already has) only describe the matrix pipeline. The HWVALU entries describe the ALU pipeline occupancy that prevents the same wave from dual-issuing — which is exactly what the ISA describes as "hardware may stall."

@clearnature You seem to be under a fundamental misunderstanding of the way the hardware works. WMMA instructions on gfx12 block VALU executiona across waves, since they are running on the regular VALUs and the additional Matrix Multiplication hardware. During the execution of a WMMA instruction, there is no execution of VALU instructions from other waves. You can still execute SALU, VMEM, and LDS instructions, but no VALU.

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