CDNA4 ISA guide: DPP on integer reversed ops selects the second source on MI350 #9893

On MI350 (gfx950), a DPP lane control on nine integer reversed VOP2 instructions selects lanes of the second source (VSRC1). Section 13.3.9 of the CDNA4 ISA reference guide, Table 94, writes every lane select as pix[n].srca, which is the first source. The other integer DPP instructions that were checked follow that table.

The PDF is amd-instinct-cdna4-instruction-set-architecture.pdf, dated 5 August 2025. The nine instructions are in section 12.7:

• V_SUBREV_U32, V_SUBREV_CO_U32, V_SUBREV_U16
• V_LSHLREV_B32, V_LSHLREV_B16
• V_LSHRREV_B32, V_LSHRREV_B16
• V_ASHRREV_I32, V_ASHRREV_I16

For these, lane n computes op(S0[n], S1[sel(n)]). Table 94 describes op(S0[sel(n)], S1[n]). V_SUBREV_F32 follows Table 94.

What was measured

On an MI350X, a full wave of 64 threads, with distinct values per lane. Each instruction was run as e32, as e64, and with these DPP controls: quad permute, row and wave shifts and rotates, row mirror, row half mirror, row broadcast, and row_newbcast, including bounds control on the shifts. For the nine instructions, every defined lane matched the second-source select. The e32 and e64 forms with no DPP control matched the instruction definitions. The same nine failed the same way on a second MI350X.

This silicon run was not repeated while filing this issue.

Compiler impact

hipcc in ROCm 7.0.2 and ROCm 10.1.0 folds a DPP move into these opcodes at -O3. A subtraction or shift of a DPP-moved value then uses the neighbor lane on the wrong source: at -O3, 64 of 64 lanes are wrong; at -O0, the compiler keeps a separate v_mov_b32_dpp and 0 of 64 lanes are wrong. The same pair of results was seen with both compilers.

ROCm 10.2 leaves that move separate. Checked with the 10.2 compiler on MI350, the result matches Table 94.

Upstream LLVM stopped the fold in 6dd22919138a (8 September 2026). The commit message says the reversed subtractions have always worked this way, and the reversed shifts worked this way before GFX11. GFX11 is RDNA3, so CDNA4 (gfx950) is in the affected set for both.

Requested change

Add an erratum to section 13.3.9, and a line on each of the nine instructions in section 12.7, saying that on this architecture DPP selects lanes of the second source. Leave Table 94 as it is for every other instruction.

Not part of this report

• V_SUBBREV_CO_U32 (LLVM's V_SUBBREV_U32) and the 64-bit reversed shifts (V_LSHLREV_B64, V_LSHRREV_B64, V_ASHRREV_I64). LLVM's SIInstrInfo::isSrc1DPPRevOpcode lists these with the nine above on pre-GFX11 targets, so they may be affected too. They were not part of the MI350 measurement, so this report does not claim them.
• The VOP3 opcode numbering error in Table 85. That is a separate guide error: CDNA4 ISA guide: VOP3 opcodes of all 85 VOP1 instructions are 64 too high #9892
• A change to the compiler. ROCm 10.2 already avoids the fold. The guide is what still needs the exception.