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.
