x86: Add support for Intel AMX instructions

[Jan Beulich]

On 29.06.2020 17:40, H.J. Lu wrote:
> On Mon, Jun 29, 2020 at 8:22 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 29.06.2020 17:16, H.J. Lu wrote:
>>> On Mon, Jun 29, 2020 at 7:48 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>> On 29.06.2020 14:46, H.J. Lu wrote:
>>>>> On Mon, Jun 29, 2020 at 3:03 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>> On 28.06.2020 09:43, Cui, Lili via Binutils wrote:
>>>>>>> @@ -4093,3 +4099,25 @@ xsusldtrk, 0, 0xf20f01e8, None, 3, CpuTSXLDTRK, No_bSuf|No_wSuf|No_lSuf|No_sSuf|
>>>>>>>  xresldtrk, 0, 0xf20f01e9, None, 3, CpuTSXLDTRK, No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }
>>>>>>>
>>>>>>>  // TSXLDTRK instructions end.
>>>>>>> +
>>>>>>> +// AMX instructions.
>>>>>>> +
>>>>>>> +ldtilecfg, 1, 0x49, None, 1, CpuAMX_TILE|Cpu64, Modrm|Vex|VexOpcode=1|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Unspecified|BaseIndex }
>>>>>>> +sttilecfg, 1, 0x6649, None, 1, CpuAMX_TILE|Cpu64, Modrm|Vex|VexOpcode=1|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Unspecified|BaseIndex }
>>>>>>
>>>>>> Aren't these lacking Vex128 and VexW0? Same for I think all further
>>>>>> entries below; see also the respective test case remark further up.
>>>>>>
>>>>>> For Intel syntax these should allow for "qword ptr".
>>>>>
>>>>> I don't think it is correct since these 2 instructions take a
>>>>> 64-memory location.
>>>>
>>>> Oh, sorry for mixing bits and bytes. Should be "zmmword ptr" then, which
>>>> I admit would be kind of ugly/misleading. It still would seem desirable
>>>> to have a way to explicitly specify memory operand size here, but I have
>>>> no good other suggestion for the moment.
>>>
>>> We don't do this for other instructions with 64-byte memory location, like
>>> movdir64b.
>>
>> Well, yes, I'm aware, but I'm not happy with the situation. Still I
>> can see why this may not warrant addressing right now.
>>
>>>>>>> +// Use VexOP3 to indicate we are going to use Vex.vvvv field to encode the third operand.
>>>>>>> +tdpbf16ps, 3, 0xf35c, None, 1, CpuAMX_BF16|Cpu64, Modrm|Vex|VexOpcode=1|VexOP3|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { RegTMM, RegTMM, RegTMM }
>>>>>>> +tdpbssd, 3, 0xf25e, None, 1, CpuAMX_INT8|Cpu64, Modrm|Vex|VexOpcode=1|VexOP3|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { RegTMM, RegTMM, RegTMM }
>>>>>>> +tdpbuud, 3, 0x5e,   None, 1, CpuAMX_INT8|Cpu64, Modrm|Vex|VexOpcode=1|VexOP3|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { RegTMM, RegTMM, RegTMM }
>>>>>>> +tdpbusd, 3, 0x665e, None, 1, CpuAMX_INT8|Cpu64, Modrm|Vex|VexOpcode=1|VexOP3|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { RegTMM, RegTMM, RegTMM }
>>>>>>> +tdpbsud, 3, 0xf35e, None, 1, CpuAMX_INT8|Cpu64, Modrm|Vex|VexOpcode=1|VexOP3|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { RegTMM, RegTMM, RegTMM }
>>>>>>> +
>>>>>>> +tileloadd, 2, 0xf24B, None, 1, CpuAMX_TILE|Cpu64, Modrm|Sibmem|Vex|VexOpcode=1|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Unspecified|BaseIndex, RegTMM }
>>>>>>> +tileloaddt1, 2, 0x664B, None, 1, CpuAMX_TILE|Cpu64, Modrm|Sibmem|Vex|VexOpcode=1|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Unspecified|BaseIndex, RegTMM }
>>>>>>> +tilestored, 2, 0xf34B, None, 1, CpuAMX_TILE|Cpu64, Modrm|Sibmem|Vex|VexOpcode=1|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { RegTMM, Unspecified|BaseIndex }
>>>>>>
>>>>>> As per an earlier comment I think for Intel syntax these ought to accept
>>>>>> "dword ptr" on their memory operands.
>>>>>
>>>>> See above.
>>>>
>>>> How "see above"? The units copied are, aiui, dwords. All larger blocks
>>>> combined from these dwords are dynamically sized, and hence can't be
>>>> expressed with a static size specifier. Hence "dword ptr" looks
>>>> applicable to me here.
>>>>
>>>
>>> So far, "dword ptr" means a pointer to dword.  But it isn't the case here.
>>> Also dword isn't the basic unit.
>>
>> Is it not? What does the 'd' suffix in tileloadd and tilestored stand for
>> then?
> 
> I will check.  But AMX spec doesn't have any dword operations in
> tileloadd nor tilestored.

It's not very explicit, but the exception section has various mentions
along the lines of "#UD if tsrc.colbytes mod 4 != 0". I.e. while
arithmetic happens on int8 / bf16 units, organization is still in
dword granularity. Also see the description of the dot product insns,
which describe how "each dword" gets interpreted by these insns.

Jan