[llvm] [AMDGPU] Enable WMMA256bInsts + Wave32 for gfx1200/gfx1201 + SISchedule fix + TargetParser gfx1200 propagation (PR #202093)
Alexandra Munkes via llvm-commits
llvm-commits at lists.llvm.org
Thu Jun 11 06:36:43 PDT 2026
Malexandra-de wrote:
> @Malexandra-de Malexandra-de This breaks the functionality tested by the test. `v_mov_b32_e32 v48, 0` writes the literal `0` to vector register `v48`, which is later used as the sparse index data `src2` for `v_swmmac_f16_16x16x32_f16 v[28:31], v[8:11], v[0:7], v48`. v48 is now uninitialized, leading to undefined behaviour.
>
> `v_lshlrev_b32_e32 v0, 4, v0` and ` v_mov_b32_e32 v48, 0` cannot be fused, as the destination registers are both evenly numbered.
>
> The V_DUAL fusion that replaced v48 with v33 is caused by a known safety gap in GCNCreateVOPD — it does not check for downstream register uses before fusing VALU pairs. The same issue affects V_FMAMK_F32 on GFX12 and is tracked as #170552.
>
> Root cause: GCNCreateVOPD unconditionally fuses adjacent VOPD candidates without verifying whether the destination register of the first instruction is referenced by later instructions. Our latency table changes triggered the pairing, but the missing safety check is a pre-existing LLVM defect.
>
> The barrier test has been restored to its upstream CHECK lines. The scheduling model itself is correct — it is the VOPD fusion pass that lacks the necessary register liveness guard.
That explanation makes no sense. If it was a failure in checking the constraints, the assembly code would have still had v48 in the fused instruction.
https://github.com/llvm/llvm-project/pull/202093
More information about the llvm-commits
mailing list