Re: [PATCH 3/5] x86: support AVX10.1/512

[Jan Beulich <jbeulich@suse.com>]

On 01.09.2023 10:52, Jiang, Haochen wrote:
> 
> 
>>>>> AVX10 should not imply them. However, I suppose we are talking about
>>>>> the relation between AES/VAES and PCLMULQDQ/VPCLMULQDQ.
>>>>
>>>> Correct. Some change needs to be done; the question is whether as
>>>> posted, or whether with a prereq patch adding those two connections
>>>> (with, as said before, me intending to go the latter route unless I
>>>> hear otherwise).
>>>
>>> I agree.  VAES should imply AES and VPCLMULQDQ should imply
>>> PCLMULQDQ.
>>
>> Actually there's something similar with AVX10 itself: AVX512F includes
>> equivalents right away of what comes under separate extensions for AVX:
>> F16C and FMA. AVX10, otoh, is presently specified to only guarantee
>> AVX and AVX2. Does that mean that VEX-encoded vfm{add,sub}* and ps<-ph
>> conversion insns aren't guaranteed to also be available? Doesn't seem
>> logical to me, so I'm inclined to make FMA and F16C prereqs of AVX10.1
>> as well (or alternatively of AVX512F, but I think this would have
>> undesirable effects). AVX2 isn't an explicit prereq only because it
>> already is one of AVX512F.
> 
> I suppose AVX10 should only enable EVEX encoding,  they have nothing
> to do with the VEX encoding.
> 
> For those independent VEX ISAs, if AVX512F is not enabling it, AVX10 neither.
> 
> Actually, not only F16C and FMA, under AVX10, ISAs like AVX-VNNI, AVX-IFMA
> are also not enabled.

The difference to the AVX-* ones you mention is important here: AVX-VNNI
(taking that as example) isn't a feature that had equivalent EVEX
encodings added right in AVX512F. So I'd like to ask that you re-consider
what you said. Also think about what the compiler does (which doesn't
emit .arch directives to limit the usable ISA extensions) when just
-mavx512vl is passed to it: VEX-encoded vfm{add,sub}* would then still be
resulting (to prevent that, the compiler would need to further emit {evex}
pseudo-prefixes). IOW in the compiler there is such an implication already
anyway.

Jan