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

[via llvm-commits]

clearnature wrote:

@Malexandra-de @krzysz00  The V_DUAL instruction fusion occurring in the barrier test is caused by a known VOPD safety issue (llvm/llvm-project#170552). `GCNCreateVOPD` fails to verify downstream register usage before performing the fusion—mirroring the issue that affects `V_FMAMK_F32`.

I have reverted the barrier test to the upstream CHECK line configuration. There is nothing wrong with the scheduling model entries themselves; while they trigger instruction pairing, the missing safety check logic belongs in the VOPD pass, not in `SISchedule`.

Regarding issue #170552 (involving SP3 structured initializers/documentation), AMD's internal policy treats this as a known limitation rather than a defect requiring a fix at the LLVM level. I have adopted the same strategy: keeping the scheduling model as-is while avoiding test cases that trigger the issue.
AMD's approach:

Direction 1: Documentation + Non-standard operand support

· Document VOPD limitations in tables
· Do not fix `GCNCreateVOPD`—mark as a "known limitation"

Direction 2: SP3 structured initialization syntax

· `s_set_vgpr_msb { src0_msb: 2, dst_msb: 1 }`
· Use high-level syntax to avoid associated register conflicts—handled by upper-level tools; do not modify downstream passes

Neither direction involves fixing an LLVM defect; AMD has chosen a workaround.
We are the authors submitting the PR, not LLVM maintainers. VOPD safety issue. LLVM architectural flaws:
Post-RA scheduler → Lacks vreg liveness information (explicitly noted in GCNSchedStrategy)
VOPDPairingMutation → Greedy pairing; does not check downstream references
GCNCreateVOPD → Unconditional fusion; lacks safety checks
AMDGPULowerVGPREncoding → Assertion triggered only in Debug builds

Known precedents:
Issue #170552 — Similar issue involving V_FMAMK_F32
Mesa3D ACO 25.1.0 — Fixed (WaR check implemented)

No existing fix available anywhere:
Scheduling model + VOPD interaction — Zero PRs addressing this. 
This is an architectural issue regarding LLVM's VOPD safety; there is nothing I can do about it.

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