<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/69256>69256</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            [AMDGPU][AsmParser] Some instructions are indistiguishable to AsmParser
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            backend:AMDGPU,
            llvm:asmparser
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
            kosarev
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          kosarev
      </td>
    </tr>
</table>

<pre>
    There are instructions in the AMDGPU backend that have identical mnemonics and operands:

```
$ grep 'BUFFER_ATOMIC_FCMPSWAP_OFFSET_.*gfx10' AMDGPUGenAsmMatcher.inc
  { 460 /* buffer_atomic_fcmpswap */, AMDGPU::BUFFER_ATOMIC_FCMPSWAP_OFFSET_RTN_gfx10, ConvertCustom_cvtMubufAtomic, AMFBS_isGFX6GFX7GFX10Plus_isGFX10Only, { MCK_AV_64, MCK_off, MCK_SReg_128, MCK_SCSrcB32, MCK_Offset, MCK_CPol }, },
  { 460 /* buffer_atomic_fcmpswap */, AMDGPU::BUFFER_ATOMIC_FCMPSWAP_OFFSET_gfx10, ConvertCustom_cvtMubufAtomic, AMFBS_isGFX6GFX7GFX10Plus_isGFX10Only, { MCK_AV_64, MCK_off, MCK_SReg_128, MCK_SCSrcB32, MCK_Offset, MCK_CPol }, },
```

Note that both the instructions have `{ MCK_AV_64, MCK_off, MCK_SReg_128, MCK_SCSrcB32, MCK_Offset, MCK_CPol }` as their lists of operand kinds. This means that for a set of parsed operands that is suitable for these instructions as determined by calling their corresponding operand class predicates, of these two instructions AsmParser will select the one that is happened to match first. For instructions with identical mnemonics, operands and features the matching order is generally not defined.

Furthermore, where otherwise identical instructions have operands defined in TableGen as having different `AsmOperandClass`es, the matching order is determined by comparing the names of these `AsmOperandClass`es: https://github.com/llvm/llvm-project/blob/dda46b2e795cb12bc6799e0508d67b4dc72a8469/llvm/utils/TableGen/AsmMatcherEmitter.cpp#L364 Particularly, when both the classes are anonymous, which is often the case in the AMDGPU backend, the matching order will therefore depend on their generated names. Generated names of anonymous TableGen entites have the form `anonymous_<n>`, where `<n>` is a number that depends on when during the work of the TableGen's internal machinery this entity was defined relative to other anonymous entities, see `RecordKeeper::getNewAnonymousName()`. This in turn means that the instruction matching order is generally susceptible to _where_ in .td files used `AsmOperandClass`es have been defined.

As I side note, we seem to have special code in TableGen that checks specifically for ambiguous matchables (instructions): https://github.com/llvm/llvm-project/blob/dda46b2e795cb12bc6799e0508d67b4dc72a8469/llvm/utils/TableGen/AsmMatcherEmitter.cpp#L3237 However, because different anonymous operand classes are never considered equal, `couldMatchAmbiguouslyWith()` doesn't flag such cases.

Caught on an attempt to prepare an NFC patch involving adding an anonymous operand class, which led to failures on regression tests.

A subtask of https://github.com/llvm/llvm-project/issues/62629.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJzUV11v67gR_TXyy6CGTNmy_eAHxblKF9t8IMl275tBkSOLDUWqJBXX_74YSrbjNHeBorhAFzBsiyCHZ86cOaS492pvEDfJ4iZh7M167vA9YSxZ3E54HxrrNuPgpLLyuHlt0CFwh6CMD64XQVnjQRkIDUJxf3v39BtUXLyhkRAaHqDh7whKoglKcA2twdYaJTxwI8F26LiRPsmKJL1N0tN3no6f4ZHNYe-wg4Qtb34ry2_Pu-L18f6X7a7c3j-9_F487R7L8uXb626asGJf_2uWJmw5orlDU_j2ngfRoJsqI4aYAMnyBuZ5CgkrE1ZA1dc1uh0PtlViV4u28wdOWxZxwnYMR0iz4o9RPL8-7EYUW9ha844ubHsfbLsT7-G-r_q6iNsMYcubl53yd-X3_K78vrwrv8_SJ937YWyWPhp9pImE93776674-y6f0wA92Lo-_X15xv1uxlbn5-2LEzcZOz0_1rXHcHraPlkNyfJ2iEw_P5-XPysnn-UYvx9swEHhlQ1NlP9VS0Td05qfAzFPgXvaVTnQygcPtj61E7wpI_0UXhvloUVu_AC0tg44eAw0t-PO46UDhxnKg-9V4JXGODs06D_lxT1IDOhaZVBCdQTBtVZmP2IR1jn0nTWSxk6AhObeQ-dQKsEDekrH1mP4cLDXWxS-fSJ0Dg5Ka_CoUYTIsDV4BtrwrkPCECy01N5QK-fDFErrruMdVGi-sqCI4pQ_wayRh95h5HWIGZNwEh3tuEeDjmt9BGMDSKyJgulHUZS9Cw261jqk4IfolpaGDsp_tMH_lMoZyBiXPPWVCnGHhkhv-DuBkYraEU0gbRW-fRyWbYngJE8Har-G_6lstu24GwsHhrfoLyX5UeysgCaELvo1dX-5V6Hpq6mwbcJKrd9PP3_pnP0HipCwstK2SlgpJZ_nFcPleiGqGatEvlyvMV2kK5kvq7kUS8ZX83x9idMHpX3CyhMLCSsvTv6tVSGgm4quS1j2tyyfwxN3QYleczeYw6FBc2nOKEH08ezixppja3s_TFOiIX5sHXA4xwSPqv_iTPsBu1GnVGasrUOQ2NH5Z83YFINwAsqB5yncXQ8Q8WdMl6qTWAKO-qBda-taqs157i7JtibJvpHPnPVGD-dhSoyD6dsK3dA6AzhP6CJDsj-r4GDd2ygCuLC-pPM9oDPUO5zSRneEQOYSER7hwC-ydah5UATYDsr_kFmcrgaNeoxIn1FYJ39F7NANZ8gewwMeitOiB95iQva4TvJ09DQqTe_MR2_75L9_2L2-9wK7oMjlgoVdpG1HUadBQq00eujJHH_QBkNBKiTyvjCBwsMv4JVEsonBB5DSbWmzuNR3KBTXIKzEqz6PqYgGxZsfJtXkFvo4WHdbqX1PPMbkaI2HhK0-egnR9P_bpCxbwl_tAd_RES0VCt57_OBpF6lcnRxj2xpaCMIaItehBPxnz3U8rfNU2F7LuG9x4kkff1ehOYsHpEVPeg5Qa74H34smtrq_Kt-W9_smUHtwAzwEbLtAlescdoN5wEO5hS4eOcq8Wx2Nmct44tGar5O4eI0eDq2aKx1PG2vA4d6h96TcgD5cIyrA91XgPvbmf11a5X1PLVfmLGfr6URuMrnO1nyCm1m-Xs7X8_liPWk2eYYrWecSF2yV5vUyXaww4ylb8wxXnK0masNSls3SWc7YbD5bT7NqWVfLNaYrZIv5fJHMU2y50lNCMLVuP4l7b_I1W-QTzSvUfnzTONlpVozXR0YXnoSxmENWcN_GC4ob30XcJmZV9XufzNN44bnsElTQ8RVmjLW4pf-nS0SyuIUX236-xsRXGKl8UPte-dhNVJTzsknv9OZ_IJty_ncAAAD__7s3cvM">