[PATCH 09/10] Support Intel AMX-FP16

[Jan Beulich]

On 18.10.2022 11:01, Cui, Lili wrote:
>>> +  { "CPU_AMX_FP16_FLAGS",
>>> +    "CpuAMX_FP16" },
>>>    { "CPU_IAMCU_FLAGS",
>>>      "Cpu186|Cpu286|Cpu386|Cpu486|Cpu586|CpuIAMCU" },
>>>    { "CPU_ADX_FLAGS",
>>
>> Can you please insert next to the other similar AMX entries? Seeing the flaw
>> here, I'll be making a patch to address the lack of CPU_AMX_TILE_FLAGS in
>> the similar pre-existing entries. When you move the insertion, it'll be easier
>> to keep things in sync.
> Done.
>  
>>> -    "CpuAMX_TILE|CpuAMX_INT8|CpuAMX_BF16" },
>>> +    "CpuAMX_TILE|CpuAMX_INT8|CpuAMX_BF16|CpuAMX_FP16" },
>>>    { "CPU_ANY_MSRLIST_FLAGS",
>>>      "CpuMSRLIST" },
>>> +  { "CPU_ANY_AMX_FP16_FLAGS",
>>> +    "CpuAMX_FP16" },
>>>  };
>>
>> Same here then.
> Done.

I guess my comment here was a little misleading (I'm sorry for that), in
that in addition I was expecting you to consider the comment regarding
the need for the *_ANY_* constants that I did give for several of the
patches in this series. I think the question applies here as well: Are
there dependent features known to appear? If not, there's no need for the
extra constant.

> --- a/gas/config/tc-i386.c
> +++ b/gas/config/tc-i386.c
> @@ -1101,6 +1101,7 @@ static const arch_entry cpu_arch[] =
>    SUBARCH (raoint, RAOINT, ANY_RAOINT, false),
>    SUBARCH (wrmsrns, WRMSRNS, ANY_WRMSRNS, false),
>    SUBARCH (msrlist, MSRLIST, ANY_MSRLIST, false),
> +  SUBARCH (amx_fp16, AMX_FP16, ANY_AMX_FP16, false),
>  };

This might also benefit from moving up, but I'm not going to insist.

> --- a/gas/doc/c-i386.texi
> +++ b/gas/doc/c-i386.texi
> @@ -220,6 +220,7 @@ accept various extension mnemonics.  For example,
>  @code{raoint},
>  @code{wrmsrns},
>  @code{msrlist},
> +@code{amx_fp16},
>  @code{noavx512f},
>  @code{noavx512cd},
>  @code{noavx512er},
> @@ -247,6 +248,7 @@ accept various extension mnemonics.  For example,
>  @code{noraoint},
>  @code{nowrmsrns},
>  @code{nomsrlist},
> +@code{noamx_fp16},
>  @code{noenqcmd},
>  @code{noserialize},
>  @code{notsxldtrk},

There are no @code{no...} entries here anymore, as of earlier today. Hence
no new ones should appear (and you need to re-base in any event).

Jan