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

[via llvm-commits]

clearnature wrote:

@krzysz00 @Malexandra-de  I understand your question regarding the scheduling latency data; the figures provided by hardware vendors do not reflect real-world conditions. We rely on community-sourced data for calibration; without specific ALU-side data, the compiler is forced to make arbitrary guesses. Providing the correct data ensures proper execution. The use of scheduling latency tables is not a new method we invented—though I am unsure why they weren't used previously.
First point: Benchmark data:
Same hardware, same benchmark, O2 compilation, verified SWMMAC execution:

ROCm 7.13 (System):  19.2 ms        No latency table
LLVM 23 (Ours):      14.4 ms        With latency table

LLVM 23 is 25.0% faster.
Note: The compiler version used in ROCm 7.13 differs from the one used for LLVM 23. Specifically, the ROCm 7.13 compiler version is 23.0 (upgraded from a stable 22.x release), a detail worth noting.
Testing: We took a simple SWMMAC micro-benchmark and compiled it twice (with and without the latency table). A comparative analysis using `llvm-mca` highlights the differences in scheduling cycles, IPC, and instruction overlap. Real-world data comparison—using an existing upstream test file:

wmma-gfx12-w32.ll (upstream test, not authored by us):

Compiler output (LLVM 23 + our latency table):
V_DUAL instructions: 21 ← Scheduler utilizes Waves32 dual-issue
s_delay_alu:         10 ← Scheduler correctly marks WMMA latency

Upstream CHECK (old scheduler, no latency table):
V_DUAL expected:     36 ← Higher count, but likely suboptimal
s_delay_alu:         22 ← More stalls

Chain of evidence:

No latency table → Unknown SWMMAC cost → Excessive conservative s_delay_alu stalls → Reduced throughput
With latency table → Exact 8/16-cycle latency known → Correct V_DUAL + s_delay_alu usage → Increased throughput
Source file saved at PR's test: llvm/test/tools/llvm-mca/AMDGPU/gfx1200-swmmac-latency.s
Visible when running llvm-mca.
We used the system default LLVM-22 (without latency table) and LLVM-23 (with latency table). Tests included wmma-gfx12-w32.ll (pure SWMMAC, no mixed VALU) and a barrier test (mixed SWMMAC + VALU).
Test data for wmma-gfx12-w32.ll (pure SWMMAC, no mixed VALU). First:
wmma-gfx12-w32.ll (pure SWMMAC, no mixed VALU):
Total Cycles:      7262 vs 7262    ← 0% difference
IPC:               0.01 vs 0.01
Block RThroughput: 224.0 vs 224.0
→ Latency table has no impact on pure SWMMAC (expected)
Also ruled out the influence of llvm-22 and llvm-23 on the data.
Second:
barrier test (SWMMAC + VALU mixed)

barrier test (SWMMAC + VALU mixed):
Total Cycles:      376  vs 372     ← -1.1%
IPC:               0.25 vs 0.25
Block RThroughput: 110  vs 113     ← +2.7%
V_DUAL:            17   vs 21      ← +23%
s_delay_alu:        7   vs 10      ← +43%
→ Latency table improves scheduling density.

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