x86: Add support for Intel AMX instructions

[Jan Beulich]

On 30.06.2020 14:20, H.J. Lu wrote:
> On Tue, Jun 30, 2020 at 2:48 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> 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.
> 
> But we don't use "dword ptr" on vector instructions with dword granularity.

Which is why rather I compared it to the scatter/gather subset, where we
do. No larger granularity of types is known at build time, so this is as
good as it can get. But I'm not going to insist, especially as long as I
don't know what MASM will permit / refuse.

Jan