[PATCH 1/6] Support Intel AMX-TRANSPOSE

Jiang, Haochen haochen.jiang@intel.com
Tue Nov 19 03:03:30 GMT 2024


> From: Jan Beulich <jbeulich@suse.com>
> Sent: Friday, November 15, 2024 9:40 PM
> 
> > --- /dev/null
> > +++ b/gas/testsuite/gas/i386/amx-transpose-inval.l
> > @@ -0,0 +1,12 @@
> > +.* Assembler messages:
> > +.*:6: Error: `ttdpbf16ps' is only supported in 64-bit mode
> > +.*:7: Error: `ttdpfp16ps' is only supported in 64-bit mode
> > +.*:8: Error: `ttransposed' is only supported in 64-bit mode
> > +.*:9: Error: `t2rpntlvwz0' is only supported in 64-bit mode
> > +.*:10: Error: `t2rpntlvwz0t1' is only supported in 64-bit mode
> > +.*:11: Error: `t2rpntlvwz1' is only supported in 64-bit mode
> > +.*:12: Error: `t2rpntlvwz1t1' is only supported in 64-bit mode
> > +.*:13: Error: `tconjtcmmimfp16ps' is only supported in 64-bit mode
> > +.*:14: Error: `tconjtfp16' is only supported in 64-bit mode
> > +.*:15: Error: `ttcmmimfp16ps' is only supported in 64-bit mode
> > +.*:16: Error: `ttcmmrlfp16ps' is only supported in 64-bit mode
> 
> I question the value of this test (and similar ones, especially when the base
> feature already isn't permitted outside of 64-bit mode).

We could remove that. It is maybe too obvious for a test.

> 
> > --- /dev/null
> > +++ b/gas/testsuite/gas/i386/x86-64-amx-transpose.d
> > @@ -0,0 +1,31 @@
> > +#objdump: -dw
> > +#name: x86_64 AMX-TRANSPOSE insns
> > +
> > +.*: +file format .*
> > +
> > +Disassembly of section \.text:
> > +
> > +0+ <_start>:
> > +\s*[a-f0-9]+:\s*c4 e2 5a 6c f5\s+ttdpbf16ps %tmm4,%tmm5,%tmm6
> > +\s*[a-f0-9]+:\s*c4 e2 72 6c da\s+ttdpbf16ps %tmm1,%tmm2,%tmm3
> > +\s*[a-f0-9]+:\s*c4 e2 5b 6c f5\s+ttdpfp16ps %tmm4,%tmm5,%tmm6
> > +\s*[a-f0-9]+:\s*c4 e2 73 6c da\s+ttdpfp16ps %tmm1,%tmm2,%tmm3
> > +\s*[a-f0-9]+:\s*c4 e2 7a 5f f5\s+ttransposed %tmm5,%tmm6
> > +\s*[a-f0-9]+:\s*c4 e2 7a 5f da\s+ttransposed %tmm2,%tmm3
> > +\s*[a-f0-9]+:\s*c4 a2 78 6e b4 f5 00 00 00 10\s+t2rpntlvwz0
> > +0x10000000\(%rbp,%r14,8\),%tmm6
> > +\s*[a-f0-9]+:\s*c4 c2 78 6e 14 21\s+t2rpntlvwz0 \(%r9,%riz,1\),%tmm2
> > +\s*[a-f0-9]+:\s*c4 a2 78 6f b4 f5 00 00 00 10\s+t2rpntlvwz0t1
> > +0x10000000\(%rbp,%r14,8\),%tmm6
> > +\s*[a-f0-9]+:\s*c4 c2 78 6f 14 21\s+t2rpntlvwz0t1
> > +\(%r9,%riz,1\),%tmm2
> > +\s*[a-f0-9]+:\s*c4 a2 79 6e b4 f5 00 00 00 10\s+t2rpntlvwz1
> > +0x10000000\(%rbp,%r14,8\),%tmm6
> > +\s*[a-f0-9]+:\s*c4 c2 79 6e 14 21\s+t2rpntlvwz1 \(%r9,%riz,1\),%tmm2
> > +\s*[a-f0-9]+:\s*c4 a2 79 6f b4 f5 00 00 00 10\s+t2rpntlvwz1t1
> > +0x10000000\(%rbp,%r14,8\),%tmm6
> > +\s*[a-f0-9]+:\s*c4 c2 79 6f 14 21\s+t2rpntlvwz1t1
> > +\(%r9,%riz,1\),%tmm2
> 
> With what I said above, the use of %tmm3 in the source file should result
> in %tmm3 being displayed here. As mentioned in the series extending the
> group handling, we ought to think about how to express odd registers in
> disassembly. Ideally that would happen before the issue is widened by this
> introducing further instances.

I also realized that when I trying to reuse the ImplicitGroup. I will change them
to even numbers in valid test and add invalid test for warning in next version of
patch.

> 
> > --- a/opcodes/i386-opc.tbl
> > +++ b/opcodes/i386-opc.tbl
> >
> > +t2rpntlvwz0, 0x6e, AMX_TRANSPOSE,
> > +TMMPairOperand1|Sibmem|Vex128|Space0F38|VexW0|NoSuf, {
> > +Unspecified|BaseIndex, RegTMM } t2rpntlvwz0t1, 0x6f, AMX_TRANSPOSE,
> > +TMMPairOperand1|Sibmem|Vex128|Space0F38|VexW0|NoSuf, {
> > +Unspecified|BaseIndex, RegTMM } t2rpntlvwz1, 0x666e,
> AMX_TRANSPOSE,
> > +TMMPairOperand1|Sibmem|Vex128|Space0F38|VexW0|NoSuf, {
> > +Unspecified|BaseIndex, RegTMM } t2rpntlvwz1t1, 0x666f,
> AMX_TRANSPOSE,
> > +TMMPairOperand1|Sibmem|Vex128|Space0F38|VexW0|NoSuf, {
> > +Unspecified|BaseIndex, RegTMM }
> > +
> >  tcmmimfp16ps, 0x666c, AMX_COMPLEX,
> > Modrm|Vex128|Space0F38|Src2VVVV|VexW0|NoSuf, { RegTMM,
> RegTMM, RegTMM
> > }  tcmmrlfp16ps, 0x6c, AMX_COMPLEX,
> > Modrm|Vex128|Space0F38|Src2VVVV|VexW0|NoSuf, { RegTMM,
> RegTMM, RegTMM
> > }
> >
> 
> I'm struggling some in trying to determine on what basis you've established
> where to add the new insns. Would imo be nice if all AMX-COMPLEX ones
> ended up together, all AMX-BF16 etc. Or alternatively if all AMX-TRANSPOSE
> ones ended up together (and not at the very top of the section).

I will change them to feature based for clearness.

Thx,
Haochen


More information about the Binutils mailing list