[Bug gas/30317] .insn directive did not swap sources

[jbeulich at suse dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30317

Jan Beulich <jbeulich at suse dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #2 from Jan Beulich <jbeulich at suse dot com> ---
(In reply to Haochen Jiang from comment #0)
> For the current AMX and AMX-FP16 bad testcases, we got testcases like this:
> 
>         #tdpfp16ps %tmm5,%tmm4,%tmm3 set VEX.W = 1 (illegal value).
>         .insn VEX.128.F2.0F38.W1 0x5c, %tmm4, %tmm5, %tmm3
>         .fill 0x05, 0x01, 0x90
> 
>         #tdpfp16ps %tmm5,%tmm4,%tmm3 set VEX.L = 1 (illegal value).
>         .insn VEX.256.F2.0F38.W0 0x5c, %tmm4, %tmm5, %tmm3
>         .fill 0x05, 0x01, 0x90
> 
> The operand order is reversed for operand 2 and 3.

And intentionally so.

> I did not fully root cause the reason but I guess the highest possibility is
> the AMX instructions are using SwapSources which swaps operand 2 and 3.

SwapSources can only sensibly be present / in use for real insn templates.
.insn has to assume some specified ordering of operands, no matter what order
they ought to be in for the real (properly mnemonic-ized) insn. Please read the
documentation, which specifically states this aspect.

Of course syntax of .insn could be extended to allow specifying such, but I'm
afraid that would become unwieldy, because _all_ possible permutations would
then need to be expressable.

-- 
You are receiving this mail because:
You are on the CC list for the bug.