x86: Add support for Intel AMX instructions

Jan Beulich jbeulich@suse.com
Tue Jul 7 09:53:22 GMT 2020


On 07.07.2020 10:19, Cui, Lili wrote:
>>> +  /* X86_64_VEX_0F385C_P_1_W_0_M_0_L_0 */  {
>>> +    { Bad_Opcode },
>>> +    { "tdpbf16ps", { XMT, EXtmm, Vextmm }, 0 },
> 
>> Along the lines of the above, EXt then (paralleling EXx)? For the last operand here I'd suggest VexTmm or VexTMM.
> 
> EXtmm paralleling with EXxmm and EXymm,

Ah, I see.

>  I took all your suggestions and revised AMX patch.

Most afaics, but not all.

> --- /dev/null
> +++ b/gas/testsuite/gas/i386/x86-64-amx-bad.s
> @@ -0,0 +1,28 @@
> +.text
> +	#tdpbf16ps %tmm5,%tmm4,%tmm3 set VEX.W = 1 (illegal value).
> +	.byte 0xc4
> +	.byte 0xe2
> +	.byte 0xd2
> +	.byte 0x5c
> +	.byte 0xdc
> +	.fill 0x05, 0x01, 0x90
> +	#tdpbf16ps %tmm3,%tmm2,%tmm1 set VEX.L = 1 (illegal value).
> +	.byte 0xc4
> +	.byte 0xe2
> +	.byte 0x56
> +	.byte 0x5c
> +	.byte 0xdc
> +	.fill 0x05, 0x01, 0x90
> +	#tdpbf16ps %tmm3,%tmm2,%tmm1 set VEX.R = 0 (illegal value).
> +	.byte 0xc4
> +	.byte 0x62
> +	.byte 0x52
> +	.byte 0x5c
> +	.byte 0xdc
> +	#tdpbf16ps %tmm3,%tmm2,%tmm1 set VEX.B = 0 (illegal value).
> +	.byte 0xc4
> +	.byte 0xc2
> +	.byte 0x52
> +	.byte 0x5c
> +	.byte 0xdc

What about the high bit of VEX.VVVV being zero?

What about the case of there not being a SIB byte?

What about the case of any two operands being the same, which I
think the assembler also still doesn't error on, as one can see
...

> --- /dev/null
> +++ b/gas/testsuite/gas/i386/x86-64-amx-intel.d
> @@ -0,0 +1,76 @@
> +#as:
> +#objdump: -d -Mintel
> +#name: x86_64 AMX insns in Intel syntax
> +#source: x86-64-amx.s
> +
> +.*: +file format .*
> +
> +
> +Disassembly of section \.text:
> +
> +0+ <_start>:
> +[ 	]*[a-f0-9]+:[ 	]*c4 e2 78 49 04 51[ 	]*ldtilecfg \[rcx\+rdx\*2\]
> +[ 	]*[a-f0-9]+:[ 	]*c4 e2 79 49 04 51[ 	]*sttilecfg \[rcx\+rdx\*2\]
> +[ 	]*[a-f0-9]+:[ 	]*c4 e2 52 5c dc[ 	]*tdpbf16ps tmm3,tmm4,tmm5
> +[ 	]*[a-f0-9]+:[ 	]*c4 e2 63 5e ca[ 	]*tdpbssd tmm1,tmm2,tmm3
> +[ 	]*[a-f0-9]+:[ 	]*c4 e2 73 5e c1[ 	]*tdpbssd tmm0,tmm1,tmm1
> +[ 	]*[a-f0-9]+:[ 	]*c4 e2 73 5e c8[ 	]*tdpbssd tmm1,tmm0,tmm1
> +[ 	]*[a-f0-9]+:[ 	]*c4 e2 7b 5e c9[ 	]*tdpbssd tmm1,tmm1,tmm0

... here (in my earlier reply I had specifically given the comment
in the context of the "inval" test).

> @@ -6830,6 +6932,78 @@ static const struct dis386 x86_64_table[][2] = {
>      { "lidt{Q|Q}", { M }, 0 },
>      { "lidt", { M }, 0 },
>    },
> +
> +  /* X86_64_VEX_0F3849_P_0_W_0_M_0_L_0 */
> +  {
> +    { Bad_Opcode },
> +    { "ldtilecfg", { M }, 0 },
> +  },
> +
> +  /* X86_64_VEX_0F3849_P_0_W_0_M_1_REG_0_RM_0_L_0 */
> +  {
> +    { Bad_Opcode },
> +    { "tilerelease", { Skip_MODRM }, 0 },
> +  },
> +
> +  /* X86_64_VEX_0F3849_P_2_W_0_M_0_L_0 */
> +  {
> +    { Bad_Opcode },
> +    { "sttilecfg", { M }, 0 },
> +  },
> +
> +  /* X86_64_VEX_0F3849_P_3_W_0_M_0_L_0 */
> +  {
> +    { Bad_Opcode },
> +    { "tilezero", { TMM, Skip_MODRM }, 0 },
> +  },
> +
> +  /* X86_64_VEX_0F384B_P_1_W_0_M_0_L_0 */
> +  {
> +    { Bad_Opcode },
> +    { "tilestored", { M, TMM }, 0 },
> +  },
> +
> +  /* X86_64_VEX_0F384B_P_2_W_0_M_0_L_0 */
> +  {
> +    { Bad_Opcode },
> +    { "tileloaddt1", { TMM, M }, 0 },
> +  },
> +
> +  /* X86_64_VEX_0F384B_P_3_W_0_M_0_L_0 */
> +  {
> +    { Bad_Opcode },
> +    { "tileloadd", { TMM, M }, 0 },
> +  },
> +
> +  /* X86_64_VEX_0F385C_P_1_W_0_M_0_L_0 */
> +  {
> +    { Bad_Opcode },
> +    { "tdpbf16ps", { TMM, EXtmm, VexTmm }, 0 },
> +  },

As a minor remark - from here to ...

> +  /* X86_64_VEX_0F385E_P_0_W_0_M_0_L_0 */
> +  {
> +    { Bad_Opcode },
> +    { "tdpbuud", {TMM, EXtmm, VexTmm}, 0 },
> +  },

... here (and further down) you started losing blanks inside
the inner braces.

Jan


More information about the Binutils mailing list